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 App packages and deployment
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.
C++ Runtime package
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.
C++ Runtime Extension SDK and Dependencies
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:
<PackageDependency Name=”Microsoft.VCLibs.110.00″ MinVersion=”11.0.50727.1″ />
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.
Non-C++ apps and C++ Runtime Package
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.