Is there a reason we can't link a .netmodule?
On the full framework, if you have a completely native DLL (compiled without the /CLR switch), you can add as input a pure MSIL .netmodule to the linker input. The file then becomes sortof a mixed assembly. How come we can't do this on the Compact Framework?
If you try this, you'll get a linker error because it doesn't like the X86 signature in the .netmodule. If you manually hack the netmodule to change the signature to ARM, the linker will cough a furball about the .netmodule's format, and then GP fault.
I ended up writing a merge program myself to merge a native DLL and a pure MSIL DLL, but it'd be a lot nicer to see the linker support this.
BTW: Even the x86 CE linker will link with a netmodule ... It seems just the ARM linker chokes.
Robert
My guess would be it's not very useful, so nobody thought of supporting it. The natural workaround is to use separate DLLs, managed DLL will be CPU independent so you need only one for all and it might even run on desktop.
Not useful? I can argue otherwise. The native DLL is cpu-dependent, so I gain nothing by having a managed wrapper that is CPU-independent. I still need an installer with all the CPU variations of the native DLL.
Perhaps the #1 benefit is avoiding DLL hell. The user of the library can remain version dependent on a specific release of the DLL and know that no matter what, nobody could accidentally overwrite the native counterpart and break his/her app.
Can you give any compelling reasons why having two DLL's in your app folder is better than one?
Robert
I ended up writing a program to merge the binaries myself, and learned quite a lot about the underpinnings of the .NET file format in the process. One of the side benefits of my custom util was that I was able to eliminate the static linking of mscoree to the library and use my own entry point stub. If mscoree is already loaded, the library calls its _CorDllMain, but if not, it bypasses it and goes to the native DLL's normal entrypoint.
It's nice because now the native portion of the library can be loaded and used by native components without any dependency on the .NET framework, and the .NET apps can reference the exact same library and use it normally as well. Oh, and another side benefit is that the merge util takes DLL's as input, so I don't have to compile into .netmodules, which means I can use the IDE for everything instead of having to compile from msbuild or the command-line.
Robert
