My name is Rob Huyett, and I’m an SDET on the Visual C++ Libraries team. I’ve been here at Microsoft for just a little over a year. One of my recurring duties here is to test VCRedist in its various forms.
VCRedist (just in case you aren’t already familiar with the term) refers to the process of distributing the VC libraries to computers that do not have Visual C++ installed so that Visual C++ programs can be run on those computers. There is a ready-made set of redistributable packages (vcredist_x86.exe, vcredist_x64.exe, and vcredist_ia64.exe) that carry around the full set of VC libraries (ATL, CRT, MFC, MFCLOC, and OpenMP) and their associated manifests. Visual Studio also provides the libraries individually in a directory called “redist” under the VC folder in case you’d like to create your own installation package that includes only those libraries that your particular project needs.
At the current time, most of the testing that I do for VCRedist is manual in nature. I’ll install a redistribution package on a machine, verify that the proper files have been installed in the right place, and run a simple test program (or two, or ten) to make sure that the program(s) can see the libraries. It may not sound like much, but that’s just for one machine, one configuration. Repeat that process for all of the supported architectures and operating systems, and I’m sure you can imagine that it can become a little tedious and very time-consuming.
To make this easier and to ensure consistency, I’m working (with the help and advice of a few other folks here) on incorporating this testing into our battery of automated tests. In addition to making life easier, the automated test suite will allow us to perform far more frequent testing and catch any potential problems sooner. So far, the automated testing just covers some very basic scenarios (install the VCRedist package, verify that the files are where they should be, execute a couple of programs, etc.), and the balance is made up with some manual testing. The idea, though, is to automate everything, so I’ll be adding new scenarios just about as fast as I can find a way to automate them! Some of the items on my to-be-automated list include repeat installations (for instance, when some or all of the libraries in the redistribution package are already on the target computer), installations, and automated testing of applocal redistribution.
Of course, if you have any comments, questions, or suggestions, I’d love to hear them! Thanks!
Rob Huyett - Visual C++ Libraries QA Team
Is this VCRedist for SP1, or are you already testing Orcas?
Are upgrades being tested? e.g. VCRedist for Visual Studio 2005 gold is installed and an application compiled with SP1 needs to be installed, will code built with RTM *and* SP1 be tested?
How about specific testing for upgraded OSes? e.g. an application installed under XP with VCRedist RTM was installed and the OS was upgraded to Vista, as well VCRedist was upgraded to SP1 after the Vista upgrade (and all the combinations thereof)?
The VCRedist*.exe files should only be used by people using Click-Once deployment - using a separate redist from your install scenario is a highly undesirable situation. For one thing, a user could uninstall it separately not knowing what it's for and then they will call you asking why your app won't work (and hopefully will remember what they uninstalled). Worse, it's not unheard of for apps which install a redist to then go ahead and uninstall it. Since there is no ref counting for an MSI (like VCRedist.exe) like there are for MSMs (the redistributable merge-modules which are the prefered redist method), this will hose your app.
In answer to Peter Ritchie's question, For a given product, all subsequent dlls released after RTM (gold as you put it) are designed to be binary compatible with previous versions. What this means is that if you have an app built with RTM, and someone installs SP1 or a subsequent version of the DLLs into Windows Side-By-Side using the redist MSMs or (God-forbid) VCRedist*.exe, your app will be redirected to the new version and will function as it did before. With Service Packs this scenario is tested relatively thoroughly. With QFEs, testing is not as in depth, but apps built with RTM bits should work fine with QFE dlls. You might not get all the fixes if they are contained in the headers (which would require a rebuild), but dll only changes (changes to .cpp files that are built into the dlls) should get picked up. This gives you free security fixes without having to rebuild your app.
From version to version though, the DLLs are renamed and your app will not run against the 2005 DLLs if built on a previous version (2003 for example).
I have ran into a strange problem while using CRT merge modules (VS 2005 version) in my product's msi. The product installs several DLLs that self-register. In most cases the install works without any problems. However, on some systems (XP SP2) especially the ones with a slower performance, the self-registration fails with the error "Fail to register HRESULT - 214702484". The error is not specific to a single DLL and occurs randomly with one or more DLLs, but not all of them. Ignoring the errors allows to continue on with install. Manual self-registration using regsvr32 on the modules that could not be self-registered during msi install is also successful afterwards.
Conclusion: it seems that the CRT modules updated by the msms are not readily available during self-registration phase. To avoid the self-registration issues on the affected systems the workaround is to run vcredist*.exe prior to msi execution.
This problem might be caused by the merge modules or by the Windows Installer. In any case, I would suggest to add self-registration testing to your automation to catch this type of a problem.
Is there any direction to replacing the core VC DLL files (e.g., crt) with ones developed in .NET?
@Steve: The direction would be nowhere. VC DLLs are required to provide specific exports for direct calls. .NET DLLs cannot provide those exports because the runtime is required to be running before .NET code can be run, something you can't do if you're directly calling an export. The other problem is .NET assemblies are IL code, there is no code that can be called via export without the runtime first JITing the IL into a different assembly.
Rob, you are seriously a GODSEND!!!
I've been having issues with VCREDIST (VS 2005) for about a year now. I don't mean to sound needy, but I am getting desparate. No, correction, I am already beyond desparate.
I made my installer with WiX, and added a custom action made with C++, some managed and some unmanaged code. For everything to work right, my bootstrapper has to install .NET framework and vcrt.
I created a VS solution named "Prerequisites," a deployment project. It's supposed to install (from the CD) .NET Framework 2.0, C++ Runtime x86, and Installer 3.1. When I build the project, I dump the .msi file it created for me, and put in the one created with WiX.
When I pop the CD into a WinXP machine, every now and then, the setup.exe will keep re-launching VCRedist, again and again, until you click the "cancel" button. I suppose I can live with that...
But then yesterday, I tried to put my CD into a Vista machine. (Brand new Dell). The VCRedist never even got launched! OK, fine, I suppose the machine had a different version of VCRedist intalled. But my custom action kept failing until I compiled the project with no CRT and with /MT!!!
Then, I double-clicked VCRedist, it installed, and my custom action was fine...
Any ideas what I can do with these VCRedist headaches? Thanks in advance!!!
Life is good!!! I saw Nikola's april entry about C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bootstrapper\Packages\vcredist_x86\product.xml being messed up, and that fixes the VCRedist problem...Thanks for publishing this!!!
If it counts, +1 vote to get this one fixed soon! (and about +20 for each of my beta testers)
We are using VC 8.0 runtime in production and I am testing the new 8.1 (SP1) runtime.
Our package consists in many different components and we won't be able to switch from 8.0 to 8.1 in one day, and will have to have both 8.0 and 8.1 components used at the same time during a transition period.
I understand that this should work and both runtimes would be loaded but I was wondering if there is any sharing of resources or each runtimes has its own duplicate resources? The reason I am asking is that we had problems with memory fragmentation due to multiple heaps in the past and I'm concerned this might happen again.
Thank you in advance.