I'm pretty new to ServiceStack, so apologies in advance if the nomenclature is not 100%.
I create a test self-hosted application and the ServiceStack Service was in the same assembly as the mainline code. All good.
I then moved the code to production use, and service now lives in a separate assembly to the main code. Initially, I have a test harness that I use to make sure everything works fine, and then a windows service that references that same assembly. Fairly sure this would be normal usage.
The test harness works fine, however for production use, I have used Fody Costura to embed the assemblies into a single executable (makes it easier to copy from dev machine to production machine was my thinking).
When using Fody Costura to embed the assembly into the executable, ServiceStack returns an error during the Init() (invalid path). I have tested this and it seems that the ServiceStack Service class needs to be in a physical assembly file that can be loaded, and not a resource.
Is there are known work around for this, or do I need to retain the code in its own assembly for ServiceStack to work?
Thanks in advance.
Craig
I'm not familiar with Fody Costura impact, but the ServiceStack.Gap project shows how you can ILMerge ServiceStack into a single cross-platform .exe.
Related
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.
Can you use the InternalsVisibleTo assembly attribute in a AssemblyInfo file of a MonoTouch Library to allow MonoTouch Unit Test (Touch.Unit) access to the internals of the MonoTouch library?
This is something that is great to use in non-MonoTouch world to allow testing of internals without having to jump through hoops. However I am not able to get it working with a MonoTouch Unit Test. So before I go any futher I figured I would ask if it is even possible, since this is an iOS Application that is the test runner, so not sure if an iOS application which is compiled to native code can even do this.
Yes, it should (or it's a bug) even if I do not recall trying it myself.
The key point is that [InternalsVisibleTo] is mostly a compiler trick and it is supported by the C# compiler (smcs) shipped with MonoTouch (as it's used inside the BCL). As such there's no reason why it should not work from a Touch.Unit-based application.
Now keep in mind that all other rules still applies. E.g. if the the managed linker is enabled when all unused code will be removed (even if marked with the attribute).
Due to MonoTouch using dll's within the actual app, how secure is this approach? For instance, if someone is using the Mono.Security.dll, couldn't someone swap out that dll with one which implemented the methods and perform a code injection attack on an app?
how secure is this approach?
As much as any existing ones I know :-)
couldn't someone swap out that dll
No for several reasons.
You cannot change the applications files. That would break the digital signature and iOS won't execute it. That alone removes a MitM attack;
the code from every .dll is already compiled to native code (by the AOT compiler) and part of the main executable binary. Swapping a new .dll won't change the code that is executed;
the .dll that is deployed on devices is stripped (for release builds). There's no IL (code) inside it since it would not be useful (we can't JIT on iOS). Even if you add a .dll with IL code (e.g. a debug build) it won't be executed (again it would require JITting);
Why are the .dll deployed ? for their metadata (e.g. if you use reflection)
Final note: MonoTouch produce native ARM executables just like Objective-C would.
This is my first question here, so please don't shoot.
I've been playing with Linux recently (Ubuntu 9.04 and openSUSE 11.1) with focus on web services. The simple Hello World web service (as described on mono-project.com) works fine. Now I need to step into the wonderful world of WCF (I'm familiar with the concept). And I'm stuck. I've installed MonoDevelop and mono-wcf package (including all the dependencies) and as you can assume I can't write simple WCF server (well, I can write it, it just won't compile). I'm missing some references which I can't find: The type or namespace name 'ServiceModel' does not exist... and when I add System.ServiceModel reference (for which I have to change to Moonlight/Silverlight project type or I don't even see it in Packages) I get: The type or namespace name 'ServiceHost' does not exist, and I just don't know where it is.
What am I doing wrong? The same code compiles and runs fine on Windows (VS2008).
Please help. And still don't shoot.
Although there is work currently being put into WCF on Mono (mainly around the parts of WCF that are included in Silverlight), the WCF stack is largely incomplete. My impression is that only the most basic of operations are functional.
Regular web services, on the other hand, should be fully functional.
I was going to try Subsonic, you can generate DAL with buildProvider element in an ASP.NET website project. But I get curious why Web applications or windows applications do not support BuildProvider.
PS: I know for Subsonic there is one other option to use it with other than BuildProvider, but I just get curious.
It doesn't work because of the different way things are compiled in web application projects vs. website projects. From what I read on MSDN, it has to do with the fact that in web app projects, all your code files are compiled into a single assembly using MSBuild before deployment, but Build Providers are used to generate code that is compiled at runtime (from your App_Code folder).
In website projects, all of your code is compiled at runtime so it all plays nicely together.
You could possibly hook it into your pre-build event, and call the sonic.exe with the proper command line.