I'm getting the following error compiling a program using a 3rd party library:
Error:(xx) No resource identifier found for attribute 'tint' in package 'com.example.mycompany.myapp'
The line xx is inside the xml layout that includes a custom component defined in the library.
cntrlco:tint="42"
The xml namespace documentation says I need the following:
xmlns:cntrlco="http://schemas.android.com/apk/res-auto"
Here's my best guess as to the problem, but if you think otherwise please let me know, this is a guess.
I suspect I don't have the library installed completely. The reason is that the library instructions want the library installed from maven. I'm not up on this technique, but it appears to be a web based auto install that automates dependency installs while performing the primary install. Nice idea, but I can't install using the web (long story), so I included the .aar file locally.
From my research, installing .aar files locally won't look at its dependencies. If this is true and the "tint" property is defined in a dependency, then this would explain the error I'm seeing.
Is there a way to follow the error chain in more detail so I can verify my theory? Along the way, will this help me find the name of the possible missing dependencies so I can see if including them fixes the problem.
This is just odd.
I'm getting a build error in ServiceStack.Text after just bringing down the latest build from GitHub.
if (endpointUrl.IsNullOrEmpty() || !endpointUrl.StartsWith("http"))
return null;
Error 1 No overload for method 'IsNullOrEmpty' takes 0 arguments
ServiceStack\src\ServiceStack.Common\Messaging\ClientFactory.cs 10 18
ServiceStack.Common
I'm also getting bunch of other build errors:
Error 35 'int' does not contain a definition for 'Times' and no extension method 'Times' accepting a first argument of type 'int' could be found (are you missing a using directive or an assembly reference?) ServiceStack.Redis\src\ServiceStack.Redis\Messaging\RedisMqServer.cs 192 37 ServiceStack.Redis
and after downloading the ServiceStack branch, I even tried opening ServiceStack-master\src\ServiceStack.sln and tried to build and it's totally broken:
I don't know what's going on here, there can't possibly be this many build errors if any right? I pray not but it seems as such.
Purpose of this post, what I'm asking about and need help clarifying and resolving (mythz???)
I need input from ServiceStack here on the following:
1) are the builds really this broken? Am I imagining this?
2) The branch stucture on GitHub is all over the place meaning I'm finding dup project folders all over and I do not know what this ServiceStack branch is as in it's src folder has a ton of projects there, different versions, as well as doesn't have projects like ServiceStack.Text, etc. so I don't know what's going on here. I want to use the basic core of service stack but there's like repeated stuff everywhere overall on GitHub. I need ServiceStack to clear all this up for me.
Here is my code, so you can see for yourself, it doesn't build.
This one won't build in terms of the ServiceStack projects - it's my solution in which I'm simply trying to include the ServiceStack projects I need along with my own projects that are using ServiceSTack. All I did was downoad those individual projects from https://github.com/ServiceStack then added them to my solution and made sure that any references to each other were now Project references, no longer binary..I removed the binary refs and readded them as project refs. So for example ServiceStack.Common depends on ServiceStack.Text but it was referencing it via binary so I removed it and readded the reference to ServiceStack.Text as a project ref now because in the end we plan on being able to look at and work with the base Stack code. The errors I posted above are happening in this Solution for ServiceStack related projects.
This one won't build - it's a download of the ServiceStack branch master (originally folder name is ServiceStack-master, I removed the -master)
UPDATE: yes I confirmed it's a bad build checked in on the GitHub site (refering to the ServiceStack branch master right above here). I had to remove unused using statements that were causing the build to fail and one of these was a dup using statement causing part of the build failure. I am surprised at this...this stuff should build and people should be checking in code that BUILDS successfully! common! Yes mythz, any dev trying to consume your API would be pissed that there are so many build erros all the time, I can't even get our protype going because this is not the only solution that won't build. First we had the Examples solution all breaking and now the core. I'm willing to fix these if I can but I honestly can't believe it's been a mountain to try to even use this API because of these checked in builds that are failing.
This one Will build because it was Nuget down, so ServiceStack is referencing other layers via binary references in the lib folder so this builds...probably builds here because someone has a working set of builds across all core projects but the stuff on the site for download is not the same revision and broken when you try to use them as project references (source code)?? Just my conclusion as it's only building IF you are using binary references to the lib folder. We want the source, not the binaries to work inside our solution so this is a brick wall for me
There are a lot of big changes happening on master right now - it will be unstable for a while.
I suggest you branch from the v3-fixes tag or pull the references from nuget.
#CoffeeAddict
Yesterday, the mythz answered about these problems in your previous question
"#CoffeeAddict like I said before, ServiceStack's is undergoing significant re-factoring and master in alpha and not for public use. While everything still builds for me and tests still pass in CI, it will be frequently unstable until its in beta. You're likely mixing v3 with v4 dlls which are technically incompatible. The release on NuGet is off the v3 branches of each project, that's what you should checkout if you want to build from src. Any contribs should be done to v3-fixes only - see Contributing docs for more info. – mythz 9 hours ago"
well looks like when I had downloaded all the stack branches, at the time earlier today contributors had checked in broken builds. Fabulous.
I just got latest early this morning, and appears people must have fixed the build and checked some stuff back in for various core projects. Now it builds.
Suggestion to mythz, get CI in place NOW. Don't wait for v4. This cost me a freakin day of trying various things to get this stuff to build and the problems were across several projects. This shouldn't happen, setup CI please. It's 2am and nobody using this project should have to deal with it.
I will contribute but first I had to get a full build to work! Not too happy as no dev would be wasting an entire day getting ServiceStack to build.
To compile v3:
Would someone with true knowledge post PROPER instructions on compiling v4 or v3? I had no luck with the build.bat files for v3 or v4, and opening solutions will not compile for most.
git clone servicestack, servicestack.text, redis, ormlite
make a new directory and copy from under src so you have these:
ServiceStack
ServiceStack.Client
ServiceStack.Common
ServiceStack.Interfaces
ServiceStack.OrmLite
ServiceStack.Redis
ServiceStack.Server
ServiceStack.Text
open csproj for ServiceStack.Interfaces ... right click properties, go to the signing tab, click the combo, new, type in your own signing pfx, I used servicestackInterfaces.pfx (doesn't matter) and make up a password.
Compiles fine, since it has not much referenced.
saved solution as ServiceStackV3 in folder C:\2015\SSv3compile
add csproj ServiceStack.Text, set signature, compiles ok
add csproj ServiceStack.Common, set signature, remove references, add references using solution for interface, text, compiles ok
add csproj ServiceStack.Client, set signature, remove references, add references using solution for interface, text, compiles ok
add csproj ServiceStack, set signature, remove references, add references using solution for client, common, interface, text, compiles ok
add csproj ServiceStack.OrmLite, set signature, remove references, add references using solution for common, interface, text, compiles ok
add csproj ServiceStack.Redis, set signature, remove references, add references using solution for common, interface, text, compiles ok
add csproj ServiceStack.ServiceStack.Server, set signature, remove references, add references using solution for Servicestack, ServiceStack.Client, ServiceStack.Common, ServiceStack.Interface, ServiceStack.Text, ServiceStack.Ormlite, ServiceStack.Redis
compiles ok
have some more trouble compiling the tests...
and finding so many tweaks and changes which are for me maddening to find
(endless agentransack searching for "namespace ISomethinMissing" in *.cs
... there seems to be namespace ServiceStack with cs code contained in projects other than Servicestack...
isn't that VERY improper? (now you require both DLLs? why not one?)
whatever...its free and works for what I wanted.
looks like there is some code leakage from v4...
after getting my head around v3, not sure I want to buy v4 - I will probably buy it in the future, I expect, and hope someday I can just clone and compile from the solution
ANyway, I love servicestack and have been
replacing old webservices
and the config nightmares of WCF with great happiness...
I say it is well worth the initial hassle.
I put this all in code block because I found the editor wouldn't accept this simple text when it was in a numbered list. whatever.
Is there any alternative to achieving serialising and deserialising of objects in Xamarin.iOS (Monotouch) using protobuf-net other than this method:
http://www.frictionpointstudios.com/blog/2011/3/31/using-protobuf-net-serialization-in-unity-iphone.html
Reading around some people claim they have managed it (without giving evidence), but my understanding is that [iOS JIT==NO] so does not quite make sense.
If the only possible solution is to fully AOT all relevant classes what might a suitable pre/post-build event command line be to perform this AOT for any relevant assemblies automatically?
I've heard a good number of people have success via that route, but I too can't give documented evidence.
That method is a bit out of date - I've simplified a few steps; there is a standalone pre-compile tool that should work:
create a project/assembly for the DTOs that you want to serialize that references the appropriate version of protobuf-net; presumably CoreOnly/ios, ideally with that dll set to copy into the output directory (it just makes life easier)
run
precompile "SomePath/YourDto.dll" -t:MySerializer -o:MySerializer.dll
(maybe with a mono before that to get mono to host the exe)
this should resolve the framework and compile a MySerializer.dll that you can reference, which involves zero JIT (MySerializer.dll will reference your dto dll and the version of protobuf-net that your dto dll referenced)
now reference your dto dll, the serializer dll, and the protobuf-net dll, and it should all work just by using new MySerializer().Serialize(...)
when you compile your solution, the projects should all AOT nicely
I'll be happy to offer guidance, but currently I am mac-less, so I can't check right now. If you get any problems let me know. If it can't resolve the framework, you can add -f:{path to the framework assemblies} to give it a clue.
I got protobuf-net 2 working on Xamarin-iOS by using the netstandard1.0 dll. You can get this dll by extracting the nuget package. No changes were needed.
I'm trying to run sample projects (viz. BestSellers and Conference) that are present in MvvmCross v3 branch. I resolved the strong assembly reference issues successfully. However each time I run a sample project, I get System.TypeLoadException in MvxFullBinding and MvxValueConverterRegistryFiller classes.
Exception in MvxFullBinding class:
Exception in MvxValueConverterRegistryFiller class:
Is anybody able to run the sample projects successfully? How do I get around these exceptions?
It looks like you're running this as the 'Touch' projects from Visual Studio? In which case you are way ahead of what I've managed to achieve.
If that is correct, then I suspect that what you are seeing is that you have:
built proper PCLs built in VS/Windows against the portable reference assemblies
but these cannot be executed against the current MonoTouch/Xamarin.iOS runtime.
If you try, you may see issues like: iOS black screen and MissingMethodException: Method not found: 'System.Type.op_Equality'
For some more info see 'almost portable binaries' on http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html
There is 'proper' PCL support currently being worked on within XamLabs - so I am hopeful that there may be a solution to this problem arriving in the Xamarin.Android Alpha channel any day now - but don't expect this to be painless initially.
Of course, I might be wrong on this - this really is new territory and I will be fascinated to hear/read about your adventures. If you want to try to find more detail, then it may help to try looking deeper into the exception details, and looking into the console log trace on your mac.
For these two particular exceptions, I can confirm that both samples...
... although that is when I'm working on my Mac.
I am experimenting with ServiceStack's JSON engine. I grabbed the MonoTouch binary build, v2.20. Works fine from simulator, but from the iOS device (iPad2, iOS5) I get an exception thrown by the type initializer for JsonWriter (and not much other than that). I am using MonoTouch 5, MonoDevelop 2.8.1, and targeting iOS 5. I have disabled library linking because I am getting an error when enabled.
I created a sample and uploaded to https://github.com/t9mike/ServiceStack-JSON1.
I'm trying to determine whether the issue is my compilation options, Service Stack, or MonoTouch. Thanks in advance.
A quick partial answer that might help:
I have disabled library linking because I am getting an error when enabled.
The current (5.0) managed linker can eliminate some unused (from a static analysis point of view) code from your application. This generally occurs when using Link all option, i.e. where user code gets processed by the linker.
One alternative is using the Link SDK assemblies only that won't touch the user code (only the code shipped with MonoTouch itself will be processed by the linker).
Another alternative is adding [Preserve] attributes on your code to ensure the serializer requirements are still met after the linker has processed your code. More information about the linker and [Preserve] attributes can be found here.
The next (5.2) release of MonoTouch will include a bit more sophisticated step in the linker to ensure the basic XML serialization and DataContract requirements are not broken. Not sure if this will solve this specific case (ServiceStack JSON) but I'll have a look into it.
As for the rest of your question I'll try to build this myself and duplicate your issue.
I ended up grabbing the ServiceStack.Text sources from GitHub, version 3.0.3. I created a new MonoTouch library project. I had to tweak ServiceStack.Text/JsConfig.cs slightly to conditionalize away the System.Drawing.Color bits. I'll send a patch and MT csproj to the authors.
After using this new assembly, my sample MT app ran fine on the device. I have updated my sample at https://github.com/t9mike/ServiceStack-JSON1 with the new ServiceStack.Text dll.