.NET: How do I make a NATIVE executable with C# / VB.Net code?

Actually, I don't think that's possible. Not that I know of at least.

Why do you want to build a native application with it? You lose all the benefits of the framework if you do that.

---

VSEDebug Visual Studio.NET Add-In. Enhances debugging in ways never thought possible.

[edited by - CpMan on November 19, 2003 11:42:52 PM]

[edited by - CpMan on November 19, 2003 11:46:00 PM]

Why: It''s simple. I want an app to be able to run on Win98 w/o the user needing to download the .NET runtime.

Well, the platform that the .NET compiler targets is .NET, thus, without the .NET framework, you can''t run a .NET application. .NET ...it''s so hot right now... .Net

You need to have the framework installed. There''s no way around it. There is no "static linking" as there was with MFC.

The bright part about it is that, once the user downloaded the 20 MB install for the .NET framework, a useful application is tiny; often less than 100 KB in release mode.

There''s a lot behind the framework, more than just a library.

---

VSEDebug Visual Studio.NET Add-In. Enhances debugging in ways never thought possible.

ngen.exe makes native Windows executables, but it just cuts out the JIT step. You still depend on the .NET libraries.

my understanding is the only way to make programs that compile into native machine code and don''t depend on .NET (using visual studio .net) is to use C++ with Win32 API and don''t compile with the /clr switch... I think even then you depend on a run time library but I''m not sure


If you''re really hardcore about supporting Win98 (which in my opinion is an admirable quality) you might also consider finding a copy of VB 6 for real cheap... although, there is a big difference from a programmer perspective between VB 6 and VB.Net

quote:

---

Original post by antareus
ngen.exe makes native Windows executables, but it just cuts out the JIT step. You still depend on the .NET libraries.

---

More than that - you still depend on the original assemblies. You cannot reflect on an ngen''ed image.

--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]

quote:

---

Original post by Arild Fines

quote:

---

Original post by antareus
ngen.exe makes native Windows executables, but it just cuts out the JIT step. You still depend on the .NET libraries.

---

More than that - you still depend on the original assemblies. You cannot reflect on an ngen''ed image.

--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]

---

True, but if you had no need for reflection, then it would be ok.

---

VSEDebug Visual Studio.NET Add-In. Enhances debugging in ways never thought possible.

AFAIK it''s not possible. Just make the 98ers install the framework. :-)

it is 100% not possible, as even in these langauges even the keywords are .NET objects ... here''s a C# example,

keyword == .NET library entity

object == System.Object
string == System.String

so you just plain and simple cannot program with the Microsoft C# or VB.NET compilers in any way which does not require a .NET runtime on the clients computer ...

Visual C++ can still generate executables that require absolutely no runtime libraries at all - just don''t use the .NET or MFC projects.

quote:

---

Original post by CpMan

quote:

---

Original post by Arild Fines

quote:

---

Original post by antareus
ngen.exe makes native Windows executables, but it just cuts out the JIT step. You still depend on the .NET libraries.

---

More than that - you still depend on the original assemblies. You cannot reflect on an ngen''ed image.

---

True, but if you had no need for reflection, then it would be ok.

---

It''s not quite that simple, I''m afraid. The runtime reflects on your assemblies all the time for various purposes: Assembly loading, verification, security etc...

It is quite simply not possible to run a managed program without having the original assemblies available.

quote:

---

Original post by Xai
Visual C++ can still generate executables that require absolutely no runtime libraries at all - just don''t use the .NET or MFC projects.

---

I''d say you''d still have dependencies on user32.dll and kernel32.dll

quote:

---

Original post by Arild Fines

quote:

---

Original post by Xai
Visual C++ can still generate executables that require absolutely no runtime libraries at all - just don't use the .NET or MFC projects.

---

I'd say you'd still have dependencies on user32.dll and kernel32.dll

---

You can get rid of that by disabling linking of the standard libraries and writing your entry point as a CRT entry point instead of main or WinMain. I just tested it and it generated an exe that has no dependencies according to depends.exe (the VS Dependency Viewer)

[edited by - extrarius on November 20, 2003 2:16:01 PM]

If you want to make a native exe, why are you using .NET anyway.

as mentioned above, VC can generate console apps that require no external libraries ... this is not the norm, but it may be done ... it is possible to limit your program to using nothing which isn''t defined in statically linkable libraries ...

quote:

---

Original post by Xai
as mentioned above, VC can generate console apps that require no external libraries ... this is not the norm, but it may be done ... it is possible to limit your program to using nothing which isn''t defined in statically linkable libraries ...

---

But you couldn''t do anything usefull, could you? You can''t interact with the OS (at least not windows), so you couldn''t display anything, get any input, save a file, etc. I guess if you used a debugger with your program you could see the value of variables, but that seems terribly inconvenient.

quote:

---

Original post by Boops
If you want to make a native exe, why are you using .NET anyway.

---

Maybe he likes c# better than c++. Or VB.net better than VB 6. But as others have told, it''s not possible, to compile those langages to native code. They are too tightly integrated with the .net framework.

quote:

---

ngen.exe makes native Windows executable

---

This is not correct—at least not in the way that one would expect. Ngen precompiles an assembly and stores that in the Global Assembly Cache. This precompiled assembly is effectively inaccessible, and the original executable is completely unmodified.