CLR to 8086

[Nadav Rubinstein]

Hi,

I wonder, Is it possible to convert a CLR DLL to a Binary
OS dependent DLL?
Explained:
The JIT compiler 'converts' the CLR DLLs to binary on
runtime ( dependent of the OS ), Is there a way for the
JIT to generate a 8086 EXE binary??? doing so will enable
Converted CLR applications to run on computers without
the CLR framework ( the virtual machine )...

Thanks in advance,
Nadav Rubinstein.

 

[Jay B. Harlow [MVP - Outlook]]

Nadav,
There are currently no native code compilers for .NET, only the JIT
compilers.

There is a Native Image Generator (ngen.exe) utility in .NET that you can
pre-JIT your assemblies in the GAC. However you need to install the
Framework on the machine, install your assembly on the machine, then use
ngen.exe.

I do not have any links, there are a couple of companies working on native
code compilers, that claim they will package enough of the framework to run
your app.

The problem I see is: even if you create a native code assembly, you still
need all the runtime assemblies. Which means you would need to compile these
to native code also. Which means you will need to install them. Where are
you going to install them. Side by Side with the App? An awful lot of disk
space if I install two native code assemblies. Is runtime common someplace,
sounds like its approaching the return of DLL hell. Or at the very least a
duplication of the existing runtime...

Hope this helps
Jay

 

[Nadav Rubinstein]

Well,

I am writing client side applications that should be
compatible with OS of Win98 and above which has no .NET
framework installed, I am just trying to see if I can
avoid writing this client side Forms app with MFC or VB6,
the .NET Forms technology makes development much faster,
BUT working with .NET Forms will require each client to
download the .NET framework ( about 20MB ) which is not
acceptable, 'converting' the CLR binaries to native
binaries may be a nice compromise, BUT as you say it is
not so elegant.

Does anyone has any suggestion????

 

[Jay B. Harlow [MVP - Outlook]]

Nadav,
Search Google Groups:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=microsoft.public.dotnet

For the reference to native code compilers (and other similar keywords).

There have been postings from at least one company working on a native code
compiler for .NET. I just don't remember the name of the company.

'converting' the CLR binaries to native
binaries may be a nice compromise, BUT as you say it is
not so elegant.

Is your app download ware? Or distributed on CD?

If its download ware, for users who do not have the Framework loaded, offer
to ship a CD with the Framework on it, so they may load it.

The problem with converting the CLR binaries to native binaries, may still
be you are looking at 10-15 MB download, as a lot of the framework is
inter-related.

BUT working with .NET Forms will require each client to
download the .NET framework ( about 20MB ) which is not
acceptable,

I would not consider it not acceptable, inconvenient yes, prohibitive for
dial up lines, yes. For dial up users, you can always offer to ship them a
CD.

I am just trying to see if I can
avoid writing this client side Forms app with MFC or VB6,
the .NET Forms technology makes development much faster,

Like any project you need to weigh the benefits of a tool with the pit falls
of a tool. If MFC or VB6 are more easily deployed for you, and deployment is
important. Then I suggest you go with MFC or VB6. For me the OOP nature of
..NET, speed of development, etc. Far outweighs the deployment of the
framework issue. Remember the Framework only needs to be installed a single
time per version on a users desktop. Once there it can be used by numerous
apps. With in limits 1.0 apps can use 1.1 framework and visa versa. For
details see:

http://msdn.microsoft.com/netframew.../library/en-us/dnnetdep/html/sidexsidenet.asp

Hope this helps
Jay