A couple of weeks ago Microsoft announced Project Centennial, an App-V like spinoff aimed at software vendors. This new project will develop a tool that will act as a bridge to help software vendors with classical windows apps (CWAs) to deliver versions of them as Universal Apps. These classical windows apps include both unmanaged and managed code apps such as Win32 apps, Win Forms apps, and .Net apps.This project, which does not have any public release dates, is called Project Centennial (Project C, for short). Because this project leverages App-V technology, I have been inundated with requests from the IT community asking me about it ever since the announcement.
If you would like to hear about Project C from the horse’s mouth, you should watch the video of the session from the Microsoft Build conference which is currently the only public information available from Channel 9 on Microsoft here: http://channel9.msdn.com/events/Build/2015/2-692. On the video, Microsoft’s John Sheehan describes what it is and demonstrates one app. His presentation was to a developer audience, so in this Q & A style article I will attempt to interpret some of what John said for the IT community. When the answer is in quotes, either John said it or it was on a slide. If not, this is my interpretation or re-wording. I remind you that I am speculating and do not speak for Microsoft; if I am wrong about something, tough luck.
Q: What is the purpose of Project C?
A: Project C is a tool for “Converting your Classic Windows App (CWA) to a Universal Windows App (UWA) for distribution in the Windows Store”. There are “something like 16 million CWAs” in existence and they are not available in the windows store today. Project C is a bridge to help software vendors move their products into the windows store “without having to make many changes to the source code”. In Microsoft’s view, all Independent Software Vendors (ISVs) want to be in the store and over time they will want to migrate their code to be fully UWA. This tool will help them get something out quickly and give them time to complete the process of re-writing.
The output of the converter tool will be a Universal, or AppX based, package. Internally, it will have two parts, a UWA part and a CWA part running in a full-trust isolation environment similar to App-V 5. So it will install and uninstall like a UWA, but be able to do (most of) what CWA apps do today. Once the ISV has a Project C enabled app, they can take their time to migrate portions of the app from the CWA side over to the UWA side.
Q: What’s so great about making old apps look like a Universal App?
A: Microsoft wants us to believe that once Windows 10 is out, enterprises will want apps to be user installed and all the ISVs will want to be in the Windows Store. They stress that it is all about making it easy for the end user to find, buy, and consume the app. So in part this project is dependent on enterprises going all out on Windows 10. Given what Microsoft is doing on pricing and solving the dual desktop and start menu of Windows 8, it is a reasonable bet that enterprises will move to 10. Enterprises have a lot invested in their current CWA deployments and I don’t think many are into the user self-service model for apps at this point, but Microsoft is betting that first the developers will follow and then the enterprises will change.
Q: Is this App-V?
A: I think that John actually used App-V for the demo, but he clearly said that “it won’t be App-V when the tool is released”. From the description, I believe that it will be a subset of App-V, possibly independently branched the way that ‘App-V for Servers’ was. Presumably these apps would work with App-V also on the box, but this was not addressed in the video so we don’t know.
Q: Will apps converted using Project C’s version of App-V be available without an Enterprise Agreement?
A: Unfortunately this was not addressed directly either, but I think that the implication is yes. Once an app is in the Windows Store, anyone should be able to download and buy it. John hinted that there might need to be warnings or segregation so that it is clear that there are full trust components included in the package, but Microsoft probably has not yet determined how that will work.
A version of App-V that is universally available as part of the OS is something that we have dreamed of for years. While I would like it to be the full version, I can understand the support challenges to providing such a complicated product to the consumer market.
Q: So can Enterprises use Project C on ISV apps?
A: First, it is intended for developers, who have access to the source code. An enterprise with developers might be able to gain access to the tool, but without changing source code that they don’t have access, it probably only works on simple apps, plus they will not be able to upload to the Windows Store.
Second, should an ISV use Project C and make a universal app of it, this should help you significantly. Speaking to the developers, John said “One thing that the App-V team is going to do is that if you convert to AppV, they will make sure that they can deploy and run your software. And potentially even on Windows 7”. So we don’t know exactly how this part will work, if is a conversion or import, but this sounds like a big win for enterprise IT. For the last 15 years we have wanted ISVs to directly output and support application virtualization, and through this back door we might actually get it.
Q: What is the difference between a normal UWA and a CWA converted by Project C?
A: The converted app will be in a standard AppX format (with some extra stuff), so you will be able to have it as a one click install in the Windows Store (or side-loaded), you’ll have a live tile, file type associations, and URI schemes (protocol handlers in App-V terms). But all of the traditional CWA stuff won’t be running in the Universal App container, it will run in a separate “full trust” container just like it always has.
Q: What is the difference between what is supported in a Project C app and App-V?
A: Clearly there is a subset of things that native and App-V apps can do that you can’t do in Project C, and these things will have to be removed by the ISV. Some things, like auto-updaters, should be replaced by the UWA means of doing this. A full list of what is and is not supported was not made available at this time, and it is quite likely that Microsoft just doesn’t know yet.
John clearly called out the following as not supported in Project C apps:
- “Windows NT Services”,
- “Things running in the kernel” (device drivers)
- “System Level Software” (anything not running in the user context)
- “Elevation”, meaning anything that causes a standard user to get a UAC prompt “will be blocked”.
Using parts of other apps in your app, at least in version 1. John indicated that they would like to support extensibility and plug-ins, just probably not initially. The implication was that this might be a direct UWA thing and not specific to Project C, but we can’t be sure.
John clearly called out the following as supported in Project C apps:
- “Anything else a standard app does that isn’t in the system space”.
I am guessing that there are a lot of other things that might end up in the ‘not supported’ list that you might have thought falls under the last item in the supported list but turns out is not supported, but we just don’t know yet:
- WMI Providers
- Windows Timed and Triggered Events (but they can write new UWA background triggers)
- Custom ETW Providers
- COM localsystem (out of process) running as the system to avoid UAC prompts
- Maybe DCOM
- Software Clients,
- Application Capabilities
- Shell Extensions, Browser Helper Objects, and the like
Other differences from App-V:
- I suspect that the App-V streaming and content store mode style of provisioning will not be supported in Project C, the whole package will likely have to stream down as part of installation. John did state the Microsoft performs single instance storage in the AppX store, so if multiple copies of the identical dll are in different packages, only one instance is stored on disk. That is cool.
- Taking what John said, it implies that folders and registry keys might always be “merge with local”. But it is possible that this isn't what John meant.
- “When it comes to data, the only thing we redirect is AppData”. “we are putting all that redirected stuff into Appdata LOCAL and it doesn't roam, nor does the HKCU stuff”. Whoops! So this won’t support roaming profiles. Maybe you can still use something like AppSense or other UEM product.Also, if the app tries to write anywhere other than AppData (local or roaming), such as an ini or log file in the CWA installation folder, or such as in the ProgramData folder, it will probably get a permission error when it tries to create/edit the file.
- We probably don’t get App-V scripts.
Q: How would an enterprise configure the app?
A: Today, most CWA apps have installation configuration, either via install GUI or command line switches, and they very clearly do not use the defaults that software vendors supply. Since the AppX installation is one click, this means that you get the vendor defaults. The vendor will need modify their apps to let the user set everything post install. But to make the enterprises happy, they probably also need to upgrade their code to support true Group Policy Objects so that IT can help users who may not have all of the information that they need for things like “where is the back-end database”. I’m not sure that Microsoft has fully thought out this problem yet.
Q: Can I create this in Visual Studio?
A: John stated that there is a converter that operates similar to the App-V Sequencer, so the ISV installs their software using MSI or whatever and this converter tool captures the changes and creates the AppX package. But he also said “you should just be able to generate those packages in Visual Studio Directly”. It was unclear if that is a manual thing the ISV does to create the App-X and registry hive, or if there would be an official new Project type–time will tell on that.
Q: Will Visual Studio be released in a UWA format using project C?
A: John mentioned that he is being contacted internally with interest, but if there was ever an app that needs system access and elevation, the Visual Studio debugger is certainly it.So I say no.
Q: So is this a hack or is it a vision for the future?
A: This is a temporary hack that either:
- Helps the software vendors move their products fully into Universal apps over time that can’t harm systems and bring stability to windows, solves the crappy app problem, and drives us to a user centric world instead of an IT driven world (which is a vision).
- Turns out to be a bust because you just can’t do everything you need to in a UWA app and the software vendors don’t follow along.
It is going to be fun to watch!
Q: When will it be available?
A: No date was given, only that it is not currently available.From some of the hedging that John did on some pretty big issues, I would guess that they are very early on in the development of the tool, but would probably privately work with a few important ISVs are part of the release process.
Tim Mangan is a Microsoft MVP for App-V and a Citrix CTP. He is the author of several books, including the "Windows Performance Through Caching" and "PowerShell for App-V 5" book, and can be found at TMurgent Technologies (www.tmurgent.com) where his title is "The Kahuna". There is a pretty good chance that you can catch him speaking at this year's BriForum conferences.