Ever since the announcements at Microsoft Ignite and subsequent blog post by the great Tim Mangan (Which you can read here), I have been itching to see what Project C is all about. Over the last couple of nights I got my first look by using the Desktop App Converter tool which allows you to convert your Win32 applications into Universal apps!
You can possibly take all of your classic Win32 applications and easily put them in the Windows Store. If vendors and developers start doing this it will greatly help Microsoft's current strategy, that's for sure!
As suggested by Microsoft this is currently a preview. It certainly feels like it's in it's early stages of development. There's quite a few moving parts and manual steps involved, which I'm sure they'll reduce in order to streamline the conversion in the future. With that out of the way, allow me to share my insight and experience.
I started by upgrading to the latest Windows 10 insider preview.
I proceeded by downloading and installing the Windows 10 SDK on my development machine. (At this moment only 64-bit Windows 10 is supported) I then downloaded and extracted the Desktop Converter tool. I used a couple of resources for getting started such as: MSDN and this great video:
You will note that the tool contains a rather large wim file. This is like a micro-VM image...that quite frankly at 3.5 GB in size is not so micro! You need to mount this VM image as the base in order to use it for creating your Universal apps:
.\DesktopAppConverter.ps1 -Setup -BaseImage .\BaseImage-14316.wim
The article I linked suggests you will be prompted to reboot. I was not prompted and it appeared that a reboot was not required but maybe you'll get prompted, who knows!? :) Don't worry if this takes a while, it did for me. Luckily you should only have to do this once per Developer machine you wish to use for converting.
The next step is to run the converter tool against a Win32 app of your choice. For your first attempt, I suggest following the video. They use VLC player as their example. I noticed that the article I linked and the video use slightly different methods. The video also leaves out the creation of the certs used to sign the app (which is required) and packs the AppX as a separate command.
I would suggest running a PowerShell (run as administrator) command such as:
.\DesktopAppConverter.ps1-ExpandedBaseImage C:\ProgramData\Microsoft\Windows\Images\BaseImage-14316 –Installer C:\Installer\vlc-2.2.2-win32.exe -InstallerArguments "/S /L=1033" -Destination C:\Output\VLC -PackageName "VLC" -Publisher "CN=VideoLAN" -Version 0.0.0.1 -MakeAppx -Verbose
Note: Ensure that only your application installer is in the installer folder, right now the process takes a copy of all files in that folder, don't put anything in that folder that's not required...do not simply use something like your Desktop or Downloads folder!
When completed, you'll want to follow the steps in the article for creating your certs e.g.:
C:\Program Files (x86)\Windows Kits\10\bin\x86> MakeCert.exe -r -h 0 -n "CN=VideoLAN" -eku 220.127.116.11.18.104.22.168.3 -pe -sv C:\Program Files (x86)\Windows Kits\10\bin\x86> pvk2pfx.exe -pvk -spc -pfx C:\Program Files (x86)\Windows Kits\10\bin\x86> signtool.exe sign -f -fd SHA256 -v C:\Output\VLC\VLC.appx
Once you've got your AppX file signed and created you can deploy and test with a PowerShell one liner:
You can change this icon, add extensions and more. I suggest you view the video I included in this post for more. Also check out the article:
As I said at the beginning of this blogpost, it's clearly a preview and the process is pretty manual. The VLC example shows a silent install for the VLC Setup, right now this is the only supported method. I look forward to the ability to just provide the installer and step through the install myself. I only tried a handful of pretty basic applications with somewhat limited success. With time I can likely resolve some of my issues by simply putting the extra dll's, or files that I need into the VFS and re-packing. It would be great if they exposed more of the isolation\filtering\IO trickery they have in play.
The method of outputting a VFS and then compiling into AppX is interesting. It kind of has a ThinApp feel to it...which can be a good thing and a bad thing. You can change your manifest file, remove files\folders etc. and then repack using a command similar to:
makeappx.exe-d C:\Output\VLC -p C:\Output\VLC\VLC.appx
The downside of this is that you have to wait for the app to compile\VFS to get populated before you can do the cleanup. When you make your changes, you then will have compile again. This could be a real bummer for large applications.
The process makes me wonder how likely vendors and developers will be to embrace this. Signed installers have not really made a huge splash previously (based on my experience in the packaging world). I guess the security enforcement is a good thing. At Ignite it was suggested that this format will also bring with it some new restrictions such as: no more ntservices or apps running in kernel and more. These restrictions are an attempt to reign in some common misuses by developers which have possibly hurt performance and even the integrity of the OS. This is a GREAT thing!
All of this seems really ambitious. During my first appearance on the Frontline Chatter podcast, when speaking about the future in the app space I had suggested that Microsoft hold all of the cards. Microsoft is the authority on the application architecture for Windows. Windows Installer tried admirably to standardize application installs starting around 2000. As a packager I can say that endeavor has not been completely successful. Unfortunately, vendors found new and interesting ways to f*ck things up, for example: using the MSI to nest an .exe installer and run as a custom action.
This new format goes even further. It's a standardized format which can be deployed via multiple deployment methods. It's also a standardized application architecture which enables you to run your 'classic' windows applications as UWP applications, which can be user installed and also run in a full-trust isolation environment.
This technology appears to borrow from App-V, though I'd guess much of that has not been completely exposed yet. I believe is has been stated that this is certainly not App-V this does not isolate the applications in quite the same way. If you are familiar with App-V, you will notice they use a similar VFS directory for the files. Something us sequencers have requested in the past is an 'output as App-V' option in Visual Studio. It looks like this may be pretty close to being ready for developers, which is great! I wonder how much more configurable this format will become over time or if they are even thinking about that. Too many configuration options can lead to issues trying to keep things standardized.
As a former Packager, I wonder what the implications of this technology will be for packaging. I guess if the Enterprise version of Windows Store takes off, Packagers may find themselves converting a clients applications in order to publish them to their internal store but time will tell on that front.
App-V has not and is not going away either by the way. In fact in the latest Windows 10 preview, App-V is in box. You can still deliver your Win32 applications using App-V. I will have a future article about this and may mention some cases in which I believe App-V would make more sense for deploying certain apps.