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
Related
I have a .net 4.0 project in which I'd like to reference .net 2.0 assemblies. As I understood from this article, .net 2.0 assemblies will be loaded in 4.0 run time and backward compatibility is not assured. Is there a way to force process side by side for this case and to load 2.0 runtime?
In process side-by-side versioning is only supported for code that runs independently without having to share data. In particular for native code that loads the CLR to execute managed code. It is a solution for the CLR versioning problem, once an unmanaged program like Explorer loads the CLR, say to support a shell extension written in .NET then the CLR version is selected by whatever version that extension asked for. Which works poorly if another extension then needs a later version of the CLR. .NET 4's side-by-side versioning feature solves that, each extension gets its own CLR. No sharing of data is required, these extensions don't know about each other.
Clearly this isn't a solution for what you are trying to do. Microsoft made a lot of effort to make .NET 4.0 as compatible as possible with previous .NET releases and loading .NET 2.0 assemblies is certainly well supported. Up to a point, they did use the opportunity to fix several old bugs whose fixes could be breaking to old code. Technically it is possible that your 2.0 code relied on the behavior of such a bug, it is however not very likely. You just need to re-test your code.
I know C++ code runs on local machine directly. I also know that we can compile c# code into native code using NGen.exe. My question is
If we use Native code generator NGen.exe to compile c# code into native code, do we still need the .NET framework to run it?
In fact, if you compile your C++ code into a Windows executable you still need Win32 dlls and other stuffs. Your program cannot run on a CPU that does not have anything besides your program.
The same story for C#. If you compile C# to native code, you do not need the JIT compiler, that is part of .NET runtime. But you still need all other parts of .NET runtime.
For example, the .NET framework with all its classes is not linked into your program. If they would put all required .NET classes into your binary, a simple Hello world app would become huge.
You can use mono to build a C# app that has everything pre-compiled with statically linked framework libraries and does not need a separate runtime.
I wouldn't recommend it, though. Not everything is available for static linking, and one of the things about using a JITter is that it makes your code faster on average across all your deployments, as you can now take better advantage of machine-specific optimizations. It's also not something that even mono is set up to do out of the box.
Yes, you need the framework because the libraries your app use come from the framework.
When you use NGen not just your code is compiled on native code, chunks of framework code are 'nativized' too, just the right parts your apps use.
All this doesn't change your assembly (exe or dll) phisical bytes, this compile the IL to native and store this native bytes in compiled assembly cache.
References in compiled assembly cache still needing some framework components, specially to framework core wich is native code from the beggining.
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.
How to make pure native Exe for C#/VB.net Application? [After that No need .net framework to run that Exe]
Short answer: you can't.
Longer answer: there are programs which wrap the framework up, such as VMware ThinApp (previously known as Thinstall) - but they're still effectively using the framework, just in a different deployment form.
Even longer answer: Mono has an ahead-of-time compiler and bundler which allows it to create native apps (e.g. for the iPhone) - but I don't know what the state of play is with using that for Windows, and the normal caveats of compatibility between .NET and Mono apply.
Anything like this is likely to have significant implications if your application uses reflection, loads plug-ins etc. Personally I'd advise against it unless you've got a really good reason for not just installing the normal framework.
Do you know any ways to run a C# project under Linux. Are there any framewoks or libraries for this?
You're looking for the Mono Project - a cross-platform (but primarily targeted at Linux) implementation of the .NET Framework and CLR. It's capable of running binaries compiled for the CLR (MS .NET), or of creating its own native Linux binaries.
The project has been going a while now, and it's current version (2.4) is very usable, even for production purposes. See the project roadmap for details of the main features and milestones of current and future releases.
Details about the current state:
The great majority of the BCL (Base Class Library) is available on Mono, with the exception of some of the .NET 3.0/3.5 stuff, such as WPF (which has minimal support currently) and WCF (almost non-existent support). Silverlight 2.0 is however being supported via the Moonlight project, and progress on that is going well. WinForms functionality (which uses GTK# as a backend) is however quite complete, as far as I know.
Implementation of the C# 3.0 language is effectively complete, including the C# 3.0 features such as lambda expressions, LINQ, and automatic properties. I believe the C# compiler is mature to the point that its efficiency is at least comparable with that of the MS compiler, though not yet matching it in some respects. What's quite cool (and unique) about the Mono C# compiler is that is now offers a compiler service - in other words true dynamic compilation from code (without using the CodeDOM). This is something that MS will perhaps only add in .NET 5.0.
Like others have already said, you can run .NET applications on Mono. If your applications use Platform Invocation (P/Invoke) to call native code, you may run into some trouble if there is no Mono implementation of the native library. To check whether your application does that (or uses APIs that haven't been implemented in Mono yet), you can use the Mono Migration Analyzer (MoMA).
For those who come across this question post 2016, can use .NET Core - An open-source, general-purpose development platform maintained by Microsoft and the .NET community on GitHub. It's cross-platform (supporting Windows, macOS, and Linux) and can be used to build device, cloud, and IoT applications.