Loading mixed-mode application without .NET installed

  • Thread starter Thread starter Staale L. Hansen
  • Start date Start date
S

Staale L. Hansen

We have an application which uses some mixed-mode code to expose a .NET 1.1
managed API. Only the necessary files are compiled with /clr.

We want to be able to load the application without .NET present, and then
just disable the API.
But we are not even able to give an error message when we start the
application without mscoree.dll present. We have tried delay-loading
mscoree.dll, but that did not help because the OS loader (at least on XP)
forces the initialization of .NET by running _CorExeMain() directly.

Is it possible to disable the .NET initialization?

Regards,
Ståle Hansen
 
Staale L. Hansen said:
We have an application which uses some mixed-mode code to expose a
.NET 1.1 managed API. Only the necessary files are compiled with /clr.

We want to be able to load the application without .NET present, and
then just disable the API.
But we are not even able to give an error message when we start the
application without mscoree.dll present. We have tried delay-loading
mscoree.dll, but that did not help because the OS loader (at least on
XP) forces the initialization of .NET by running _CorExeMain()
directly.
Click to expand...

Move .NET-dependent code into a separate DLL, delay-load it in your EXE.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
 
The problem is that the API is dependant of a HUGE part of the main
application, and then we also get in trouble with a lot of C++ singleton
objects. This a large native C++ application buildt from almost 100 libs /
dlls. While developing we use DLLs, and everything is OK. But the company is
not willing to ship the application like that, and the release version is
therefore statically linked (including at statically linked mixed-mode
assembly). Making "call-back interfaces" is just not an option, as it is way
too much work.

Kind regards,
Ståle
 
In the 2.0 runtime you will only load a very small piece of the .NET runtime
if you do not actually run any managed code, so if you are worrying about
load time or working set issues, they probably already aren't huge in 1.1
and are non existent in 2.0. But you do need the .NET redist installed for
the reasons you state and cannot delayload mscoree.dll. The solution Igor
suggest is the canonical one. I am not sure I understand why you would need
to use "call-back interfaces" just to be able to ship the mixed part as a
separate DLL you can delay load.

You could also create 2 versions of the application and have a shim starter
app determine whether the runtime is available and either load the .NET
enabled version of the app or the non-.Net enabled version of the app.

Ronald Laeremans
Visual C++ team
 
As the API is a very small part of the application, actually running it
without the .NET framework would be nice (with a disabled API). At least we
need an error message telling what is wrong, but the Windows XP loader just
gives the not too informative message "The application failed to initialize
properly (0xc0000135)". We would also like to get an error message when
running on 1.0, but the application crashes during load when we do that, and
we are not able to show the error message. (We linked with nochkclr.obj, but
did not, and will not use /clr:initialAppDomain.). And if we do not provide
a app.config to say that running on 1.0 is OK, the application just silently
dies with no visible messages (on 1.0 that is).

The API exposes .NET wrapper objects around the core native C++ objects, and
does therefore need to use and access most C++ classes in the core.
Statically linking means that most of the object code are duplicated into
the API dll, and that C++ singleton objects are not single anymore, so
accessing the application objects is not possible.

Kind regards,
Ståle
 
Hi Staale,

If you do NOT link with nochkclr.obj then you will get a reasonable error
message if you try to run the image on a 1.0 runtime.

I still don't completely understand why you can't delay load one dll that
contains the managed code or how it relates to having to statically link.

Ronald
 
Hi Ronald,

Thank you for your answers (and your patience...:)

Yes it is true that we get a reasonable error message, but I do not
understand why we are unable to display our own. Using very simple code that
should be backwards compatible to just display a message should be possible.

The whole solution consists of 99 projects, where one is the application,
one contains the managed code, and the rest contains various classes and
"subsystems". When we develop (debug config) this generates one application
and 98 DLLs. That is fine and works well (when we were able to handle the
"mixed dll loading problem"). But the company wants us to ship as few DLLs
as possible, one monolithic application being the goal, as it has been
previously. In the Release config everything is linked statically. But
adding the API project caused a lot of unexpected problems.

It is possible to delay load the managed (mixed) DLL, but to be able to make
the DLL it must be linked to the other projects. And since they are no
longer DLLs it must be linked statically, and that is not a working
solution. In the end we actually managed to also statically link the mixed
assembly into the application, and that works great. Except that we are now
totally dependant upon .NET being installed.

Ståle
 
Hi Staale,

You can take the checkclr.c source code in the product, modify it according
to you needs, compile it and put the .obj on the link line in front of the
CRT libs to pick up your own custom version. If you just need to output a
different message, you only need to change the _amsg_exit call right at the
end.
It is possible to delay load the managed (mixed) DLL, but to be able to
make the DLL it must be linked to the other projects. And since they are
no longer DLLs it must be linked statically, and that is not a working
solution. In the end we actually managed to also statically link the mixed
assembly into the application, and that works great. Except that we are
now totally dependant upon .NET being installed.
Click to expand...
I am probably just being dense here, but I still do not understand why you
cannot ship with a monolithic app apart from the 1 mixed mode DLL. Normally
you can decide on a module by module basis whether you statically link or
dynamically link.

Thanks.

Ronald
 
Back
Top