VC++ 2005 redistributable (vcredist_x86.exe etc.)

Hi there,

I noticed that the Beta 2 redistributable is hosted on the Microsoft download library, but the final ones seems not to be. Will it be hosted on microsoft.com (or is it already somewhere ).

Also, it has been reported to me that on Windows 2000 the (RTM) redistributal gives an unuseful error message if Windows Installer 3.1 is not installed. The message is

error 1723. "A DLL required for this install to complete could not be run."

. It would be a lot more helpful to my users if this was a more informative error message - the solution of installing Windows Installer 3.1 was only found by trial and error.

Thanks.

Answer this question

VC++ 2005 redistributable (vcredist_x86.exe etc.)

Change2
Hi,

Thanks for the reply, but I am of course aware of that and it does not quite answer my question or my other comment :)

I know the libraries are included in the .NET framework 2.0 which is hosted on microsoft's website, but that is a larger download and some users seem to not like installing it either..
newtovisualc
Nikola Dudar wrote:

But it is not MSI pulls it MSI3.0, but rather customaction.dll inside MSMs.

Yes, this is what OShah discovered above already in his analysis, not MSI engine but the custom action which calls two functions only available in MSI 3.1 (MsiEnumProductsEx and MsiQueryComponentState)

It was by design decision across VS and VC had to follow it.

But it can hardly be faulted for us that we're curious as to why this is the case (i.e. why the 3.1 targeting design decision unless the MSI 3.1 gives you some functionality that your custom action absolutely requires) In OShah's analysis, he concluded that the "downlevel" functions MsiEnumProducts and MsiQueryProductState could have possibly been used instead. This may not even be the case, but we cannot know unless we see the actual source code of the custom action. It's interesting for us to hear some of the "inside" shop talk of the "why's" in some cases, even if it's normally considered confidential.

Ted.
Thomas Ott
There are several issues mixed in this post. I will try to address them one by one

1) It is planned to have vcredist_*.exe available on the website. I do not have an ETA for this now, but it is going to be announced when available.

2) MSI 3.1 is required. Agree that error message should be more informative. Pleaser report a suggestion on lab.msdn.microsoft.com

3) vcredist_*.exe is installed by Visual Studio as a bootstrapper package inside .Net SDK folder. If you do not see it on the hard drive, go back to VS install and select Redistribution packages under list of components.

4) Using vcredist_*.exe in your application does not introduce dependency on .Net SDK itself.

Thanks,
Nikola
VC++
Kylin.Sandfield
Re: MSI 3.1 - I'm wondering the same thing. I think it's some advanced WinSxS policy support stuff they needed.

For VC Express: you can make your own MSI redistributable using the MSM files that are available at: \Program Files\common files\Merge Modules

using the method mentioned here:

http://blogs.msdn.com/nikolad/archive/2005/09/02/460368.aspx

He has a typo in step 8, it should be:

a >cd d:\WiX
b. >candle.exe vccrt.wxs -out vccrt.wixobj
c. >light.exe vccrt.wixobj -out vccrt.msi

The funny (ironic) thing is that he has a troubleshooting secton that mentions this exact typo! (troubleshooting step 1)
Bliszek
Thanks.

When I discovered that this problem would affect every customer of Visual Studio 2005 (whether they install the Express Edition or Team Suite), it made me believe that Microsoft was conducting a conspiracy to monopolise the setup market and get us to install MSI 3.1 (maybe because they hated the fact KB898268 was preventing anyone from installing it--sounds stupid, but so does every conspiracy theory).

I'm not sure if I want to use the custom manifest... mostly because of the reasons Ayman mentioned. I liked the way Visual C++ Beta 2 worked: you could place msvcr80.dll in your app directory, and if the user had the WinSXS version, it would load the WinSXS version.

Have you taken a look at MsiEnumProductsEx and MsiQueryComponentState I'm no expert at Windows Installer, but MsiEnumProductsEx seems to be a filtered version of MsiEnumProducts, and MsiQueryComponentState seems to be a filtered version of MsiQueryProductState. So if the MSMs fallback to these older APIs we can eliminate the dependence on Windows Installer 3.0!

Using a bootstrapper is a good idea, but I'm not sure how it works in MSI. If it's a self-contained native app that does version checking on the MSI DLLs, I'd rather write my own app. If it relies on Windows Installer 1.0 being installed, I'm definitely writing my own app.
developer-Stu

Ted. wrote:
He has a typo in step 8

Thanks. :-) I have corrected it. Agree, it is ironic. :-)

But it is not MSI pulls it MSI3.0, but rather customaction.dll inside MSMs. It was by design decision acros VS and VC had to follow it. As I said on the newsgroups, you may contact developer support and request assistance if this is a "showstopper" for your product.

Nikola
Kiran Sattenapalli

Nikola.

I spent the last two days making my own bootstrapper application (which includes and installs MSI3.1 if necessary). This bootstrap app may be the final solution for me. About your offer of a QFE--it sounds like you've already come up with a fix, but need extra support from our side to get it released. Forgive me if I'm mistaken.
When you chose that design decision, did anyone mention the possibility that it could lead to DLL Hell, The Sequel (impacting both developers and end users)

Ted, Why I labelled Microsoft.VC80.CRT.manifest a custom manifest Visual C++ Express doesn't have a Microsoft.VC80.CRT.manifest in its folder (it has no VC\redist folder whatsoever, it just has the MSMs from common files). Fortunately, I managed to recreate that manifest from other sources. Hence why I called it a "custom" manifest. Hope that clears up any confusion.

