VS2005 SP1 nightmares

· by Steve · Read in about 5 min · (902 Words)

Argh. I downloaded and installed VS2005 SP1 yesterday, and all appeared to go well. I performed a bunch of builds yesterday (crucially, all release builds) and all was fine.

Today, however, after making a lot of changes for better ANSI compliance and warning fixing, I wanted to test a debug version. And this is where the nightmares started. I now have a seemingly totally random case of debug builds refusing to locate the side-by-side assemblies for the debug C++ runtime library - it moans about a missing MSVCR80D.DLL and MSVCP80D.DLL - the usual suspects. Of course these days they are picked up via a manifest which tells the system to go find the appropriate version in %WINDIR%\winsxs\somelongpathname, and up until now this has generally worked fine. With SP1 though, samples in debug mode will randomly complain about not being able to find the debug runtime - I can build one and it’s fine, another one won’t work. After a clean build, more often than not, the one that used to strangely work no longer does. Yet there have been no changes at all to the code, project settings or installed DLLs. Grrr.

Now, the fact that different samples, linking and using the same DLLs, behaved differently suggested that this wasn’t an issue with the underlying OgreMain_d.dll etc, but to be sure, I proceeded to clean rebuild all the dependencies with SP1. No dice. So, I started to look at the .manifest files that were being generate, and here’s what I found. In the OgreMain debug manifest file (stripped for brevity):

`Argh. I downloaded and installed VS2005 SP1 yesterday, and all appeared to go well. I performed a bunch of builds yesterday (crucially, all release builds) and all was fine.

Today, however, after making a lot of changes for better ANSI compliance and warning fixing, I wanted to test a debug version. And this is where the nightmares started. I now have a seemingly totally random case of debug builds refusing to locate the side-by-side assemblies for the debug C++ runtime library - it moans about a missing MSVCR80D.DLL and MSVCP80D.DLL - the usual suspects. Of course these days they are picked up via a manifest which tells the system to go find the appropriate version in %WINDIR%\winsxs\somelongpathname, and up until now this has generally worked fine. With SP1 though, samples in debug mode will randomly complain about not being able to find the debug runtime - I can build one and it’s fine, another one won’t work. After a clean build, more often than not, the one that used to strangely work no longer does. Yet there have been no changes at all to the code, project settings or installed DLLs. Grrr.

Now, the fact that different samples, linking and using the same DLLs, behaved differently suggested that this wasn’t an issue with the underlying OgreMain_d.dll etc, but to be sure, I proceeded to clean rebuild all the dependencies with SP1. No dice. So, I started to look at the .manifest files that were being generate, and here’s what I found. In the OgreMain debug manifest file (stripped for brevity):

`

See that? Two references to the DebugCRT. In previous builds, there was only one, the ‘8.0.50608.0’ version which must have been the pre SP1 version. Now, I could imagine this if I still had dependencies that were built with the old CRT, but I’ve already rebuilt them all. Secondly, the manifest file for the failing demos only references the ‘8.0.50727.762’ version, not the older one. I assume this is why it’s failing to find it, because it somehow thinks it’s needed, but the manifest isn’t pulling it in. So I have 2 very puzzling issues - why is it still trying to reference the old CRT too, and why isn’t that dependency being carried through to the exe anyway?

Oddly I have demos built with the old pre-SP1 version, and their manifest references ‘8.0.50608.0’, and they run just fine. Also, if I browse my winsxs folder for Microsoft.VC80.DebugCRT, I find the two versions I have there are actually labelled ‘8.0.50727.42’ (Spetember 2005, presumably the original) and ‘8.0.50727.762’ (Dec 2006, clearly SP1). Quite where the ‘8.0.50608.0’ version is, or why it worked at all before is rather puzzling.

I can only assume the fact that it’s referencing 2 versions of the CRT at once is confusing it, yet no amount of rebuilding all the dependencies seems to get it to just reference the new one. I’ve done countless clean builds of both Eihort and the dependencies today and I’ve gotten nowhere. I haven’t checked the forums yet because I don’t have time to answer all the questions with this going on today, so I’m not sure if anyone else is experiencing this with SP1. All I know is that it’s damn annoying, and I wish this manifest business hadn’t been invented, it’s far more trouble than it’s worth. If I can’t solve this soon I’m going to have to uninstall SP1.

**edit - I’ve isolated the problem and found a workaround after 24 hours of teeth-knashing, see the comments. I’m convinced this is an SP1 bug. **

** edit2 - turns out this is the FAT32 timing bug (my coding drive has never been upgraded to NTFS), which for some reason I never hit before SP1. Workaround is to enable the ‘FAT32 workaround’ option in every project file. What a pain. **