I have a Win8 app that is purely native (c++) and I've already used a library that is written using managed code AFAIK. No issues there, I created objects and addressed them using C++/CX with ref counted pointers etc.
I need to add a new library, I referenced it as I did previously, but when I declare and object and try to address it I get:
error C3624: 'System::Object': use of this type requires a reference to assembly 'mscorlib'
Using #using <mscorlib.dll> is not a solution obviously, because WinRT does not support #using of a managed assembly.
When I look up the definition of the class I'm using in Object Browser I see that it's inherited from System::Object. The previous library had a class that was inherited from Platform::Object which is valid for C++/CX.
I already contacted the developers of current library I'm trying to use, but it takes a lot of time for them to respond.
Can I work around this issue? What are the possible courses of action?
UPD: Can I ask the developers to rebuild a library for C++/CX?
I do not believe this is going to work in the general case, unless the C# library is a PCL (portable class library). If it leverages anything that is not in the WinRT .NET client profile, it simply will not work.
If it is a PCL, what you can do is write a C# Windows Runtime Component that itself has a reference to this third-party library and wraps the necessary functionality. Then you reference that C# Windows Runtime Component from your C++/Cx application.
Related
I'm working on a project which is an open-source cloud, similar to Nextcloud. It also provides a file upload and manage feature.
I'd like to have a shell namespace extension which displays those files and folders in the Windows Explorer. Moving, deleting, renaming and editing files / folders should be possible.
Data is available from a REST API or my Electron Client.
I know NodeJS and only some C#.
Is it possible whith NodeJS / Electron to create a shell namespace extension?
If not, are there any free libraries which make this task easier?
Windows Explorer uses 'COM' as its extension model. Therefore, technically speaking, you can use whatever you like, as long as it supports COM.
For NodeJS, you'd be dependent on the runtime to provide the COM support for you and to wrap the appropriate APIs. I'm not aware of any project that does this for the Windows Shell APIs. Here is one for the WinRT APIs.
For C# (.NET), again you'd be dependent on the runtime for COM support. .NET does expose that to you; although it is messy. There are a few projects which wrap the shell APIs and try to hide the COM interop goo as best they can for you.
Here is an open source one.
Here is a commercial one.
Be aware that Microsoft advises against building shell extensions which require a runtime (EG: .NET). The runtime may be loaded into processes that aren't expecting it. Therefore, in practice, Microsoft expects you to use C/C++ to build shell extensions. Here is the Microsoft supplied sample project. It is written in C++.
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).
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.
I have a DLL (written in C) that uses static thread local storage (__declspec(thread)), and I want to use this DLL from a Visual Basic graphic interface.
Unfortunately, when running the interface on Windows XP that DLL which use static thread local storage crashes when it try to acess its thread variables.
How can I solve this problem?
Thanks,
Regards
G.B.
PS
I would like to not modify the DLL.
This is a known limitation of static TLS. Although you aren't explicitly calling LoadLibrary(), the VB runtime does so on your behalf.
Note that this limitation has been lifted from Vista. The most comprehensive reference that I know of is on Ken Johnson's blog.
You may be able to get around the problem if you could get the DLL included in the imports table of the generated .exe, which would likely involve some PE hacking and I'm far from certain it's a viable strategy. Otherwise you'll need to change the DLL.