I have visited this and found no answer How to convert a .NET exe to native Win32 exe? for me. I am searching for a program that converts .net exe to win32 exe. Is that possible ? I have run ngen.exe from Microsoft, but when I write the command that should convert the assembly, it tells that converting successed, but I don't find the converted exe:
This is the command:
start ngen install C:\program.exe /debug
You need a much bigger weapon to create a native win32 executable from a managed program. Ngen.exe merely pre-compiles the IL, the CLR and the original assemblies are still needed to run the program.
The kind of tool you need was somewhat popular in the early days of .NET when programmers were fretting about getting the .NET framework installed on the target machine. They are known as ".NET linkers", Salamander was popular. No idea if it has kept up with .NET versions, you definitely want to verify the trial version first. Also beware of the considerable sticker-shock you'll suffer.
I think ngen.exe installs the native image in the cache. So you don't really see it as a file on disk, but it will run when you invoke the application.
You can see what images are in the cache with
ngen display
Related
Can a C#/.NET application be compiled to native binaries using .NET Native without being a UWP application? For example, a 4.5 console app? I've watched over 2 hours of video on .NET Native and also read docs but they did not clearly answer this question.
There are not a perfect solution for this but serveral alternatives:
Native AOT, formerly called 'Core RT', which supports full native compilation from managed dlls to binary executables on the target platform(OS and CPU Arch), but it is still marked as 'experimental' (Update: merged into the mainline since .NET 7 preview) with a lot of features missing.
IL2CPP, which is developed and used only by Unity.
CrossGen, which is a part of CoreCLR and could generate .ni.dll files which contains precompiled (native code on specific platform) code rather than IL code in normal managed dll, making it faster loading. But it still requires the runtime because it is basically still a managed dll with JIT compilation already done (AOT).
Note that .NET Framework is going to be obsolete with .NET Core becoming the unified .NET, and you can easily hear from some news about native compilation support if you keep watching .NET Core things
is it possible to create a AnyCpu assembly with SWIG? I have both the x86 and x64 binaries compiled (c++) and I'm able to generate a SWIG P/Invoke Wrapper. But the wrapper is dependent on the invoked native dll (which is CPU specific). But I like the idea of let the executable decide instead of having two different executables. I'm would put the dlls in seperate folders (e.g. named x64/x86) if this is helpful. Or do I have to write a handmade wrapper in C# which decides to load the right dll?
Thanx for input.
It seems you have to roll you own wrapper.
I came across the solution CLRZMQ was using for similar reasons.
They solved it pretty well by embedding both .dll versions and extracting those accoring to the current platform:
They determined the running platform by using Environment.Is64BitProcess and adding a x86 or x64 suffixe + version string before extracting and loading the correct dll.
Here is their solution to the problem and here is the corresponding discussion which gives different ideas on how to solve it. Also interesting is their SafeLibraryHandle which I just found out about.
I am asking this question primarly to learn. Let's say I want to send a very small console application (50 lines of code Also I am using the System.Text.RegularExpresion namespace.) to a friend writen on c# on .net framework 4.0 . I will like to make the application portable therefore I just send him the output of the bin directory.
Why does he has to install the .net framework 4.0 client which it takes quite a while. Also it will be nice to include only the dll libraries that I plan on using in this case system.dll (that library contains system.text.regularexpressions namespace).
In other words why is it that I cannot include system.dll in my console application in order to make it portable and for it to work on a computer that does not have the .net framework installed.
Why is the installation of .net framework 4.0 so complex? What would happen if windows where to place all .net libraries on C:\Program Files\.net framework 4.0\ and then on the installation write a key to the registry of the path where that framework was installed so that programs are able to find the nessesary dlls.
Why are installations so complex on general?
I tried to decomplile system.dll with reflector then include that on my project and that did not worked
Edit
I guess my question should have been why .net framework 4.0 takes so long to instal? Why is it not posible to run the .net framework 4.0 if windows where to place the necessary dlls on program files and then write to the registry the path where those dlls are located. That process would have been much faster. Why not do it that way?
So in conclusion
Thanks for the help I understand now how important is the CLR. I guess the only part that I am missing to understand is why installations take so long. I understand that there are thousands of dlls. Unziping those dlls to program files and writing 10000 keys on the registry should be much more quicker.
Your question seems to boil down to "Why do I need to install the entire .NET Framework, instead of including just the required DLL's?"
The answer is that .NET Framework consists of more than just DLL's. The other major component of the framework is the CLR, which is in charge of executing and managing .NET code. The .NET Framework consists of many other smaller things (such as compilers) which are not necessary to run code, but nevertheless included with the framework.
The CLR is more important to .NET than the DLL's themselves. It is analogous to the CPU on a computer. Without it, nothing can be done, and the executable programs you have are just garbage data. The CLR takes care of JIT compiling your code to a native executable, memory management, etc. It is very similar in concept to the JVM for Java applications.
Even the DLL's are more complex than it would seem. Although you could in theory (disregarding the CLR for a minute) deploy just the dependency DLL's with your application, remember that all those DLL's (with the exception of mscorlib) have dependencies on more DLL's, and so on, including a vast number of dependencies for a simple application.
The C# programming language requires the .Net framework be installed on the target computer first, before running the target program. VB.NET and F# have the same requirement. The .net framework is a very large set of libraries, requiring more than just a couple of .DLL files, but also access to the system registry. There is a fairly deep level of integration, most of it through COM, but going deep into Win32 (at least for WinForms).
Now, Microsoft could have make C# compile directly to native code, but that is not what they decided to do. These programs require the framework to be installed, by design. As it is now, the .Net framework is required. This was a bigger deal in 2001 when C# and .Net was first introduced, because everybody had to install it! Today, Windows 7 (and Vista) come with it pre-installed, making it easier to the user. For server-side (web apps), it is also not that big of a deal, because it is not a matter of installing it on many client computers
One way of looking at it would be that each program would require all of the libraries, making it more difficult to maintain bug fixes, if every program had their own collection of .Net libraries they used. With having one installation of the framework on a computer, when a bug is found, Microsoft can patch the one version of the framework, rather then the multiple locations the file(s) could be if each program had their own set of library files.
As for portability, you can use Mono to run these same .Net (C#) binaries on Linux and Mac. Of course, on those other platforms, you will still need an installation of Mono to make it work.
I'm trying to embed SQLite into my portable C# .NET 2.0 application rather than having the DLL files included in the distribution folder. However, to embed SQLite, I cannot use the Mixed-Mode libraries provided by PHXSoftware. Instead, I am using their 'Managed Only' version.
This works fine on 32-bit computers, but when it's running on a 64-bit machine, it throws a format exception. As I found out from here: http://sqlite.phxsoftware.com/forums/p/2564/9939.aspx I need to load the unmanaged sqlite3.dll manually in the required architecture format first before I use the managed libraries.
That's where I fall short. I cannot find a 64-bit version of SQLite to include along with the 32-bit one. Can anyone help? Dare I say, does anyone have any better ideas?
I'd recommend you build the source yourself. It's very straight-forward to do. Especially considering Sqlite offers amalgamation source.
Here are the compiler pre-processor defines I use for a 64-bit release build:
WIN64 NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
Here are the compiler pre-processor defines I use for a 32-bit release build:
WIN32
NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
The System.Data.SQLite fork has x86/x64 binaries for .Net 2, 3.5, and 4. Downloads are here.
Update:
Another possible solution is to target your application for x86 platform and just use the x86 SQLite libraries. If your application doesn't require x64 features targeting the x86 platform will greatly reduce the complexity of your deployment.
I've been trying to port a .NET library built on/for Windows to Ubuntu 11.04 using Mono. The library uses .NET 4.0 so the version of mono (2.6.7) that is standard with Ubuntu 11.04 doesn't cut it. Specifically, I'm trying to use Microsoft.VisualBasic.Devices.Computer.Info.TotalPhysicalMemory. I've searched high and low for packages or parallel build scripts that install Microsoft.VisualBasic.dll, but none of them do.
Ideally I'd like to find a way to get the best of both worlds, Mono with .NET 4.0 support and Microsoft.VisualBasic so that the code won't have to be modified. I would settle for an alternative that uses another method (although, the P/Invoke method I saw in this previous post does not appeal to me).
Any help is greatly appreciated.
It looks like getting VB.dll won't help you either. This method is not implemented in Mono:
https://github.com/mono/mono-basic/blob/master/vbruntime/Microsoft.VisualBasic/Microsoft.VisualBasic.Devices/ComputerInfo.vb
You could try to fool Cudafy by creating your own version of the DLL.
Use reflector or check here to see the interface
https://github.com/mono/mono-basic/blob/master/vbruntime/Microsoft.VisualBasic/Microsoft.VisualBasic.Devices/ComputerInfo.vb
You can use a performance counter on Mono to actually get the amount of memory;
var pc = new PerformanceCounter("Mono Memory", "Total Physical Memory");
var mem = pc.RawValue();
You can use the MoMA tool to check how compatible mono is for your project.
In your particular case the method you need isn't implemented, if that's the only thing preventing your project from working, you can implement it, and build and provide your own MS.VB.dll until mono releases a version with the change in it. Once you've built mono-basic it's simple to install on any machine (with mono already installed), just run:
gacutil -i path/to/MS.VB.dll
and the dll will be installed into the gac.