Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / December 2007

Tip: Looking for answers? Try searching our database.

Check .NET Framework exists from managed assembly

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Chris - 03 Dec 2007 21:14 GMT
Hi,

I have a managed C++ program that needs to check if the .NET framework v1.1
exists each time it runs. I wish I only had to do this at installation time
but users have removed the framework and encountered a crash and entered
complaints so I have to add the check.

I know how to do this as a seperate utility app that would then launch my
executable but I would like to avoid any additional utility apps or
assemblies. Is there any way to check this from a managed assembly without it
crashing when the .net framework does not exist?

I believe the crash will occur as soon as the managed code is loaded, is
this right? I don't know when this happens though. I tried to add some
unmanaged code before any managed code is called but it still crashes first.

Any help would be greatly appreciated.

Thanks,
Chris
Vadym Stetsiak - 03 Dec 2007 21:53 GMT
Hello, Chris!

If there is no .NET Framework installed then no managed can be executed.
If you want to detect if .NET is present you can do that through purely
unmanaged code (without the /clr switch for C++).

--
With best regards, Vadym Stetsiak.
Blog: http://vadmyst.blogspot.com

You wrote  on Mon, 3 Dec 2007 13:14:33 -0800:

C> Hi,

C> I have a managed C++ program that needs to check if the .NET
C> framework v1.1  exists each time it runs. I wish I only had to do
C> this at installation time  but users have removed the framework and
C> encountered a crash and entered  complaints so I have to add the
C> check.

C> I know how to do this as a seperate utility app that would then
C> launch my  executable but I would like to avoid any additional
C> utility apps or  assemblies. Is there any way to check this from a
C> managed assembly without it  crashing when the .net framework does
C> not exist?

C> I believe the crash will occur as soon as the managed code is loaded,
C> is  this right? I don't know when this happens though. I tried to add
C> some  unmanaged code before any managed code is called but it still
C> crashes first.

C> Any help would be greatly appreciated.

C> Thanks,
C> Chris
Chris - 03 Dec 2007 22:38 GMT
Thanks Vadym for responding,

Even with the /clr switch they are compiled on a function by function basis.
So is it possible to use something like (psydo code):

#prama unmanaged

int CheckDotNETFrameworkExists()
{
   if ( ! //check dot net framework exists here )
   {
       MessageBox(0, "test", "test", MB_OK);
       return 1;
   }
}

int APIENTRY _tWinMain(HINSTANCE hInstance,
                                   HINSTANCE hPrevInstance,
                                   LPTSTR    lpCmdLine,
                                   int       nCmdShow)
{
   if ( CheckDotNETFrameworkExists() )
       exit(1);

   return ManagedMainFunction(...);
}

#prama unmanaged

int ManagedMainFunction(...)
{
// main function
}

I have not been able to get it to not crash without the .net framework so
far though.

Thanks,
Chris

> Hello, Chris!
>
[quoted text clipped - 31 lines]
>  C> Thanks,
>  C> Chris
Chris - 03 Dec 2007 23:08 GMT
To elaborate,

When do the managed assemblies get loaded? If I can call unmanaged code
before hand I would be able to check it then.

Thanks,
Chris

> Thanks Vadym for responding,
>
[quoted text clipped - 71 lines]
> >  C> Thanks,
> >  C> Chris
Michael Nemtsev [MVP] - 04 Dec 2007 06:53 GMT
Hello Chris,

why not to check the registry entries for .NET existence?

it's installed into specific hives and can be easily tracked

---
WBR,
Michael  Nemtsev [.NET/C# MVP] :: blog: http://spaces.live.com/laflour 

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

C> To elaborate,
C> When do the managed assemblies get loaded? If I can call unmanaged
C> code before hand I would be able to check it then.
Prashant - 04 Dec 2007 09:25 GMT
As Michael already mentioned, please refer to the below link on registry key
detail
http://support.microsoft.com/default.aspx?scid=kb;%5BLN%5D;315291

> Hello Chris,
>
[quoted text clipped - 12 lines]
> C> When do the managed assemblies get loaded? If I can call unmanaged
> C> code before hand I would be able to check it then.
Chris - 04 Dec 2007 14:13 GMT
Thanks for the responses,

Checking if the registry values exist is not a problem, going back to the
original question, the problem is needing to check from a managed project. I
was told that I cannot add any new assemblies to our installation so I need
to know if it is even possible to do. Can I call unmanaged code in a managed
project in a way that the managed code is not loaded until after I check the
registry with unmanaged code? Therefore, the executable will not crash before
the check allowing me to show a dialog if the .net framework does not exist.

Thanks,
Chris

> As Michael already mentioned, please refer to the below link on registry key
> detail
[quoted text clipped - 16 lines]
> > C> When do the managed assemblies get loaded? If I can call unmanaged
> > C> code before hand I would be able to check it then.
Prashant - 05 Dec 2007 12:04 GMT
If you have managed executable this is how it works.The operating system
loader checks for managed modules by examining a bit in the common object
file format (COFF) header. The bit being set denotes a managed module. If the
loader detects managed modules, it loads mscoree.dll, and _CorValidateImage
and _CorImageUnloading notify the loader when the managed module images are
loaded and unloaded.
You won't be able to turn off/on the bit in COFF header by running the
managed executable. Its not possible to run Managed Executable without CLR
which in turn need .net assemblies

But you could probably write an executable in unmanaged code to check for
.net framework and display a dialog box if it doesn't exist and if it does
exists you could launch your managed executable from your unmanaged code and
terminate the unmanaged exe.Managed exe will impersonate the calling process
security access token.

If your application is being deployed you could also make use of the
installation script to warn users.

> Thanks for the responses,
>
[quoted text clipped - 29 lines]
> > > C> When do the managed assemblies get loaded? If I can call unmanaged
> > > C> code before hand I would be able to check it then.
Chris - 06 Dec 2007 20:38 GMT
I am already checking it in the installation script but apparently too many
people decide to uninstall the .net framework at some point. I will probably
just launch my app from an unmanaged exe like you suggested.

Thanks for the help,
Chris

> If you have managed executable this is how it works.The operating system
> loader checks for managed modules by examining a bit in the common object
[quoted text clipped - 48 lines]
> > > > C> When do the managed assemblies get loaded? If I can call unmanaged
> > > > C> code before hand I would be able to check it then.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.