VC REDIST 2008 being installed every launch of Borderlands 2

[MrZoolook]

I experienced an annoying bug with VC-2008 after installing the game (and Steam) on a new Win-7 install. I wanted to just run by how I managed to get it sorted.

The game persistently needed to run the setup for "VC-Redist 2008" no matter how many times it had run before. The other pre-requisites were fine, but not that one. I even tried running both Steam AND BL2 as administrator, but to no avail. I set the package as installed using the registry, and it would still need to install it.

I downloaded the installer direct from Microsoft, and even that failed. BUT this did give me an error telling me the installer couldn't access its files on my Data drive (drive X:). I tried removing the drive letter from that drive using Computer Management, and ran the VC-2008 installer direct, and lo and behold, that worked. But with the caveat that I needed to manually delete the temporary installer files from the root directory of my System drive (drive C:).

So, in short, if:
1. you're getting issues with games constantly running setups when launched,
2. every other solution you try fails,
3. you are happy to fix issues that dumb-♥♥♥ programmers cause by not doing their jobs,
4. you have more than one hard drive in your computer...

You might want to try taking off the drive letters for all those extra drives and partitions, and this (presumably) forces the installs to use the drive that's (presumably) hard coded in those badly written installers.

Of course, remember to change all those dirve letters BACK TO WHAT THEY WERE after the install finishes, or you'll probably end up with other problems.

[Mr.Aight]

An easy fix that I remember is to delete the installation files for VC REDIST and all the prerequisites to get rid of that.

[MrZoolook]

