Hello again, this is Ben Anderson, SDET on the Visual C++ libraries team.
One of the most common questions we get from customers on the forums and elsewhere is “My app needs the Visual C++ Libraries (CRT, ATL, MFC, OpenMP or some combination thereof) – how do I get them on my customers’ machines?” It’s also something we see in the wild done, if not incorrectly, at least non-optimally fairly frequently. The help documentation in MSDN is correct, but there is no one stop-shopping explanation of all your options. This blog post will attempt to explain what to do. (In case you’re looking for the short answer, almost always, the correct thing to do to distribute the Visual C++ libraries is to add the Visual C++ redistributable MSMs, or “Merge Modules”, for the libraries you use to your application’s setup.) I’ve tried to outline below the various methods of redistributing the Visual C++ library DLLs based on what your deployment story may be.
In most cases, folks deploy their applications using a standard Windows setup. In these cases, you probably build an .msi file using some toolset (such as a Visual Studio setup project) which is then wrapped in an .exe file by your tool chain. End users run this .exe file and your application is installed. If you don’t already have a setup for your application, it’s very easy to create one using Visual Studio’s setup project (found by right clicking your solution, clicking Add -> New Project… -> Other Project Types -> Setup Project). You can then right click your setup project, click “Add->Project Output…”, then select Primary Output. You can then add Start Menu items and tweak your setup to meet your needs.
In order to redistribute the Visual C++ libraries, all you need to do is include the appropriate .MSM file and its accompanying policy .MSM to distribute the library you need. If you are creating a setup project as part of your solution as described above, Visual Studio will attempt to detect which libraries you depend on and will add MSMs as appropriate. If you are creating your setup project with another tool, or not using the “Add project output” option, you will have to manually add the MSMs for any libraries you need. These libraries are found in “%ProgramFiles(x86)%\Common Files\Merge Modules”. For example, on my VS 2005 SP1 system, if I had an x86 MFC App, I would add the following files as Merge Modules to my setup project:
These files are then consumed by your setup tool, and their contents are dropped as part of your MSI on your users’ systems. They contain components which install to Windows Side by Side the DLLs and the redirection policies [see footnote 1] for the libraries you select. These components are ref counted so that every time an app using these MSMs installs, the ref count is incremented, and every time one of these apps uninstalls it is decremented. Once the ref count hits zero, the DLLs and policy are uninstalled.
There are a few cases in which MSM installation may not work for you. In one case, you may have to deploy your app on systems where the user has no administrator privileges and so cannot run a setup. There may also be some other reason you cannot use an MSI to install your application – for instance, users may run your binaries directly from a network share.
In these cases, you can do an “app-local” deployment, which is sometimes called deploying the DLLs as “private assemblies”. All you need to do in this case is provide a copy of the DLLs you need, and their accompanying manifest in the same directory as every .exe, .dll or .ocx file in your application. To deploy in this way, simply copy the entire contents of the appropriate folder under <Visual Studio install dir>\VC\redist [see footnote 2] into the all folders which contain binaries which use those libraries.
The advantage of this approach is that you do not need to create an install for your application. This means you can deploy and run without requiring your users to elevate to administrator privileges. All your users need to do is copy your application folder onto their systems or run your .exe directly from its current location. The disadvantage is that you must put a separate copy of the libraries you need in every single directory in which your binaries reside. For a simple application, this may not be a problem, but for a large app which might have many subdirectories with many tools and DLLs, this is a lot of file duplication.
Finally, there is one additional scenario for redistributing the Visual C++ libraries DLLs. This scenario is if you are using “Click Once” deployment. In this case, “Click Once” will use a custom built installer package called “VCRedist_<arch>.exe” to install the libraries for you. DO NOT use the VCRedist_<arch>.exe installer packages for any other purpose.
The VCRedist packages are simply MSI’s built by consuming all the MSMs from “%ProgramFiles(x86)%\Common Files\Merge Modules” as well as the MSDIA DLL (used for debugging). However, MSIs are not ref counted like the components in the MSMs, so if you install it, you can never uninstall it because you do not know who else might be using it in addition to your app. Further, your users cannot uninstall it because they do not know which of their applications may be using it. Additionally, your users may not realize what it is when they see the entry in Add/Remove program files. Imagine a user trying to free up space on their machine, seeing the entry for VCRedist which they do not recognize, uninstalling it, then some time later (maybe months), trying your application again. It will not work! Your user will probably not connect the action of uninstalling VCRedist at some point in the past, and will either be broken without a fix, or use your support center’s time trying to find out why your app stopped working. What’s more, it’s very likely that you are not using every single Visual C++ library, and installing the whole of VCRedist is unnecessary. Alternately, a poorly written installer for another application which used VCRedist to redistribute the Visual C++ libraries may (incorrectly) uninstall VCRedist when that app uninstalls.
A better option if for some reason you cannot incorporate the MSMs into an MSI which installs your application is to use Visual Studio or another tool to build a tiny MSI installing just the MSMs, and only those that you require. Since this MSI is unique to your product, and can be named whatever you like, you can uninstall it when your application is removed, and you can name it in such a way that your user recognizes it as part of your application and will not uninstall it inappropriately (name it say “MyApp Prerequisites). By using your own MSI, you also guarantee that no other application which uses the VCRedist package will interfere with your app by incorrectly uninstalling it during that app’s uninstallation.
Again, just to emphasize – do not use VCRedist*.exe unless you are using Click Once to deploy your application.
In addition to all the methods described above of distributing the Visual C++ libraries DLLs, there is one last option for building your application which does not require you to distribute the DLLs. However, this option only works for native-only code (it is not supported with /clr) and leaves your customers seriously vulnerable to any security holes as well as adds a significant burden upon yourself to patch all customer systems should a vulnerability be found in any of the libraries. This option is to statically link in the libraries as .lib files instead of dynamically loading them as DLLs. You do this by using the /MT flag on the cl.exe command line (vs /MD), or selecting the appropriate option in your project properties through Visual Studio. You may wish to use this option when testing early debug builds of your application on test machines before you start working on setup. [See footnote 3]
However, I can think of no scenarios in which this is actually the right thing to do when shipping your product to customers. Basically, what this approach does is pulls in the binary code needed from .LIB files at compile time, making it a part of your .exe or .dll files. It increases the size of your application, and there is no way to update the libraries apart from recompiling your application with new .LIBs and redistributing your application all over again. What this means is that unless you go touch every single machine which has installed your application every time there is a security vulnerability found in the Visual C++ libraries and completely reinstall your updated binaries, you will be leaving your customers vulnerable to attack. If instead you use the DLLs, every time there is a security vulnerability found in the Visual C++ libraries, Microsoft will install the update centrally into the WinSxS folder via Windows Update and all requests for the DLLs will be redirected to the updated version. This removes all servicing burden on your side and also allows the user to install one small update which will touch all their applications instead of replacing every installed exe and DLL on their system. Please, do not distribute an application built by linking statically against the Visual C++ libraries unless you have a system in place for updating every customer machine and also have a very good reason to do so. At this time, I can think of no circumstance under which this would be the right thing to do for a shipping application.
Well, hopefully this article has helped you out in understanding how to redistribute the Visual C++ libraries onto your customer’s machines. If you have additional questions, you can find the documentation for deploying Visual C++ built applications here:
If you still have questions, you can post comments here (I will check back for a few weeks), or you can post your question in the Visual C++ forums here:
Thanks,Ben AndersonVisual C++ Libraries Team
 The redirection policy always redirects requests for the Visual C++ dlls to the latest installed versions, even if the application requesting the dlls has used “app local” deployment to drop the dlls as private assemblies – this way, if a security issue comes along, Windows Update can drop fixed dlls into Windows SxS and all affected applications will be fixed. The Visual C++ team maintains a strong binary compatibility guarantee that applications built against an earlier version of the library will work against all later versions with few exceptions (exploitable usage may be broken to prevent customer machines from being hacked).
 Please note that the files in this directory are not updated in QFE patches, and some of the manifest files in this directory were not updated as part of SP1 of Visual Studio 2005. As a workaround, you can find the appropriate version of the files in the WinSxS directory of your Visual Studio development box by typing “c:\windows\winsxs> dir *VC80*”, identifying the correct directory based on version numbers, then copying the contents of that directory into your application directories instead.
 A better option would be to create a simple setup project and include all the Visual C++ MSMs and install this on all your target machines.
