If you have shipped software built using Visual C++, you probably have had to think about deploying C++ Runtime DLLs. If your binaries dynamically link to the C++ Libraries, then your desktop apps probably deploy C++ Runtime using VCRedist, merge modules or by copying C++ Runtime DLLs alongside your own binaries. In this blog post, we are going to look at how this problem has been addressed for Windows 8 Store apps that are written entirely using C++ or contain some components written using C++.
Windows 8 has reimagined the deployment model for Store apps. As a developer, you don't write routines to install or uninstall your Windows Store app. Instead, you package your app and submit it to the Windows Store. Users acquire your app from the Windows Store as an app package. Windows uses information in an app package to install the app on a per-user basis, and ensures that all traces of the app are gone from the device after all users who installed the app uninstall it. There are more details about this new model here.
Having a uniform deployment model simplifies the lives of app developers and having a single trusted source of apps in the form of the Store, provides greater confidence to the end-users. This in turns helps the ecosystem.
Usually an app package is a fully contained, self-sufficient unit of deployment that contains all binaries, resources, assets etc. of your app. But there are times when you need to express dependencies on some external components such as the C++ Runtime DLLs. In order to provide this functionality, we have created a special package called the C++ Runtime package. This package is special in the sense that it is a Windows Component Library which other packages can depend on and which can be shared by multiple packages. This package contains all the C++ runtime DLLs relevant for Windows Store apps. If an app package specifies a dependency on the C++ Runtime package then at runtime, the app is able to load the C++ Runtime DLLs from the dependency package.
If you use Visual Studio 2012 to create your C++ app package, then VS automatically introduces a reference into your app’s AppXManifest.xml which basically expresses a dependency on the C++ Runtime package.
The C++ Runtime packages are already on the Store. So when you upload your C++ app (with a C++ Runtime dependency) to the Store, the Store is smart enough to associate your app with the latest C++ Runtime package version. Now whenever an end-user downloads your app from the Store, they also get the C++ Runtime package along with your app. The dependency package is downloaded only if it is not already present on the end-user’s machine or the version number on the end-user’s machine is less than the latest dependency package on the Store.
In order to express C++ Runtime dependency for C++ apps and to mimic the same runtime behavior on developer’s machines as would be seen on the end-user’s machines, we make use of the new Visual Studio Extension SDK mechanism.
If you look under the folder “Program Files (x86)\Microsoft SDKs\Windows\v8.0\ExtensionSDKs” on your machine, you will see a list of SDKs that your Windows Store apps can take advantage of using the Visual Studio “Add Reference” feature. For example, if I create a C++ Windows 8 Store project in VS, and invoke the “Add Reference” dialog, here is what it looks like on my machine:
You will notice that although the above mentioned folder contains an entry called “Microsoft.VCLibs” (which is basically the Extension SDK for C++ Runtime), it is not listed in the “Add Reference” dialog. This is because when you build a C++ project, VS automatically inserts a reference from your project to the Microsoft.VCLibs SDK.
So what really happens as a result of adding this SDK reference?
A couple of things:
1) When you build your app, the AppxManifest.xml file (that describes the properties of your package to Windows) automatically gets a dependency on the C++ Runtime package. If you look at the AppxManifest.xml file for your app package, you will see a section like the below:
<Dependencies> <PackageDependency Name="Microsoft.VCLibs.110.00" MinVersion="11.0.50727.1" /></Dependencies>
This basically means your app package now requires that before it installs, a package with the name of Microsoft.VCLibs.110.00 (the C++ Runtime package) and at least a version of 11.0.50727.1 (the Visual Studio 2012 RTM version) must also be installed on the machine.
2) If you were installing this app from the Store, then as described earlier, Store will automatically push down the dependency package also. However, when you just want to debug the app on your developer machine, Visual Studio sees that your project has a reference to the Microsoft.VCLibs SDK so it knows that at runtime (when you hit F5 to run your app), it needs to deploy the C++ Runtime package (found at “Program Files (x86)\Microsoft SDKs\Windows\v8.0\ExtensionSDKs\Microsoft.VCLibs\11.0\AppX\Retail\x86”) along with your app. This way the runtime behavior is similar to what would be seen on an end-user’s machine.
If you examine the contents of the folder “Program Files (x86)\Microsoft SDKs\Windows\v8.0\ExtensionSDKs\Microsoft.VCLibs\11.0\AppX”, you will notice that it contains both debug and release packages for all architectures. Depending on the configuration of your project (debug or release), VS inserts the dependency on the appropriate C++ runtime package (debug or release). The debug packages are only meant for debugging purposes (used at F5) and are not uploaded to the Store. Which means that any app package expressing a dependency on the debug C++ Runtime package will not be accepted during Store submission.
A great thing about Windows 8 Store apps is that it is really easy to build hybrid apps in which different components of the apps can be written in different languages and can talk to each other easily using the Windows Runtime technology (see here for an example).
You will probably notice that in most cases, you as a Windows 8 Store app developer have to rarely think about the C++ Runtime. It is mostly handled for you by Visual Studio and by the Store. As always, we are happy to receive any feedback you might have about the above solutions. We are always looking to improve both the libraries functionality as well as the deployment process.
I think you've make a big mistake here.
Windows 3.x had DLL problems. Windows 95, NT, XP, and 7 (intentionally omitting ME and Vista) had. Yes, W7 has DLL problems. Sometimes SxS becomes crazy and you need to reinstall Windows. Or user mess with SxS folder because it is bigger than the sum of all other folders.
And now, W8 RT will have DLL hell too. The same DLL Hell that had all Windows. Is it so difficult to deploy an App with ALL of its DLLs? System knows installed applications, and can visit their local C++ runtime DLLs and update them if a needed.
Instead of that you make a new baroque deploy scenario that surely will have problems. What happens is system updates a DLL that breaks an installed App due a change in DLL internal that is not covered by the App (has had happened in all Windows versions?
Why not deploy *all* needed DLLs in App folder? Separate DLL code load for process.
@RFOG - that approach has issues as well. What if Microsoft releases a security fix the the C++ runtime? Do they have to scan all application folders and update the DLLs there?
Actually at that point, why not enforce static linking of the C++ runtime?
Out of topic but when will you guys add more support for C++11? Those guys who are responsible for adding support for C++11 STANDARD in VS 2012 should be ashamed
@RFOG: Isolation vs. serviceability is an old debate. Some people prefer control while others want to have the ability to be serviced. The shared package model doesn't necessarily create DLL hell. Number of existing shared packages is very small and will be kept that way. Moreover, we ensure that any updates to shared packages have a really high bar and the updates are always compatible with existing apps.
@SimonRev: Fair point. Static linking has the same problem as app-local deployment. But this is good feedback. We shall definitely look into it for future.
@Asesh: You should expect to hear from us shortly about updates on the C++ 11 support.
@Asesh: is your sole purpose to troll MSDN blogs and make off topic and inflammatory comment posts? This is the third I've read just today. If this is so, kindly remove yourself from this community, the rest of us will take it from here thanks.
Another issue: The Windows Store will notify users when there's an update to an application. If the dependencies have updates released but there's no updates to the apps, the Store won't be able to indicate there are updates available as the dependencies wouldn't show up as apps.