[RudiVisser]

I'm currently in the process of writing a bootstrapper for a project that requires .NET 4, you know, something that will say "hey, you don't have .net! get it".

Something very simple in theory and my first go-to for this was a simple Visual C++ app. Then that got me thinking, since I'm using VS2012 the MSVC++ 2012 runtime dll will be referenced, which is just another dependency on the bootstrapper, albeit not the main app.

So then I started thinking again, although my bootstrapper may seem like a seemingly useless/reinvent-the-wheel project, how would you do it?

I know the most obvious solution is to statically link against the runtime library from VS, but this is going to increase size of the app which is something I'd rather avoid. Would a better option be perhaps to statically link against some smaller runtime library? I've seen the Tiny C Runtime which might be a good option.

[tlhIn`toq]

Why are you writing all that when there are off the shelf solutions created by teams that specialize in that?

InstallShield
AdvancedInstaller

[RudiVisser]

RudiVisser, on 16 August 2012 - 11:02 AM, said:

So then I started thinking again, although my bootstrapper may seem like a seemingly useless/reinvent-the-wheel project, how would you do it?

For this reason

I'm aware the project is somewhat useless but that is not so much the question, just a question of how different people would achieve the goal of producing a lightweight, dependenciless (in a way) executable.

This post has been edited by RudiVisser: 16 August 2012 - 07:20 AM

[Skydiver]

I've gone down that bootstrapper route before in the early .NET 2.0 Framework days when even the 1.1 framework was still an optional Windows Update. Even worse, the .MSI also had some C++ custom actions that required the latest MSVCRT redistributables. So my bootstrapper had to install the C++ redist, .NET Framework, and MDAC as well. It was "interesting" to say the least especially trying to have some kind of progress bar for the .NET Framework and MDAC installs.

Anyway, I would go the same route I did the first time around. I did a static link of the CRT and assumed that the linker stripped away everything that I didn't use. (Actually, I do remember spending an afternoon inspecting the .MAP file just to double check.) I was pretty careful to limit myself to using only a C runtime library call only if I really needed it. If there was an equivalent function in the USER.dll, KERNEL.dll, or ShlWApi.dll, I would use that instead. (eg. lstrlen() instead of strlen(), wsprintf() instead of sprintf(), CopyMemory() instead of memcpy(), IsCharAlpha() instead of isalpha(), etc.) Fortunately, that was sufficient.

I was prepared to also link against ntdll.lib which also has it's own subset of the CRT, but fortunately I didn't need to go down that route. (If you do a dumpbin on ntdll.dll, you'll see all kinds of useful CRT functions. If you install the DDK, you'll get ntdll.lib.)

One of my far off contingency plans was to use /delayload and call other CRT functions after the MSVCRT redistributables were installed, but thankfully I didn't need to resort to that.