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

Why application is allowed to run if dependent assembly is missing

P: n/a
I notice the following strange behavior of the applications running under
..NET Framework.

Let say I have application MyApp.exe which reference assembly MyAssembly.dll.
The MyAssembly.dll is strong named assembly, which is installed in the GAC.

I notice that if MyAssembly.dll is not installed in GAC or the different
version
of MyAssembly.dll is installed in GAC then MyApp.exe starts OK. But as soon as
the MyApp.exe app tries to call any function from the MyAssembly.dll the
MyApp.exe
application crashes.

In unmanaged VC++ 6.0 world the application wouldn't even allowed to start
if some dll are missing. The system would display error message saying that
some dll's are missing and application would gracefully exit.

I wonder whether I misunderstand something or made any mistake? Why
MyApp.exe is allowed to start in order to crash right after attemp to use any
functionality from missing dependent assembly?

Can anyone clarify this situation?
Thanks
Boris
Nov 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Hi Boris,
I notice the following strange behavior of the applications running under
.NET Framework.

Let say I have application MyApp.exe which reference assembly MyAssembly.dll. The MyAssembly.dll is strong named assembly, which is installed in the GAC.
I notice that if MyAssembly.dll is not installed in GAC or the different
version
of MyAssembly.dll is installed in GAC then MyApp.exe starts OK. But as soon as the MyApp.exe app tries to call any function from the MyAssembly.dll the
MyApp.exe
application crashes.

In unmanaged VC++ 6.0 world the application wouldn't even allowed to start
if some dll are missing. The system would display error message saying that some dll's are missing and application would gracefully exit.

I wonder whether I misunderstand something or made any mistake? Why
MyApp.exe is allowed to start in order to crash right after attemp to use any functionality from missing dependent assembly?


Nope; it's working just as expected. The runtime will only load an assembly
when it needs to. This, btw, helps insure you don't load things you're not
gonna use, and, it enables some interesting scenarios with web-distributed
rich client applications (since you only have to download when you use it;
what you don't use doesn't need to be transferred at all!)

--
Tomas Restrepo
to****@mvps.org
Nov 17 '05 #2

P: n/a
OK, this is not , this is "feature".
But how can I prevent the ugly crashes in described above situation and exit
gracefully?

Thanks
Boris

"Tomas Restrepo (MVP)" wrote:
Hi Boris,
I notice the following strange behavior of the applications running under
.NET Framework.

Let say I have application MyApp.exe which reference assembly

MyAssembly.dll.
The MyAssembly.dll is strong named assembly, which is installed in the

GAC.

I notice that if MyAssembly.dll is not installed in GAC or the different
version
of MyAssembly.dll is installed in GAC then MyApp.exe starts OK. But as

soon as
the MyApp.exe app tries to call any function from the MyAssembly.dll the
MyApp.exe
application crashes.

In unmanaged VC++ 6.0 world the application wouldn't even allowed to start
if some dll are missing. The system would display error message saying

that
some dll's are missing and application would gracefully exit.

I wonder whether I misunderstand something or made any mistake? Why
MyApp.exe is allowed to start in order to crash right after attemp to use

any
functionality from missing dependent assembly?


Nope; it's working just as expected. The runtime will only load an assembly
when it needs to. This, btw, helps insure you don't load things you're not
gonna use, and, it enables some interesting scenarios with web-distributed
rich client applications (since you only have to download when you use it;
what you don't use doesn't need to be transferred at all!)

--
Tomas Restrepo
to****@mvps.org

Nov 17 '05 #3

P: n/a
Exception Handling :-)

--
Regards,
Nish [VC++ MVP]
http://www.voidnish.com /* MVP tips tricks and essays web site */
http://blog.voidnish.com /* My blog on C++/CLI, MFC, Whidbey, CLR... */
"Boris" <Bo***@discussions.microsoft.com> wrote in message
news:45**********************************@microsof t.com...
OK, this is not , this is "feature".
But how can I prevent the ugly crashes in described above situation and exit gracefully?

Thanks
Boris

"Tomas Restrepo (MVP)" wrote:
Hi Boris,
I notice the following strange behavior of the applications running under .NET Framework.

Let say I have application MyApp.exe which reference assembly

MyAssembly.dll.
The MyAssembly.dll is strong named assembly, which is installed in the

GAC.

I notice that if MyAssembly.dll is not installed in GAC or the different version
of MyAssembly.dll is installed in GAC then MyApp.exe starts OK. But as

soon as
the MyApp.exe app tries to call any function from the MyAssembly.dll the MyApp.exe
application crashes.

In unmanaged VC++ 6.0 world the application wouldn't even allowed to start if some dll are missing. The system would display error message saying

that
some dll's are missing and application would gracefully exit.

I wonder whether I misunderstand something or made any mistake? Why
MyApp.exe is allowed to start in order to crash right after attemp to
use any
functionality from missing dependent assembly?


Nope; it's working just as expected. The runtime will only load an assembly when it needs to. This, btw, helps insure you don't load things you're not gonna use, and, it enables some interesting scenarios with web-distributed rich client applications (since you only have to download when you use it; what you don't use doesn't need to be transferred at all!)

--
Tomas Restrepo
to****@mvps.org

Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.