I noticed today that Evernote was in the Windows Store. I went to the store, installed Evernote, and it ran. No nextnextnextfinish-style install, it just worked and it worked nicely. It's a Win32 app and it appears to use NodeWebKit for part of it's UI. But it's a Windows app, just like VB6 apps and just like .NET apps and just like UWP (Universal Windows Platform) apps, so I found this to be pretty cool. Now that the Evernote app is a store app it can use Windows 10 specific features like Live Tiles and Notifications and it'll be always up to date.

The Windows Store is starting (slowly) to roll out and include existing desktop apps and games by building and packaging those apps using the Universal Windows Platform. This was called "Project Centennial" when they announced it at the BUILD conference. It lets you basically put any Windows App in the Windows Store, which is cool. Apps that live there are safe, won't mess up your machine, and are quickly installed and uninstalled.

Here's some of the details about what's happening with your app behind the scenes, from this article. This is one of the main benefits of the Windows Store. Apps from the Store can't mess up your system on a global scale.

[The app] runs in a special environment where any accesses that the app makes to the file system and to the Registry are redirected. The file named Registry.dat is used for Registry redirection. It's actually a Registry hive, so you can view it in the Windows Registry Editor (Regedit). When it comes to the file system, the only thing redirected is the AppData folder, and it is redirected to the same location that app data is stored for all UWP apps. This location is known as the local app data store, and you access it by using the ApplicationData.LocalFolderproperty. This way, your code is already ported to read and write app data in the correct place without you doing anything. And you can also write there directly. One benefit of file system redirection is a cleaner uninstall experience.

The "DesktopAppConverter" is now packaged in the Windows Store as well, even though it runs at the command prompt! If your Windows Desktop app has a "silent installer" then you can run this DesktopAppConvertor on your installer to make an APPX package that you can then theoretically upload to the Store.

NOTE: This "Centennial" technology is in Windows 10 AU, so if you haven't auto-updated yet, you can get AU now.

They are also working with install vendors like InstallShield and WiX to so their installation creation apps will create Windows Store apps with the Desktop Bridge automatically. This way your existing MSIs and stuff can turn into UWP packages and live in the store.

It looks like there are a few ways to make your existing Windows apps into Windows 10 Store-ready apps. You can use this DesktopAppConverter and run it in your existing silent installer. Once you've made your app a Store App, you can "light up" your app with Live Tiles and Notifications and other features with code. Check out the https://github.com/Microsoft/DesktopBridgeToUWP-Samples GitHub Repro with samples that show you how to add Tiles or Background tasks. You can use [Conditional("DesktopUWP")] compilation if you have both a Windows Store and Windows desktop version of your app with a traditional installer.

If your app is a simple Xcopy-deploy app that has no installer, it's even easier. To prove this I installed Visual Basic 6 on my Windows 10 machine. OH YES I DID.

NOTE: I am using VB6 as a fun but also very cool example. VB6 is long out of support but apps created with it still run great on Windows because they are win32 apps. For me, this means that if I had a VB6 app that I wanted to move into the Store and widen my audience, I could.

I made a quick little Project1.exe in VB6 that runs on its own.

I made an AppxManifest.xml with these contents following this HelloWorld sample.

In the folder is my Project1.exe long with an Assets folder with my logo and a few PNGs.

Now I can run the DesktopAppConverter if I have a quiet installer, but since I've just got a small xcopyable app, I'll run this to test on my local machine.

Add-AppxPackage -register .\AppxManifest.xml

And now my little VB6 app is installed locally and in my Start Menu.

When I am ready to get my app ready for production and submission to the Store I'll follow the guidance and docs here and use Visual Studio, or just do the work manually at the command line with the MakeAppx and SignTool utilities.

"C:\Program Files (x86)\Windows Kits\10\bin\x86\makeappx" pack /d . /p Project1.appx

Later I'll buy a code signing cert, but for now I'll make a fake local one, trust it, and make a pfx cert.

"C:\Program Files (x86)\Windows Kits\10\bin\x86\makecert" /n "CN=HanselmanVB6" /r /pe /h /0 /eku "1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13" /e 12/31/2016 /sv MyLocalKey1.pvk MyLocalKey1.cer

"C:\Program Files (x86)\Windows Kits\10\bin\x86\pvk2pfx" -po -pvk MyLocalKey1.pvk -spc MyLocalKey1.cer -pfx MyLocalKey1.pfx

certutil -user -addstore Root MyLocalKey1.cer

Now I'll sign my Appx.

NOTE: Make sure the Identity in the AppxManifest matches the code signing cert's CN=Identity. That's the FULL string from the cert. Otherwise you'll see weird stuff in your Event Viewer in Microsoft|Windows\AppxPackagingOM|Microsoft-Windows-AppxPackaging/Operational like "error 0x8007000B: The app manifest publisher name (CN=HanselmanVB6, O=Hanselman, L=Portland, S=OR, C=USA) must match the subject name of the signing certificate exactly (CN=HanselmanVB6)."

I'll use a command line like this. Remember that Visual Studio can hide a lot of this, but since I'm doing it manually it's good to understand the details.

"C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe" sign /debug /fd SHA256 /a /f MyLocalKey1.pfx Project1.appx



The following certificates were considered:

Issued to: HanselmanVB6

Issued by: HanselmanVB6

Expires: Sat Dec 31 00:00:00 2016

SHA1 hash: 19F384D1D0BD33F107B2D7344C4CA40F2A557749



After EKU filter, 1 certs were left.

After expiry filter, 1 certs were left.

After Private Key filter, 1 certs were left.

The following certificate was selected:

Issued to: HanselmanVB6

Issued by: HanselmanVB6

Expires: Sat Dec 31 00:00:00 2016

SHA1 hash: 19F384D1D0BD33F107B2D7344C4CA40F2A557749





The following additional certificates will be attached:

Done Adding Additional Store

Successfully signed: Project1.appx



Number of files successfully Signed: 1

Number of warnings: 0

Number of errors: 0

Now I've got a (local developer) signed, packaged Appx that has a VB6 app inside it. If I double click I'll get the Appx installer, but what I really want to do is sign it with a real cert and put it in the Windows Store!

Here's the app running. Pretty amazing UX, I know.

It's early days, IMHO, but I'm looking forward to a time when I can go to the Windows Store and get my favorite apps like Windows Open Live Writer, Office, Slack, and more! Now's the time for you to start exploring these tools.

Related Links

Sponsor: Big thanks to Redgate for sponsoring the feed this week. Discover the world’s most trusted SQL Server comparison tool. Enjoy a free trial of SQL Compare, the industry standard for comparing and deploying SQL Server schemas.