Warning - Microsoft updated the VC2005 CRT

[sinbad]

CPACK can be configured to use archives or create a full on NSIS based installer.

Last I checked, NSIS doesn't interface with Windows Installer, which is needed to install WinSxS binaries, so this wouldn't work. It's why I started using WiX for my installers.

It's just a massive PITA to have to install on an otherwise dev machine (an issue if you are recruiting spare hardware for network MP testing ),

Yeah I know - luckily though it's a one-shot thing so subsequent updates of your app are just an xcopy away, and that installer I posted would just need to be run once - unless MS changes the version under your feet! This is the problem I had - I shortcut the process most of time when distributing to test machines, thinking the CRT is unchanged!

Well, in the cases you want a "copy paste" install, this will not do (you need admin rights to do it right...).

An installer is an expected part of most final distributed apps though, and I think it's in the MS app design standards (if you care about that seal of approval).

The good news is that it seems that from VS 2010 - it is easy once more.

I didn't know that - that will justify the upgrade price on its own then!

[jacmoe]

CPACK can be configured to use archives or create a full on NSIS based installer.

Last I checked, NSIS doesn't interface with Windows Installer, which is needed to install WinSxS binaries, so this wouldn't work. It's why I started using WiX for my installers.

Well, I just run vcredist.exe with the silent flag from the NSIS installer. My users wouldn't know what hit them.
Anyway, pretty moot point, considering the original topic.. as I'm using VC2008 CRT.
Still, yes: it would be great just doing a simple xcopy.

[Assaf Raman]

....

Well, in the cases you want a "copy paste" install, this will not do (you need admin rights to do it right...).

An installer is an expected part of most final distributed apps though, and I think it's in the MS app design standards (if you care about that seal of approval).
....

Not always, the case I was thinking of is a user without admin rights wanting to use a firefox plug-in that uses Ogre, firefox plug-in doesn't require admin rights to install - and they are a sort of an xcopy install. I don't want to require admin to install just for the CRT.

[Borundin]

The vc_redist.exe's on Microsoft's site currently only cover the 762 version of the CRT, not 4053.

If anyone is interested there is a vc_redist.exe available on Microsoft's site that seems to work actually.
You can download it here: Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update

[Jusas]

Bumping this up, does anyone know what version of the CRT has been used in Ogre's pre-built dependencies?
I just hit the brick wall here as well, I just found out that my app requires both .762 and .4053 CRTs since some of the libraries I use have been compiled with the older CRT. It can be resolved by using Microsoft.VC80.CRT directory with the .4053 dlls + manifest and running the vc_redist.exe with .762 dlls (so the old version is found automagically by windows and the new version is found from the directory) but this requires running the exe in order to use two versions at the same time. I'd really like to go back to only having just one version of CRT which can be supplied with the executable, guaranteeing the right version, which is why I'm asking this. If Ogre or some of its dependencies have been built with .762, the problem will still remain regardless of rebuilding all my own libraries.

So... is the latest Ogre fully using .4053?

[xavier]

If you mean the SDK, not likely.

Rebuilding Ogre is not difficult. Nor is rebuilding its dependencies -- that part is just tedious.

Dependency Walker looks like it's your best friend here:

www.dependencywalker.com

[sinbad]

The newer SDK will have been built against 4053 yes, since that's what I have installed, not that it was by choice! The dependencies are probably still based on the old runtimes, but those should be installed automatically if you distribute your app properly with a Windows Installer.

I do intend to build a new set of dependencies for the upcoming stable which will make it easier if you want to use the non-official route of in-place DLLs, otherwise it's best to rebuild the dependencies yourself (instructions in the wiki).

[xavier]

The newer SDK will have been built against 4053 yes, since that's what I have installed, not that it was by choice! The dependencies are probably still based on the old runtimes

Interesting -- I would not have expected that.

if you distribute your app properly with a Windows Installer.

That's a bit of a loaded phrase.

[sinbad]

The newer SDK will have been built against 4053 yes, since that's what I have installed, not that it was by choice! The dependencies are probably still based on the old runtimes

Interesting -- I would not have expected that.

I didn't have a lot of choice in the matter, MS patched my build machine whether I asked for it or not.

if you distribute your app properly with a Windows Installer.

That's a bit of a loaded phrase.

I've learned that trying to go against what MS recommends is like bashing your head against a wall

[xavier]

I didn't have a lot of choice in the matter, MS patched my build machine whether I asked for it or not.

Agreed that patching an SDK through Automatic Update is just insane.

[jacmoe]

I just found out that there's no stand-a-lone redistributable for this update?

So, I basically have to first run the vc 2008 sp1 redist, and then run the vc 2008 sp1 atl update redist ?

That's just totally insane!

(No, I am not going to xcopy anything - we have a larger dependency set and it would be a royal pain in the behind to go and change all the build settings.)

Please tell me that it's all in a different vcredist somewhere: the sp1 *and* the sp1 atl update.

[sinbad]

Or, you can just create a combined .msi like the one I uploaded?

[Devil N]

A few weeks ago I had the reverse problem: Ogre 1.6.4 is compiled against the patched runtime, while my VS2005 SP1 installation was unpatched (I have no idea why I didn't get the patch automatically). After jumping through a couple of hoops I found out that there is a stand-alone version of the patch, namely here: http://www.microsoft.com/downloads/deta ... laylang=en

Downloading 250 MB for a stupid little patch is a bit ridiculous, but at least it worked.

[jacmoe]

Or, you can just create a combined .msi like the one I uploaded?

I have VC Express, and I really don't fancy Wix (steep learning curve?), but that's a good idea.
I have a release to make, so I'll just chain the installers, for now. And look into it.
Thanks for the tip.