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.
Related
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
Can Ngen be used as the perfect Code Obfuscator, protecting your .NET CIL from ever reaching the client?
Can I run Ngen on my dev PC and ship the exe to every client that has a compatible .NET framework version? (assuming both are x86 or x64) What are the differences between Ngen'd exe's across machines?
I know the latest Ngen generates an exe that contains the IL + Native code, which can be extracted and "converted" back to source code using something like Reflector. However, the ngen for .NET framework 1.1 strips out the IL in the generated exe, making it a possible choice for code security if you use .NET framework 1.1.
No, CLR requires IL assembly in order to locate the corresponding native image. So you would need to distribute IL binaries anyways.
See this page for more info on how CLR locates Native Images: http://blogs.msdn.com/b/abhinaba/archive/2013/12/11/net-loading-native-ngen-images-and-its-interaction-with-the-gac.aspx
Besides, NGEN images are not designed to be distributed. Native image generation is tightly coupled with the machine it runs on.
I am having problem with understanding what FEATURE_PAL compiler directive means in .net 4.0 source code. It is used almost in every class that access unmanaged code.
PAL = Platform Adaptation Layer. It is first and foremost a detail of the CLR, insulating it from the operating system implementation. You'll indeed see it used in the Reference Source copy of the source code for the .NET 4 classes. It appears in any code that has a strong dependency on the underlying operating system implementation, bypassing such code since it cannot work on an operating system other than Windows.
You may be familiar with the use of the DEBUG and RELEASE directives to wrap blocks of code specific for testing/production code.
The .NET 4.0 framework uses the FEATURE_PAL compiler directive to execute code on newer platforms. It has to adapt to the platform by calling native methods found in native dlls. Hence the name of the feature: 'Platform adaptation layer'.
I came across this post after looking at the code for the Process class. One can image that killing a process works different on a given platform.
Think of the your code running on a newer version of Windows installed on a device that uses an ARM processor. When killing a process you need to call a method inside a native dll tailored to that platform.
So when compiling the framework for such platforms the FEATURE_PAL compiler directive is set as 'conditional compilation symbol'.
There's a program written entirely in C# that targets .NET Framework 2.0.
Is there a way I could somehow compile (translate) managed EXE to a native one so it could be .NET-agnostic? I know there are probably commercial products for that purpose... but they are a bit expensive.
The problem is that we are to deploy the program on computers running Windows XP with no .NET Framework installed. There's also a requirement that the program's size must not exceed 500Kb (1Mb maximum) for it is downloaded from the web server (now the size is 255Kb). That is why there's no way we could attach a full-fledged .NET FX (or even a reduced one) to the downloaded program's file.
Obviously it is a terrible software engineering error that should have been detected and avoided earlier so we could use native technologies like C++ instead.
We have tried for now Novell's Mono - an open-source implementation of .NET Framework for Linux, MAC and Windows. Mono consists of C# Compiler, IDE, runtime (CLR) and Class Library assemblies (like System.dll and mscorlib.dll - much like .NET's class library assemblies installed to GAC).
What we tried to do is to locate CLR files and ship those along with our program's file and a few assemblies. This way the program can be invoked by running "mono program.exe" (command prompt) on a user's computer.
In addition to the inconvenience of such a use for the end user CLR files (mono.exe and mono.dll) turned out to be about 2.5 Mb in total that is much greater than the desired 500 Kb or even 1 Mb.
So, we have left with no other option but to translate our .NET App to a native one by a compiler, however the question remains - what compiler should we use and where could we find one...
For now I have stumbled upon a Singularity OS Project by Microsoft Research. It is an open-source research OS that is written in managed code (in part at least). The Singularity OS includes a Bartok compiler that the OS uses in order to translate a managed program to a native one (x86 32 bit). It should be noted that Bartok can't translate all the aspects of .NET 2.0 to a native code, but most of them. However I haven't yet learnt how to use the Singularity...
I would be really grateful to you if you could provide me with some useful tips and advice regarding the problem, your own experience with Singularity OS and Bartok Compiler or another approaches to the problem that I have overlooked and ways of solving it.
Thank you very much in advance!
Finally, using Mono's Full AOT feature (on Callum Rogers' advice) I've managed to produce a program.exe.dll that lacks a CLI header.
So it looks to me like a native dll. However I can't figure out how to convert that dll into exe or make it operational.
Also this dll doesn't seem to expose any functions of interest such as main function.
Check out AOT (Ahead Of Time) Compilation from the Mono project. This compiles your managed project into a native exe or an elf executable (depending on which system you target) that does not need the JIT. This is the technique used to get mono apps onto the iPhone (where the JIT/Framework are not allowed) and also has the added benefits of faster startup times, lower memory usage and it makes it harder for people to decompile your code. You said you were already using Mono, so it should be compatible.
Read up about it at the mono-project.com website and at Miguel de Icaza's blog (and iPhone info).
Note that you cannot use dynamic code or generic interfaces like
interface IFoo<T> {
...
void SomeMethod ();
}
And you will have to compile the DLLs of all the libraries you use.
PS: Make sure to use "Full" AOT for your problem.
2018 Update
At Build 2018, Microsoft announced .Net Core 3.0 roadmap that support Windows desktop applications (Winform & WPF)
2017 Update
For console apps, you can use .net core Self-contained deployments (SCD). Even for a hello world app, your package will 50MB+. You still need to install VC runtime though.
Update
As #jenix's comment, .NET Native is only for Windows Store Apps(UWP). After 3 years of it's announcement, this is still true, .net native for desktop may be dropped by microsoft . So this answer is not applicable anymore.
========
Microsoft Announced .NET Native Preview on Build 2014
With the .NET Native Developer Preview, apps will get deployed on end-user devices as fully self-contained natively compiled code, and will not have a dependency on the .NET Framework on the target device/machine. So, no .NET framework required on the target machine with .NET Native.
Announcing .NET Native Preview
Microsoft .NET Native
There is a project called CrossNet that parses .Net Assemblies and generates unmanaged C++ code, that can be compiled in any standard compiler.
Not really a solution for .NET to native conversion, but maybe this helps: http://www.yoda.arachsys.com/csharp/faq/#framework.required
Not quite sure that there is much you can do besides painstakingly rewrite the application. To ease the already burdening process, you could disassemble the .NET application using something like Reflector (into Microsoft C++), and use that as a base to start and just replace managed C++ references with native ones.
I just want the ECMA language translated into native code with the fundamental runtime (garbage collector) etc. I'm not talking about .NET just the language specification of C#.
Using C# like any other native compiling language as a langauge alternative for Delphi, D or C++ because it offers generics, expanded types, garbage collection and many other nice features. As a langauge it's pretty nice.
But i don't like .NET nor do i find it very portable (.NET for PA-RISC's HP-UX anyone?).
So a compilation to C99 would be much, much better then compilation to native (that’s how it works very well for Eiffel).
The Mono framework has support for native compilation, which they call Ahead Of Time (AOT) compilation. More here: http://www.mono-project.com/AOT
Maybe the Salamander .NET Mini-Deployment tool may help you, it does convert the code to native and has an embedded runtime, so that you don't need the .NET framework for deployment.
Singularity RDK uses Bartok. Also the .Net Micro Framework has several native compilers (last I used the Micro Framework it did not have a native x86 compiler).
A third party option would be to use the Salamander .NET Linker
Microsoft's Native Image Generator (NGEN) is capable of converting .NET assemblies into native programs. However, it only means that the JIT compiler is being bypassed, and the .NET Framework is still required to be installed.
The Native Image Generator (Ngen.exe)
is a tool that improves the
performance of managed applications.
Ngen.exe creates native images, which
are files containing compiled
processor-specific machine code, and
installs them into the native image
cache on the local computer. The
runtime can use native images from the
cache instead of using the
just-in-time (JIT) compiler to compile
the original assembly.
Perhaps you could elaborate on the context in which you need native code for your .NET assemblies? Depending on the purpose, NGEN may be good enough, though a tool that actually eliminates dependencies on the .NET Framework may be what you want.