By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,457 Members | 1,301 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,457 IT Pros & Developers. It's quick & easy.

Loading mixed-mode application without .NET installed

P: n/a
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
Nov 17 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:e8**************@TK2MSFTNGP15.phx.gbl
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.


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
Nov 17 '05 #2

P: n/a
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
"Igor Tandetnik" <it********@mvps.org> wrote in message
news:um**************@TK2MSFTNGP14.phx.gbl...
"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:e8**************@TK2MSFTNGP15.phx.gbl
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.


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

Nov 17 '05 #3

P: n/a
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

"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:uG**************@tk2msftngp13.phx.gbl...
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
"Igor Tandetnik" <it********@mvps.org> wrote in message
news:um**************@TK2MSFTNGP14.phx.gbl...
"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:e8**************@TK2MSFTNGP15.phx.gbl
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.


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


Nov 17 '05 #4

P: n/a
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
"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message
news:e3**************@TK2MSFTNGP15.phx.gbl...
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

"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:uG**************@tk2msftngp13.phx.gbl...
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
"Igor Tandetnik" <it********@mvps.org> wrote in message
news:um**************@TK2MSFTNGP14.phx.gbl...
"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:e8**************@TK2MSFTNGP15.phx.gbl
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.

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

Nov 17 '05 #5

P: n/a
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
"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:u0**************@TK2MSFTNGP12.phx.gbl...
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
"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message
news:e3**************@TK2MSFTNGP15.phx.gbl...
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

"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:uG**************@tk2msftngp13.phx.gbl...
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
"Igor Tandetnik" <it********@mvps.org> wrote in message
news:um**************@TK2MSFTNGP14.phx.gbl...
"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:e8**************@TK2MSFTNGP15.phx.gbl
> 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.

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


Nov 17 '05 #6

P: n/a
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
"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message
news:OC*************@TK2MSFTNGP12.phx.gbl...
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

Nov 17 '05 #7

P: n/a
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. 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

"Staale L. Hansen" <st****@winsoft.no> wrote in message
news:Oo**************@TK2MSFTNGP12.phx.gbl... 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
"Ronald Laeremans [MSFT]" <ro*****@online.microsoft.com> wrote in message
news:OC*************@TK2MSFTNGP12.phx.gbl...
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


Nov 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.