Hopefully, when my custom bootstrapper is finished, I'll be rid of these problems.
Dr. eX
I agree, in a perfect world Microsoft would revisit this and eliminate the possibly unnecessary dependence on MSI 3.x. There might be other reasons why they moved to MSI 3.x other than just those functions.

Note: I asked Microsoft whether this was a bug or by design, and they said by design. Look here:

http://groups.google.com/group/microsoft.public.dotnet.languages.vc.libraries/msg/be11e4eefb3d2687

Yes, I agree it is nice that it chose the ones WinSxS folder first in older versions, this is one of the major disadvantages of the new method, but I've got to weigh the benefits.

For installing applocal, you mentioned a custom manifest, actually no changes to the default generated manifest are necessary. You simply need to copy the Microsoft.VC80.CRT folder into your program folder.
I tried this:

1) On a machine with Visual Studio 2005, build a release app that is dependent on msvcr80.dll etc.

2) Find an XP machine that has no trace of 2005 or the framework 2.0 (virgin machine), i.e. no copies of any of the new CRT DLLs.

3) Copy the release executable built in step 1 to the virgin machine.

4) Copy the folder \program files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT to a subfolder of the location of the executable copied in step 3.

5) Double click on the executable. It just works! No custom manifest necessary.
Vishal Bansod
Actually, the vcredist_x86.exe isn't part of the Net Framework package (neither the redistributable nor the SDK contain it). I have Visual C++ Express, and .Net v2 SDK installed on my machine, and neither installed that file. I had to pull that redist from a Visual Studio Professional machine.

It looks like that redistributable is specific to Visual Studio Professional.

On the MSI front, I'm wondering what feature required MSI 3.1 to be installed and why it required MSI 3.1.
kismath

My original statement that MSI v3.1 is requirement is incorrect. The redistributable only requires MSI v3.0 (ie. if you have MSI 3.0 you won't get the 1723).

However, even using WiX, I still got the 1723 error on systems without MSI 3.0. In the VCCRT.wxs file, I noticed that the Package element included the following attribute:

InstallerVersion='300'


which means that my custom MSI will refuse to install on anything less than XP SP2. That shouldn't be a problem--Just fix that attribute so that the minimum Installer version is 2.0, and it should run quite happily.

Or so I thought.

The MSI 3.0 requirement seems to be embedded in the MSM files themselves. I took a look at the Msievent.logs and noticed that the 1723 occurred at step SXSInstallCA. Eager to discover what this step did, I decompiled the Microsoft_VC80_CRT_x86.MSM with msi2xml (http://msi2xml.sourceforge.net/). The SXSInstallCA (and also the SXSUninstallCA) step called into a custom DLL called MSMCustomAction.dll. I knew I was homing in on the source of the problem.

Seeing how the problem was caused by an outdated Windows Installer, I opened up MSMCustomAction.dll with Dependency Walker (http://www.dependencywalker.com/) and found the two APIs that caused the 1723.

They are MsiEnumProductsEx() and MsiQueryComponentState(). Unless these two functions are located in MSI.dll, then the entire install will fail with a 1723.

This means:

a. All VC++2005 programs that rely on the multi-threaded DLL (that's the default) CRT will not work on Windows 2000SP3, XPSP1, or Server 2003, unless they obtain a patch to update Windows Installer. (did I forget to mention that the patch REQUIRES A REBOOT )
b. It doesn't matter if you use the vcredist_x86 or author your own setup from the MSMs. I've also checked a machine with VS2005 Pro (the same problem with those MSMs).
c. An end user may be required to download 300Mb of patches (and reboot, and then reinstall Windows when the patch fails) just so they can install your application.
d. Fixing requires a change to the prepackaged MSMs themselves. There's nothing I can do from the setup side to workaround it.

Given a dialup connection and the choice of a 500k statically-linked app (whose CRT may or may not have security bugs), and a 20k app that requires 300Mb of extra downloads (which doesn't have security bugs, just reliability bugs), I know which one an end user will choose.
Hiryux

In my installation, I found the such file under
Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86

I believe that is the .net framework SDK.

Hope this helps!

Thanks,
Ayman Shoukry
VC++ Team
evilone
Thanks, the awnsers to 1) and 2) is what I wanted to know :) I've filed a suggestion now.
Prashant Sridharan
Thanks OShah for your valuable comments - I keep forgetting about that fact that VC Express only has the MSM files. I think they should have at least included those custom manifests as a minimum. Now there is no obvious way to deploy apps applocal using VC Express.

I'd be interested to hear about your bootstrapper once you get it done. In fact, I think that Microsoft should release a modified vcredist that installs the Windows Installer 3.1 as well as the libraries. This will save a lot of pain for people.
DanielRehn
OShah - great analysis, excellent post. This finally gets to the bottom of why this is happening.

1) I think that you may be able to include MSI 3.1 redist with your app

http://www.microsoft.com/downloads/details.aspx FamilyID=889482fc-5f56-4a38-b838-de776fd4138c&displaylang=en

2) There are also some files here that may help you for redist:

\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\WindowsInstaller3_1

Not sure of the ins and outs of the bootstrapper mechanism yet.

You might be able to call into these new APIs without immediate reboot (i.e. so-called delayed reboot) but I haven't yet found out whether it is possible (something similar was possible with MSI 2.0)

3) There is also the method of not using the redist or MSI at all, and just install applocal. See other my posts relating to this e.g. http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=156832&SiteID=1

I've decided to go this route for my apps.
VC++ 2005 redistributable (vcredist_x86.exe etc.)

Answer this question