Did not work for me :(

[CoolingGibbon]

Go to C:\Program Files (x86)\Steam\steamapps\common\Borderlands 2.

Inside you will see a "installscript.vdf" file. Open it with Notepad, clear the contents, save and close.

Right-click on the file, go to Properties and set the Attribute as read-only.

Launch BL2 and see if you still get the VC redist installation.

[MrZoolook]

Again, that did not work here. Litterally, I tried everything I could find relating to this (and DX installing conctantly - just in case it was related) and nothing worked until I removed the drive letter from my data drive. And as if by magic, all was well from then on.

[CoolingGibbon]

Ah I see, so you had already fixed the issue then. Either way, it's just practical (though not always feasible) to have your games installed on C: by default. Prevents a lot of headache down the line.

[MrZoolook]

That's the thing. Steam and all the games, Windows, all my applications etc are on C:, the only thing I have on my data drive is documents, mp3s, video... things like that. Yet the VC-REDIST installer apparently insisted on using my data drive to unpack it's temporary files. And yes, my tmp directory is still also on C:.

Meaning the VC installer ignored the settings I had for system installation or temporary directory, and tried using the other drive. And that somewhere in the install code, it was set to use C: instead of "where the temporary files were unpacked". Which to me is bad programming on behalf of the writers of the install program.

I effectively needed to remove my data drive (by removing the drive letter of X:) so the install program correctly used the system drive to unpack its temporary files, where it would happilly see them and continue without error.

[CoolingGibbon]

There is no "fixed" location for unpacking temporary installation files and there is no setting that allows you to control it (outside of playing around with environment variables). Usually Windows installers extract temporary files to your logical drive and then clean it up post-installation. It's not so much bad programming as the quirks of Windows installers. Though I believe the newer VC redistributables might have changed the extract location because they don't use the cab installers that the older VC redist versions do.

Removing your logical drive path forces the redist installer to use your primary drive instead.

[MrZoolook]

I have 2 physical drives, each with exactly 1 partition set as primary on each, comprising the whole drive, except that the system drive had a small 100mb partition created during Windows setup on the first drive; the only drive in the computer when I set Windows up by the way.

There is no logical behind the setup program using the second, non boot, non system, completely independant physical drive, when it's run from the first, only system, and only boot drive.

There is also no logical reason why removing the drive letter from the independant drive should suddenly allow the installer to use the system drive it's being run from. Even if it did, theres no reason the VC installer should unpack temporary files on one drive, only to then try and read them from a different drive. That IS 100% bad programming.

[CoolingGibbon]

I don't think the "drive" plays as big a role as the "partition" in this. Even if you have both drives set as primary, Windows can have only ONE boot partition at any given time. So even thought the second drive acts as a primary partition for another OS, it is treated as a secondary drive as far as the current running Windows install is concerned. At least that's my theory.

[MrZoolook]

No, no... my 2nd drive is ONLY data. there are no system files at all on it. THE ONLY boot and/or system partition is on the first drive in the computer. There really is no reason for the install to try using any other partition except the system partition on the first drive, which is the ONLY system/boot partition on the entire system.

[CoolingGibbon]

Unless I'm misunderstanding you, "installation" and "extraction" are two different things. The files are "extracted" to the logical drive. They are then "installed" to the boot drive. The exe that you click is nothing but a self extractor. It doesn't matter whether your secondary partition contains only data or a whole other OS. It's irrelevant as far as the running Windows boot partition is concerned.

[MrZoolook]

The complaint is that after running the self extracting executable (which should then run the now extracted VC installation executable), and not even being given a choice where they are extracted, the extracting executable actually tries running the VC installation executable from a different place to the place it extracted the installation files.

THAT is badly programmed. It is completely, utterly, 100% irrelevant how many physical, logical, extended, cloud, ftp, {list all forms of storage devices here} drives are installed. For the extractor to not even give you a choice where to extract, and then try and run the extracted install file from a different place to that it extracted it to, is bad programming.

Is that really too hard to comprehend?

If it temporarily extracts the install files to X: without even giving an option to extract them elsewhere, I bloody well should expect it to run the extracted files from X:, not C:.

It would be like installed Office apps, games etc, just failing to run after being installed on your hard-drive, because even though you told the installer to use that drive, it installed them on a USB thumb-drive that was connected.

I don't understand the difficulty here. The extractor executable used 1 drive to extract its files, then tried to run the install program from a different drive. Simple as that.

[CoolingGibbon]

My apologies, I must've missed your response earlier.

Originally posted by MrZoolook:

The complaint is that after running the self extracting executable (which should then run the now extracted VC installation executable), and not even being given a choice where they are extracted

Self-extracting VC installers do not provide you an option to extract to a location of your choice unless you use a third-party tool like WinRAR or 7-Zip. It has been that way since VC 2005. Funny how you never noticed that before.

Originally posted by MrZoolook:

THAT is badly programmed. It is completely, utterly, 100% irrelevant how many physical, logical, extended, cloud, ftp, {list all forms of storage devices here} drives are installed. For the extractor to not even give you a choice where to extract, and then try and run the extracted install file from a different place to that it extracted it to, is bad programming.

I'll disregard the rambling and ask you a simple question... have you ever installed a redistributable before? If you think it's bad programming or whatever, I'm surprised you're noticing it just now.

Originally posted by MrZoolook:

Is that really too hard to comprehend?

Yes it is, on your part. I suggest you check that condescending attitude of yours at the door before posting on a forum that operates on the notion of people helping each other.

Originally posted by MrZoolook:

If it temporarily extracts the install files to X: without even giving an option to extract them elsewhere, I bloody well should expect it to run the extracted files from X:, not C:.

Now that is the real issue you are facing, minus the incoherence. This is something worth investigating. By default the extracted MSI should run from the same location it was extracted to. I have never had this problem when the extraction occurred on either the primary drive (C:) or the secondary one (X: in your case, and D: in mine). I believe this has something to do with the paths defined in the environment variables on your system, but I'm not sure. You might want to look into that aspect if you have the technical knowhow.

[MrZoolook]

"I'll disregard the rambling and ask you a simple question... have you ever installed a redistributable before? If you think it's bad programming or whatever, I'm surprised you're noticing it just now."

Yes, and this was the only.... THE ONLY one, before or since, that both failed to clear up its temporary extracted files, and failed to read them from whatever directory it chose to extract them too.

[CoolingGibbon]

Originally posted by MrZoolook:

Yes, and this was the only.... THE ONLY one, before or since, that both failed to clear up its temporary extracted files, and failed to read them from whatever directory it chose to extract them too.

I tried reproducing your problem with the VC 2008 SP1 MFC redistributable and could not do so, both with 32-bit as well as 64-bit versions.

Is this the installer you downloaded?

https://www.microsoft.com/en-gb/download/details.aspx?id=26368