CLR to Binary ???

  • Thread starter Thread starter Nadav Rubinstein
  • Start date Start date
N

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.
 
Hello,

Nadav Rubinstein said:
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 )...
Click to expand...

http://www.lesser-software.com/ is working on a tool that will allow
this. IMO this doesn't make sense.

Regards,
Herfried K. Wagner
 
Isn't Ngen.exe intended to be used on the client machine? My understanding
is that it works by compiling the code to native code that is optimized for
that particular machine. Unfortunately, that prevents the developer from
using it to distribute native DLL's/EXE's to clients (unless they have an
identical hardware setup.)
 
Hello,

Robert Jacobson said:
Isn't Ngen.exe intended to be used on the client machine?
Click to expand...

You are right. AFAIR it's recommended to use it on the client computer
when installing the application if necessary.

Regards,
Herfried K. Wagner
 
Sure - use the Ngen.exe (Native Image Generator) utility which comes with
the .NET framework.

This will convert your CLR DLL/EXE to a native file image. It even slightly
speeds up load times for your app, since you don't get the perf hit from the
JIT compiler. On the other hand, you lose the benefit of the JIT optimizer
which can optimize MSIL instructions to CPU specific machine code.

Hope that helps.

Cheers,
Wim Hollebrandse
http://www.wimdows.com
http://www.wimdows.net
 
Wim,
However that makes absolutely no sense.

For these images to be used you need to have the Framework installed, if you
have the Framework installed, you will have ngen on that machine. If ngen is
on that machine, why bother with ngen on other machine first?

Also ngen "creates a native image from a managed assembly and installs it
into the native image cache on the local computer". Notice that part about
"*installs* it into the native image cache". I strongly suspect that if I
ngen an assembly, find it in the cache (which I am sure is undocumented).
Copy this image to another machine, I would need to put it in the image
cache. I suspect the fact an image is in the cache is recorded someplace...
Why go through all the trouble, if I can simply ngen it on the target
machine and be done with it.

Just a thought
Jay
 
Jay,

Not saying it makes sense. I'm not advocating using Ngen at all. Rather the
opposite. I was just thinking of reasons why someone would Ngen the
assemblies and then deploy. Ngen'ing on all client machines would hinder
deployment. The other reason as to why one would ngen an assembly or
exectutable is for improvement of the initial JIT performance hit.

Regards,

Wim Hollebrandse
http://www.wimdows.com
http://www.wimdows.net
 
Hi Nadav,
I wonder, Is it possible to convert a CLR DLL to a Binary OS dependent DLL?
Click to expand...
No. Although you can use NGen to complie your IL to native code prior to execution and thus potentially improve the performance of your application, only your IL has been affected by this operation. Your code still has an assembly holding metadata and relies on the support of CLR. You have taken a step out of the process, the compilation of the IL, but you have not dropped your dependency on the CLR. For example the Windows Forms assemblies are (IIRC) Ngen'd to improve performance, but are still managed code assemblies and dependant on the CLR.
Sorry but you will need to install the .Net framework on your target machine in order to use the .Net framework (and this is no different as a problem from potentially having to install any other library your code depends on, and in fact should be easier, becuase the CLR takes measures to overcome the resulting problems of DLL hell).
HTH,

Ian Cooper
wwww.dnug.org.uk
 
Back
Top