Mono.Cecil does not support mixed mode assemblies as of date, and even though it can read the .NET portion of such assemblies, it does not write such assemblies back to disk. What does it take to support a read->write roundtrip for mixed mode assemblies? (without making any changes to the x86/x64 assembly)
Please note I only need to work with .NET metadata and CIL, not the actualy x86/x64 assembly itself. I only need to modify some .NET classes within a mixed-mode assembly, therefore, I need to load it into objects using Cecil, make my changes, and then save it back, leaving the x86/x64 assembly code unmodified.
I'm assuming the x86/x64 assembly would be stored in a chunk, which could be simply read into a bytearray during parsing, and outputted back into the generated EXE when saving the assembly. Is it so simple?
From the FAQ:
Cecil can read mixed mode assemblies, but writing mixed mode assemblies is not supported
Mono.Cecil does not support writing mixed mode assemblies.
There is another library, dnlib, which does. The API is similar, but not the same, so it's not a drop-in replacement.
From the project's README.md
dnlib was created because de4dot needed a robust .NET assembly library that could handle all types of obfuscated assemblies. de4dot used to use Mono.Cecil but since Mono.Cecil can't handle obfuscated assemblies, doesn't fully support mixed mode assemblies, doesn't read .NET assemblies the same way the CLR does and many other missing features de4dot needed, dnlib was a necessity. The API is similar because it made porting de4dot to dnlib a lot easier.
GitHub repository is here: https://github.com/0xd4d/dnlib
Related
I have a .net (4.7.2) application that calls into a 3rd party native library using [DllImport("Foo.dll"...)]. That native Foo.dll is written in C++ and has a lot of dependencies: 90 assemblies, 360 MB (!) are shipped currently. I know that some dependencies are shipped, but not used anymore. Asking that 3rd party for cleanup had no effect, its getting more and more every few month.
Q: Is there any way to distinguish required, actively loaded native assemblies from dll bloat?
I have experimented with AppDomain.GetAssemblies() on application exit, but it one only returns managed assemblies.
I have experimented with DependencyWalker and its modern brother Dependencies, but it seems most of the truly required dependencies of Foo.dll are loaded on demand - only a small fraction shows up in those apps.
You could use Procmon to track assemblies being dynamically loaded.
But if some assemblies are only loaded if the feature is in the use, then you don't have any other choice than looking at the code (if you can) or go through all the possible code paths and track all loaded dlls.
Is C++ source code required to build a .NET wrapper or static libraries *.lib files are just enough?
We plan to use SWIG.
Thanks.
w.r.t. your question asking specifically about static-libraries *.lib:
Is C++ source code required to build a .NET wrapper or static libraries *.lib files are just enough?
I doubt you actually intend to wrap a static-lib: Statically-linked libraries generally aren't redistributable nor portable (e.g. the authors of closed-source static libraries need to build them every time a new supported compiler comes out, e.g. you can't use a GCC lib with VisualC++ 2017, and an x64 VisualC++ 2017 lib won't be compatible with an x86 VisualC++ 2015 project) - and even if you loaded a *.lib into your process' memory and jumped into a known function address inside the lib's image, it would immediately break because the static library's code will have references to certain memory addresses (e.g. of string-constants) which aren't yet relocated - you'll get an segfault (or "Access violation" on Windows) crash if you're lucky (if not, it'll definitely corrupt your process' memory space before being detected).
P/Invoke in .NET Framework and .NET on Windows (i.e. using [DllImport]) only supports DLLs (Dynamically Linked Libraries), not statically-linked libraries.
You can also call into native code if the native code is available as a COM object, or can be accessed through platform features like OLE, WMIC, ADSI, etc (assuming your code's process is the same ISA as the native code you want to call, as it will still be loaded into your process, which is why you can't use 64-bit Office Excel to open databases where only a 32-bit OLE-DB or ODBC driver is available).
When a library is available as a *.lib then you need to make your own native host first - a simple C/C++ Win32 (PE) EXE or DLL that re-exports all of the useful functions from that *.lib will be sufficient - because then those exports can be imported by C#/.NET.
But in general:
If you are exporting COM objects to .NET then you don't need both the source-code files (*.c, *.cpp) or header files (*.h and *.hpp), only the IDL files or *.tlb (Type-lib) which the compiler will generate for you.
If your native code is also available through other platform features like OLE, ActiveX, COM Automation (IDispatch), ODBC, OLE-DB, ADSI, WMI, etc then you wouldn't be using [DllImport], and those platforms all either provide a standard interface (like ODBC and OLE-DB)
But generally speaking, no - you do not need the source-code (i.e. both *.c and *.h files) to create a .NET wrapper around native code exported from a native DLL and imported into .NET using [DllImport].
But you will need the header files (*.h) from a C/C++ project in addition to knowing the compiler settings (for finding out things like calling-convention, parameter marshaling info, etc) and a PE inspector (to verify the exported functions are at least present in the DLL you want to load).
Don't forget to ensure you provide both x86 and x64 native DLLs for all functionality if you're compiling your C#/.NET code for AnyCPU (tip: Using a 32bit or 64bit dll in C# DllImport )
I've read many questions and answers indicating that if I want to link my C# project against native libraries, I can't use AnyCPU platform target but must make separate 32- and 64-bit builds, each linked against the native DLL of the appropriate bitness.
This makes me wonder how the .NET Framework assemblies themselves are, or at least appear to be, built for AnyCPU. That is, when adding a reference to my GUI application, why don't I have to pick the 32-bit or 64-bit version of System.Windows.Forms? I thought this might just be some Visual Studio magic that would resolve to the appropriate GAC subdirectory (GAC_32 or GAC_64), but I searched for System.Windows.Forms.dll in the GAC and found it in:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll
Note the "GAC_MSIL". So how does this DLL manage to wrap a native 32-bit API yet remain linkable in a 64-bit application? And why can't I use a similar strategy to make a single C# DLL that links against a native 32-bit library yet remains runnable in 64-bit mode?
Option 1: In GAC you may register 2 versions of assembly one 32 and one 64 bit with exactly same names. Oracle DB Driver for .NET uses this strategy.
Option 2: With your assembly that will be AnyCPU deploy two versions of native DLL and choose proper DLL at runtime (SQLite works like that). As it turns out .NET Framework is intelligent enough to load proper version of native DLL via P/Invoke (Using a 32bit or 64bit dll in C# DllImport)
I had the same problem and ended up using Fody Costura
DLL Files will be shipped as embedded ressources and the lib takes care of the bitness.
You could find an example for SQLite here
The problem I have encountered was that your application needs to have access to the Windows Temp folder to create the assemblies from the ressource. If you dont need it, you could disable it using a config setting createtemporaryassemblies
I know I'm not the first person to ask this question on Stack Overflow and I'm sure I won't be the last. But, after spending hours researching how to do this and then physically trying to do it, I'm near ready to give up.
I have a .NET Framework 4, C#, WinForms application that builds to an executable. I rely on many many many dlls. The dlls fall into multiple categories.
Libraries I have written with no dependencies of their own
Libraries I have written with dependencies on other libraries I've written
Libraries I have written with dependencies on third party dlls
Third party stand alone dlls
Third party dlls with their own dependencies on other dlls
So after I compile my application I have a directory with an executable and approximately 15 dlls.
I want to pack all the dlls into a single executable so that I can simply distribute a single executable.
I know that IlMerge is the typically suggested application to use for this, but I'm curious if there is something easier to use that is more intuitive and works accross both WinForms and WPF.
The problem here is that ILMerge only can merge .Net assemblies. Your file lame_enc.dll isn't a .Net assembly but a standard Windows dll and therefore can't be loaded by ILMerge.
To get around this you could embed lame_enc.dll in your assembly and then extract it when needed in your application. Check out this article for more info on that.
http://weblogs.asp.net/ralfw/archive/2007/02/04/single-assembly-deployment-of-managed-and-unmanaged-code.aspx
In the end, I went an entirely different direction.
I decided to use the Costura Visual Studio Extensions located here.
These extensions use a combination of two methods
Jeffrey Richter's suggestion of using embedded resources as a method of merging assemblies
Einar Egilsson's suggestion using cecil to create module initializers
What's nice here is that you simply install the extensions into Visual Studio. After doing that, for any project where you want to pack your DLLs into a single executable, simply select the project, click Project on the menu bar, Costura, Configure, and then OK. It will ask you to reload the project - click yes. Now whenever you build the project it will create just a single executable (or DLL if you are doing it on a library). Couldn't be more easy.
ILMerge only combines pure (not mixed-mode) CLR assemblies. It works by extracting all of the CIL modules and then relinking them into a single new assembly. Assembly resources are also recombined.
ILMerge cannot merge native executable code. lame_enc.dll is a native DLL file and does not contain any CIL modules, that's why you can't combine it.
If you want to pack your application into a single executable a workaround is to include lame_enc.dll as an assembly resource, then save lame_enc.dll to disk in a temp folder perhaps, and add the folder it was saved in to your application's PATH, so your [DllImport] runtime linker will be able to access it.
To address your exact issue, verify that the file C:\Release\lame_enc.dll exists and that it is in fact a .NET file. ILMerge can only merge .NET assemblies.
Now if you are only worried about distribution of your application, you may consider creating an installer to install all of the binaries, and not worry about merging them using ILMerge.
Another alternative to using ILMerge is to embed the binaries in an assembly as desribed here.
Is there any way to compile a .NET assembly into native code (i.e for x86) output, that is, without MSIL.
For what I understand if you just specify x86 as architecture this would only change the PE Header to point that out to the JIT, but still the assembly will contain MSIL and will be JITTed as needed.
NGen does produce assembly files for the specified architecture but it's not a compiler, it's designed to improve performance but you do still need the original DLL, the presence of the native image only serves to avoid JIT compiling the assembly but you just can't get that native image and use it, can you?
So, is there any way to actually compile from .NET to native machine code?
Spoon Studio (was named Xenocode before) seems to be able to do that: http://spoon.net/Studio/Features.aspx
RemoteSoft also have a product but the website looks quite old: http://www.remotesoft.com/linker/
You can do this using the new precompilation technology called .NET Native. Check it out here: http://msdn.microsoft.com/en-US/vstudio/dotnetnative
Currently it is only available for Windows Store Apps. It performs single component linking. So .NET Framework libraries are statically linked into your app. Everything is compiled to native and IL assemblies are no longer deployed.