<i>At this time, I can think of no circumstance under which this would be the right thing to do for a shipping application.</i>
1) historically, Microsoft has completely screwed up versioning, installing and patching the CRT and MFC DLLs.
2) Microsoft does not include the MFC, CRT and associated DLLs with service packs and, to my knowledge, has never updated them through Windows Update.
3) The DLL install package is huge. Do you really suggest that I should ship a 2 MB package so a 90k executable will run? Are you out of your mind?
Seriously, you comment illustrates absolute ignorance of the reality of distributing commercial executables to customers and in supporting those customers, especially in light of Microsoft's history of awful support for the MFC and CRT DLLs and the bloat of these libraries.
Agreed. Another circumstance I'd like to add: you must statically link if your program must run as a stand-alone .exe. There are many circumstances in which this is required, such as if your program has no setup module and users are likely to just run it out of a .zip archive. Would you dynamically link a stub for an installer? That would be stupid.
You say that dynamic linking allows for DLL servicing. Are you aware of the testing load that this incurs? If you were to find a problem that you wanted to fix in the CRT, you would have to test ALL versions of the CRT you were updating against ALL programs using them. The DirectX team went down this path with the D3DX DLL, and they are now up to at least 12 versions of D3DX_*.DLL. Hotfixing and testing an update for a flaw in all of those versions is a huge task, and it turns into a nightmare for vendors if the DLL breaks a program, because it becomes one more moving part in the system. The main effect so far of the D3DX DLL scheme has been a big installation headache, and this is true for the DLL versions of the VC8 CRTs as well.
My rule for avoiding distribution and servicing headaches in third party components is, for the most part, to simply avoid using them. That isn't really an option for the CRT, so I statically link it. I have no plans to change this any time soon.
As hinted above, static linking does *not* increase file size. It makes your .exe slightly bigger, yes (but only adds the bits that you actually use), but it saves you from having to distribute the full CRT/MFC/whatever DLL's, which are much bigger than the slight increase in file size you get with static linking. That's one argument down.
As for the security thing, true, but:
1: How often are security vulnerabilities found/patched in the CRT?
2: How is static linking different from an app-local deployment, where you get (multiple copies of) the same dll's, but in the app's folders where a general windows update won't be able to reach them?
And of course, there's 3:
It just works. (and you know it'll keep working, because you, the developer, controls when/if your code gets updated)
Distributing dll's doesn't, as your post shows. There's too many hoops to jump through, too many gotchas, and too little benefit.
It would be really nice if Microsoft recognized this. I'm not opposed to dynamic linking (seems to work fairly well on Linux), but when it's done as awkwardly as this, static linking is just a better alternative.
I love static linking, but it seems like I'm the only person at Microsoft who does.
Yes, if a security flaw were patched in the CRT or separately compiled Standard C++ Library, you would have to ship your binaries again if you statically linked them. But no matter what, if a security flaw were patched in the header-only part of the Standard C++ Library, you'd also have to ship your binaries again. Same thing for any other libraries you use that are statically linked (e.g. zlib, bzip2, Boost.Regex) or header-only (e.g. other parts of Boost). And if a security flaw is patched in your own code, you definitely have to ship your binaries again.
Result: Any application with security exposure (which is almost all of them) needs to be serviceable. Statically linking the CRT/etc. increases the number of scenarios in which you will have to ship your binaries again from "many" to "many plus one". It does not increase it from zero to nonzero.
As I said, though, I haven't been able to convince anyone else at Microsoft with this argument. Officially, statically linking the CRT is severely frowned upon (as Ben makes clear).
Jalf: Proper app-local deployment of the CRT DLLs *does* permit Windows Update to service them (basically, it checks for patched copies before loading the app-local DLLs).
Stephan "/MT" Lavavej
Visual C++ Libraries Developer
There seem to be a few misunderstandings regarding the details of how this process works. I'll try to hit all of them, but I might miss some, so be patient.
In no particular order:
Phaeron - in the case you mention, in your first paragraph, having a standalone exe with no installer, the correct thing to do is to package the CRT DLLs app-local - no need to install and in the case of a security event you will be redirected to the patched version by WinSxS.
With regards to maintaining multiple versions of the DLL, the VC servicing policy is different than what you describe for DirectX. VC has an extremely strong commitment to binary compatibility within a VS version. What this means is that if you build with our RTM bits, every subsequent version of that VS is guaranteed to be compatible with your app. So any version of MSVCR80.dll greater than or equal to the version your app was built will work with your app. If not, this is a bug and we will fix it for you and/or pull the update. The only scenario I can envision a binary breaking change would be if there is an exploitable use case where not breaking the case would result in customers boxes getting owned. In that case there might be justification to break that API (have it gracefully fail) to ensure that end user boxes are not compromised.
In your scenario, I strongly recommend you change your stance towards statically linking the CRT. I believe your choice was made based on mistaken assumptions. I cannot envision any scenario that would give you a headache by dynamically linking and I can envision a scenario where you would be significantly inconvenienced by statically linking - a security event along the lines of the GDIPlus vulnerability from a few years back described here: http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx. Without WinSxS the only way to fix this was to scan the machine for copies of the dll and update each one. Now with WinSxS, a single central copy with accompanying policy can redirect all DLL requests to a patched version. However, if you are statically linking, you will have to handle servicing all your customers yourself.
Regarding point 2 - when you deploy app-local, even though you have a local copy of the DLL, when your DLL is loaded, if there exists a policy in WinSxS to redirect requests for the version of the DLL you are trying to load to a centralized version, your app will load the updated version. This is the main benefit VC derives from using fusionized (WinSxS) DLLs. We can service every user of the DLLs centrally even if they are deployed app-local. It also guarantees, rogue DLLs named msvcr80.dll should not get loaded by an app loading the CRT dynamically by building /MD.
In question 1 you ask how often security vulnerabilities are found and patched in the CRT. I don't have the numbers in front of me, but I can think of one case since VS2005 RTM that I was involved in (thankfully it was never exploited). It is true that since the Secure CRT functions were added we've had significantly fewer vulnerabilities than in previous product versions, however this is no guarantee. It only takes one really nasty vulnerability like the GDIPlus one from a few years back to cause a huge headache both for end users and ISVs.
I would also dispute your assertion that distributing DLLs does not work. In nearly every mainstream scenario DLLs are both easy and untroublesome. If there is some scenario you think we need to address to make things easier let us know. We recognize that guidance on using the new fusionized redist mechanisms was not very good coming out of the gate for VS2005. We're working hard to improve that story as we hear from you guys what the pain points are.
I saved your post for last because I don't believe you have any misconceptions about how things work to clarify. I think you and I just disagree about the cost/benefit of things.
Let's start with the size issue you mention. There are two sides to the size story - size of what you have to ship and size once your app is installed on end user systems. Let's analyze making that distinction.
In your example I'm assuming all you have to ship is a single 90k executable (which is pretty small by statically linked size standards - by just using printf and cout I get a 122k exe /MT which is 7k /MD - but really, we're talking about a 0.1 meg difference so no biggy). I'm also assuming you're dependent only on the CRT and possibly also the SCL (the C-runtime and Standard C++ libs). In this case, assuming you don't want to add anything to the start menu and that sort of thing, it's probably reasonable to ship installer-less as just a zip file including the MSVCR80.dll (CRT) and MSVCP80.dll (SCL). This adds about 1 MB to what ends up on your user's drive, and assuming you zip your app and 400k to what you have to ship (459KB vs 59KB in my little dummy app). In this dummy app scenario, the CRT dlls do dominate, but in most serious applications, if you have a gui or anything along those lines and accompanying resources and artwork, this scenario will be reversed. In my mind 400k to ship and 1MB on my users machines is worth not having to service in the case of a CRT issue.
Now, let's assume you have an installer and you use the merge modules to redist. I think in this case you might get a little bigger - say about 2 MB total to ship your app and the consume CRT MSMs into an installer. So you're now shipping a little more. However, what ends up on your end user's machine in most circumstances is less. Since many, many apps use the CRT, it's almost guaranteed to be on your users system already - I believe IE7, Office 2007, Windows Vista all ship the 8.0 CRT. Since the MSMs will simply bump a ref count and not drop anything additional on your users' systems in this case, your user will actually be saving about 100KB of space vs what they would if you shipped statically.
So really, the size argument comes down to whether you are sweating having to redist about 1MB in addition to what you otherwise would have to. I would argue that in most large applications, you'd actually be saving space shipping the MSMs when you have a number of binaries you are shipping to link dynamically. But even in a small app, where this isn't the case, are you going to want to service your users in the event of a security issue? Is the saved cost in a 1MB smaller shipping vehicle worth the cost of harming your customers and having to service them yourself? If size is the only argument, I would have to say that in my mind the answer is a resounding No!
I believe your other argument is that historically, CRT and MFC versioning has been screwed up. I'm not sure exactly what you're referencing, but it is true that back in the 90s some companies had issues. One annecdote I was told by a coworker was that back when VC6 shipped, which I think was before we started renaming the dlls with each version, we shipped a new msvcrt.dll which had a vastly improved memory allocation scheme which was much better at reusing freed memory. At the time a lot of vendors had double-free bugs which most of the time did not repro because on the second free, the memory had not been reused yet, but when 6.0 hit and was shipped, their apps started crashing when they hit their double free bugs after the memory had been reused. This clearly was a bad situation. The vendors did have bugs and all that really happened was that their apps were crashing more frequently than they were before, but since the CRT was dropped on them from elsewhere, they didn't have the opportunity to test their apps against the new CRT before they got hit by the new bits. This was bad.
However, we've learned a lot since the 90s and are constantly trying to make things better for you guys. Starting with 70, we started renaming our DLLs every version and maintaining strong binary compatibility commitments within a version. With 80 we've gone with WinSxS which allows us even closer control. If you have an issue, please tell us, and if there's any way we could behave better please tell us that too.
We're a company that ships a lot of software from huge projects like Office to tiny utilities. If you've hit a pain point, we probably have too since we're our own customers. Across the range we are able to ship linking the VC DLLs dynamically without pain and saving a lot of rebuilding and servicing effort when picking up fixes as well. We've been successful this way and I think you can be too.
I apologize that as we try to improve the situation the story changes over time and takes a little bit of re-education on the current story from version to version. I'm also sorry that the shipping documentation was a little hard to understand. We're doing what we can to rectify the situation, and hopefully in the future things will get easier, clearer and more pain free.
If you have any suggestions about how we can keep a strong servicing story while making things easier for ISVs, we're definitely interested in hearing them.
There is a running joke that Microsoft never found a task it couldn't make more complicated. My variation is that a normal developer writes a Hello World program in one line of code, Microsoft writes in 10,000 lines of code and it involves COM.
Thus is the case here. Side by side native assemblies is a complex solution to a simple problem and arguably doesn't really solve it at all. The common sense solution would have been to name the DLLs according to their version. Thus, I would be linking against MFC804.DLL right now. This is an elegant solution requiring no jumping through hoops and diving in and out of the registry, adding manifests and all that nonsense. Moreover, if there was a genuine, honest to God show stopping bug and full regression testing found that it could be safely fixed in MFC804.DLL, it could be easily patched.
This is all you had to do. It could have been implemented in an hour and would have saved Microsoft hundreds of thousands of dollars in development, testing, deployment and other headaches. It would have saved us developers millions of dollars in trying to deal with a solution that has terrible support from your own tools. To put it even more directly; you created a million dollar solution for a hundred dollar problem.
That aside, for years I have been working with Embedded XP and XP/W2K installed headless. Sometimes I've had broadband access to these boxes, but sometimes I have limited, and very expensive, access. Reducing patches by 50k causes us cheers.
In addition, we like to keep our patches as simple as possible, meaning xcopy (we simply unzip the files into our binary directory during boot up.) Suddenly I have a 2MB executable that has to be downloaded and executed, not just unzipped into our binary directory. Had you done the common sense naming method, we could do exactly that and avoid DLL hell at the same time (and made the install smaller since we only need the CRT and MFC DLLs.)
Do note that even if I were currently dealing with "normal" end users, I don't want to use the side by side assemblies since they require yet another install step with too many points of failure which will (not may) generate increased calls to tech support. Calls to tech support cost real money and reflect badly on the company.
One final point: you express concern for security, but currently that is of little concern of mine in my context. Why? Because our "boxes" are so locked down it doesn't matter. Furthermore, I can't recall a single security issue with the code set we use. (Even the GDI+ issue you discussed was a non-issue for me years back because I completely controlled what files were accessed.)
Hi Joe, thanks for your comments.
In your case, where you have locked down boxes with little or no access to the internet or other input, I think statically linking may be "ok" and even make sense in some cases. (You may save time overall by dropping the dlls app local once and then all your subsequent updates can be much smaller).
Beyond that, there are two points I'd like to address.
First, I think you may have a misconception about what is required to redistribute the DLLs. The 2MB exe you describe is the VCRedist.exe file, which as my original post describes is not intended for anyone to install but people deploying with ClickOnce (not something most people use). In your case you would be better served by deploying just the DLLs you use app-local with your app. This can be done in the zip file method you describe. If instead, in your scenario, it is possible to drop the dlls once into WinSxS, and then ship dynamically linked binaries which will be smaller than the statically linked binaries, I would recommend building your own MSI as described in the article, including the MSMs for only the libraries you intend to use, dropping that, then never worrying about it again.
The second misconception, and it is a common one, is that we are using WinSxS as a side-by-side versioning mechanism. In VC's case, we are not. As you say that is handled nicely by renaming the files. Instead, we are using it as a guarantee that all requests for our DLLs can be directed to a specific version containing a fix. We are dependent on Windows for this functionality, and the functionality they provide is WinSxS. If we don't use WinSxS, apps just load whatever .dll is on the path - no guarantee it is even ours. I believe WinSxS provides strong guarantees that any request will not only load the DLL in WinSxS, but also that it is our DLL and not some other DLL with the same name that has been maliciously dropped there. This allows us to allow end users to distribute app localy allowing the xcopy/zip file deployment method, but also be redirected to the new version if there's a security fix. In the sense that we are not really using the majority of the functionality of WinSxS, I agree with you that this is an over-engineered solution. Unfortunately, we go with what we can get in terms of loading from Windows and WinSxS while giving us headaches, provides us with security guarantees we can't get otherwise.
Some of this depends on perspective. From a developer perspective it's a little bit more of a pain if you don't take the time to understand how the new WinSxS scheme works. I think this is the big hurdle as once you understand how it works, it actually ends up being pretty much the same as the old scheme with some benefits. From a library provider perspective though, since we can't guarantee the patching behavior of all our developer customers, having a mechanism to centrally provide fixes so that end users of applications which use our libraries aren't hosed by a two step process of getting fixes where we can't guarantee the middle man is being responsible is very appealing.
And to address one of your points about our tooling not really being up to date with making this process easy, I definitely agree there. I don't think too much work has been done in VC9 (Orcas) to make the situation better, but it's definitely one of the pain points we've noticed over the last two years since VC2005 shipped, and for VC10 we'd love to have a better story.
So any suggestions are definitely most welcomed.
Just a correction to my last post, the first parenthetical should have read "You may save time overall by dropping the dlls centrally once and then all your subsequent updates can be smaller". What I mean is install the libs you'll be needing to WinSxS using a custom built MSI using the MSMs you need (You can call it "YourProduct Prerequisites"), then all your future installations can just be tiny dynamically linked executables. This of course only makes sense if your going to be dropping a lot of things.
First, let me say that I am in no way opposed to providing ways of creating more secure apps -- certainly I am no fan of strncpy(). However, I think you are overreaching in considering Microsoft's experiences in application deployment and maintenance as mostly representative.
I do not use an installer, nor do I want to. I use .zip files for deployment because they are simple and universal. The largest program I have ever written, with a full GUI is 950K; I have distributed many smaller modules down to 50K. The CRT DLLs would add very significantly to the download footprint of each. In addition, none of the side-by-side scenarios you have noted work for me -- users tend to run applications directly from .zip files without supporting files, and there is no directory layout that works directly for both Windows 2000 and XP, since 2K does not support WinSxS. When manifest-based DLL lookup fails, the errors are often cryptic even to programmers, much less users. As others have said, the only CRT linking scenario that is guaranteed to work is static linking, and everything else is a support hassle. For applications which make light use of the CRT, the size overhead is minimal compared to the DLL.
More importantly, I do not desire Microsoft to update the CRT used by my program without my express permission. You have already given the reason why -- the best intended changes, even fully tested and correct in themselves, can break applications. Like Joe said, applications can use DLLs are used such that no external data ever reaches them, mitigating many security issues in those modules. The necessary API break case you speak of would be very inconvenient, especially since users would not associate the breakage with you -- they would associate it with us, the application vendors. As for pulling the update, frankly, I don't believe you. Did Microsoft pull the recent .NET Framework security update that changed the behavior of the character encoding classes and broke existing applications in ways not security related? No, users were left wondering why their apps were broken and vendors had to scramble to fix them.
I am not going to say that Microsoft should roll back its security practices. However, you must realize that your security policies, for better or for worse, are not the same as everyone else's. Furthermore, it is obnoxious and not very good design for the lowest level library in a program to be dictating application distribution policy. Static linking gives us the option of both greater flexibility and responsibility. This kind of choice is part of the reason we use C++ and native code.
Ben Anderson wrote: "having a standalone exe with no installer, the correct thing to do is to package the CRT DLLs app-local - no need to install and in the case of a security event you will be redirected to the patched version by WinSxS."
This might be correct for other Dlls, but installing the CRT-Dlls app-local is a BAD idea, at least for .NET applications. I've spent two days tracking down strange bugs that happened only on a particular production machine, until I looked in detail at the loaded modules: There were two different versions of each of the msvc...dlls, the app-local one and the one from WinSxS. This led to very strange, non-reproducible bugs. I don't know if the older WinSxS-DLLs were buggy, or if they were incompatible with the newer app-local ones. My guess is that the CLR loader loaded the WinSxS-versions.
As soon as I installed vcredist_[arch].exe everything worked fine.
Bottom line: If you want xcopy-deployment, use vcredist_[arch].exe. I wish there was a way to put all the components for my application in one folder, but I couldn't find one.
Count me as another one who'd love to link statically to avoid dependencies on dynamic CRT. Unfortunately, our app has multiple DLL modules which pass vectors and strings around, so we need the common allocator.
We didn't migrate to VC8 yet, mostly due to distribution issues. If we will, it's going to be app-local. Or maybe VC10 will show up earlier.
Anyway, this blog post was very interesting - thanks.
I think the approach here is kinda unfriendly toward installers. For example, Windows Installer has various limitations on SxS assemblies. If I have any file that self-registers or relies on a file that needs to load the VC Runtime DLLs, that file will fail to load because the SxS assemblies have not been loaded. This means that I cannot load my DLL in System Context, say if I need to write to ProgramFilesFolder or something of that nature. The obvious and simple solution is to simply package the EXE and launch it as a prerequisite, as nearly all of the mainstream commercial installer products allow.
The approach on VCRedist is pretty scary as the download page does not, in any way, explain the severity of installing it that way.
Please excuse my ignorance of some of the approaches for VC9; however, I think the SxS merge module only approach severely limits deployment capability and locks you in to a situation where you're likely to experience issues.
Further, I was wondering: Is there a solid upgrade approach provided through the merge modules? Will including the VC8 MM and then changing to the VC8Sp1 MM break Windows Installer minor upgrade component rules?
Is there a thought to making the EXE Redist approach realistic in the future without the huge side-affects?
Just some thoughts :)
Is it possible to use the merge modules if you do not create a Windows Installer? Can you somehow install the merge modules by launching them on your own? (not sure this makes sense)
Currently in our installers we use the VCRedist*.exe because we create our installers with Inno Setup, but it sounds like we should switch to copying the DLLs or using the merge modules.
The idea behind SxS is good. The implementation is bad.
I use private assemblies for CRT and ATL and bypassed almost every problem. I'm forced to put all my binaries in one folder, but that is not a big issue.
Anyway I got problems with some computers where Vs2005 was previously installed (maybe another version). The program failed to load, no way. I tryed with VC redist, with private assemblies, etc.. No way. The same dist in another (clean) computer worked well. Why?
- SxS is the worst documented feature of MSDN. No way to read a document containing the way it works in a clear manner. I mean , how it REALLY works.
"How to deploy VC++ apps" doc is good, but it doesn't cover every possible scenario... Approximative, I would say.
- It is not clear how SxS and manifests work with COM dlls, with dependent DLLs, etc... (i.e. sometimes I get themes enabled anyway, sometimes not... why?)
- It is really not clear how manifest, redirection, COM isolation , isolation aware compilation, etc... work in complex scenarios.
I'd like to use these features from visual C++ projects, but I was never able to do that, and I'm using VC from years now...
- Mixed RTM & SP1 deployment never worked, using manifests, shared assemblies, etc...
I don't see the point in using assemblies for CRT:
- If I use redirection from RTM to SP1, I could break things out for non-recompiled software.
- If I use Side by side, I get two copies of the CRT in memory , the same as using a static lib.
So why don't simply overwrite the CRT DLL and let programmers be happy ? :)
- Using non MSI tools or merge modules, needed to install in different location in Win2000 or Win > 2000. Not really good.
And there's not instruction for deployment in such cases.
- PLEASE do not force the user to use assemblies, and do not force the user to include manifests, at least for "x-copy" deployment.
(Sorry for my bad english)
To VC team: I won't never deploy a CRT or MFC dll patch "alone", I don't think anyone will do that. I will always send it with a new version of the software, and I'd like that Windows Update doesn't interfere with my application, breaking things out, specially if I deploy private assemblies.
Conclusion : I'm not able to use static libs because I have multiple DLL's in the same project, but if I could, I would!
Wow, thanks everyone for your posts! I'll try to respond to most questions / posts, forgive me if I miss something.
In reverse order:
Your issue where you couldn't get your app to load sounds strange. You didn't have a mismatch between what you had compiled for and what you were redisting did you? Or maybe you had a prerelease version installed?
I totally agree with you that SxS isn't super well documented. A lot of it is black magic to me. As for your questions about COM, I'm not entirely sure which complex scenarios you're referring to, but a lot of what happens falls out of how the Windows loader works and what WinSxS does. I believe you may be seeing the themed look sometimes and not others based on the order in which you load binaries and whether any of them has loaded the common controls DLL with themes since those things get reused by the loader if possible. I've found the Windows Internals books helpful in understanding what might be going on in situations like this. I'm not sure if they're up to date now or not so I'm not sure if they include WinSxS info, but check them out - they're a helpful tool in general.
As for your comment about redirection from RTM to SP1 - actually you will should not break anything, and if you do you should file a bug and request a QFE from support if you need it. We put a lot of work into making SP's and QFEs binary compatible with previous versions meaning if you compile against RTM and onward, all future QFE and SP VC++ libs DLLs should work with your bits. Note that Windows Vista and Office 2007 both work this way - they built with and shipped against one version and as users install other software with updated DLLs, they are redirected to use the newer DLLs. No issues so far :). Please note that msvcrt.dll along with the various MFCs shipped with the OS are also patched from time to time to fix security holes and that sort of thing and in recent years I don't believe that has caused issues.
I believe the common practice to workaround the limitations you describe is to chain multiple MSIs into your installer so that you install the SxS stuff first, then your app. I'm not really a setup guy though, so I'm not sure about some of your other questions. I'll see if I can get a setup guy to take a look at some of these posts, but if not, check out Heath Stewart's blog here: http://blogs.msdn.com/heaths/default.aspx and maybe he can help you if you post a question in the comments of an appropriate post.
Thanks for your post :). I'm curious - is the reason you would use app-local deployment instead of the MSMs because you want to avoid an installer? If not, why so? When you mention you haven't migrated to VC8 yet because of distributions issues just that you would have to redist the libs or was there something further holding you back? It'd be great to know any specific issues you're worried about.
The issue you saw deploying app-local sounds kind of bad. If you could help us out by filing a bug and repro on the Connect site, that would be super helpful. Even if it's not a bug, at least we could understand the issue you are hitting. https://connect.microsoft.com/feedback/default.aspx?SiteID=210&wa=wsignin1.0
I understand your concerns and why you chose to do what you do. That is why static linking is still available and supported. I do think that the likelihood of your hitting an issue due to a CRT update is very slim, but I understand also that other people breaking you is no fun ;). I do think that with MS supplied base components like the CRT though, that the target value is very high for malicious exploitation. As such, I think it's important that we are able to update well if vulnerabilities are found. The concern though is probably not for folks like you who understand the issues and update their customers responsibly. The concern is for less informed folks, less responsible folks, or just unforseen circumstances (companies going out of business, developers no longer working on projects, that sort of thing).
I'm pretty excited about the posts we're getting on this thread. I think already I've identified a couple things we could do better in the future like a) more informative error messages on loading errors, b) better accommodate the Win2k app local scenario and c) explore ways of removing the redist burden from the developer. I think redisting via Windows Update is something worth exploring. I'm not sure whether it would be possible, and whether it would be possible to ship it as an automatic update since some users are sensitive about what gets shipped as a critical update (usually the vote is that only security updates gets shipped as critical). If you have more ideas let us know. Just to note, we are probably not going to move to a model where users can refuse a redirection. I think we're comfortable with our binary compatibility (I can't think of a single issue I've heard in relation to this) and we want to maintain central updatability given the target a component like the CRT makes.
Keep it coming
Visual C++ Libraries QA Team