.NET Stubs | Tech Off

W3bbo
The Master of Baiters

I'm looking for something that lets me add a native stub to any .NET executable that informs the user that they need to download the .NET framework (or better yet: downloads it for them) before continuing. Bonus points if it gets the x64 version for x64 systems. Oh, and it must work with ILMerge (of course, I could apply it after ILMerge has statically linked my assemblies).

I've found this, but it's too expensive. Are there any free (preferably GPL) offerings around?

EDIT: I just found that the Netcheck program I linked to is not a stub program, but something you package with your program... I don't know how they get away with charging money for it then.

staceyw
Before C# there was darkness...

Not sure I understand. A Setup package will do this as a dependency. Also a Click-Once app will do this for you (as well as other dependencies such as sql express, 3.5sp1, etc). You could also write something like NetCheck pretty easy as a native wrapper that starts your .net exe or opens URI to the framework if not installed (maybe about 10 lines of code I think).

figuerres
???

why not just have 2 .exe files

1 pure native - does a splash dialog and the checking

1 .net that is the app.

native app has the name users see , .net has other name like main.exe

that also allows loading updaters and other stuff based on startup conditions.

and leaves the standard .net exe in a default format.

Ion Todirel
buuu

interesting, so the loader will have to check for a .NET installation then if one exists load the CLR, if not show a custom warning or do something else, interesting idea, aren't there some limitations to the stub size or something? Or you can just create a whole native app and just embed somehow the managed code/il

W3bbo
The Master of Baiters

In reply to Ion Todirel

#Jun 30th @ 11:42 PM

I'm not too bothered about how it works, I'm just surprised Microsoft let the CLR specification go by in such a way that if the .NET Framework isn't installed the users just get a nondescript error message about the program failing to initialise.

Of course with the CLR now included in Windows since Vista it is kind of moot, but it would have been of great use from 2002 through 2007.

figuerres
???

In reply to W3bbo

#Jul 1st @ 4:07 AM

why?

the thing called an install program perhaps?

all retail / large apps have an installer that checks the pre-req's and install them if missing.

and if each .net app had to have more stubb code then a lot of folks would complain and look for a way to remove it...

the "xcopy deployment" of .net apps was always "once .net is installed then you can just xcopy files and run them"

W3bbo
The Master of Baiters

In reply to figuerres

#Jul 1st @ 5:17 AM

You forgot the scenario where the installer program itself is managed code Wink

AndyC

In reply to W3bbo

#Jul 1st @ 5:51 AM

True, but all the cool kids use Windows Installer and everyone who doesn't deserves to suffer.

figuerres
???

In reply to W3bbo

#Jul 1st @ 5:51 AM

that would be rather silly....

then the installer would need an installer to install the pre-req for the installer.....

DUH what?

any commercial installers i have seen are native apps with zero or very few deps for that very reason.

so they can update almost anything on the target system, and can run on a bare target pc.

staceyw
Before C# there was darkness...

In reply to Ion Todirel

#Jun 30th @ 11:42 PM

"interesting, so the loader will have to check for a .NET installation then if one exists load the CLR, if not show a custom warning or do something else, interesting idea, aren't there some limitations to the stub size or something? Or you can just create a whole native app and just embed somehow the managed code/il"

In VS, you create a setup project that installs your managed app. Basically, you are creating an .msi that windows installer can install and will check for and install the framework. So that part is done for you already for the most part. You could create your own loader, but not sure why unless the Setup project did not cover all your bases. IIRC, if you create your project as a ClickOnce app, then you get framework dependency installed also. Another reason you always will have to worry about this (and should create a setup package) is because many times you are targeting newer versions of the framework (i.e. 3.5, 4.0, etc) so older versions already on the system will not help anyway, so you should probably always assume your fx is not installed. Then you always have a nice unit of deployment.