0

I'm reading about Project Centennial as I'm studying how to deploy my WPF application through the Windows Store

I understand I have to input the binaries or a supported installer to have the APPX package in output. I guess I'm missing something as every new release of my application should go through the workflow. Which seems cumbersome as I'm using an unsupported installer (ClickOnce) so I have to manually keep track of the binaries in the package manifest (which seems weird as the .prj has this information)

Is it possible to give the .sln file in input? In other word, can I say to Project Centennial: "Hey, here's my .sln file, build me an APPX

Stefan Wick MSFT
  • 12,864
  • 1
  • 26
  • 47
JiBéDoublevé
  • 3,802
  • 3
  • 32
  • 51
  • 1
    UPDATE - Following the release of VS2017 you can build an AppX for Desktop Bridge directly from your SLN. More details here: http://stackoverflow.com/questions/42792941/why-use-project-centennial-when-we-have-advanced-installer – Bogdan Mitrache Mar 16 '17 at 10:42

1 Answers1

3

No, Project Centennial isn't something you can invoke to create a package. It appears to have been the name for the work that went into creating both the Desktop Bridge and the Desktop App Converter that you can invoke (now also available in the store).

To deploy a desktop app to the Windows store, first you have to create the app package. There are three general options to create a UWP App package that uses the desktop bridge:

  1. Use a tool that explicitly supports creating these packages directly. Tell it the files and other information that your package will need. (Full disclosure: my employer sells one such tool.)
  2. If you have or can create some form of traditional desktop installation, use the Desktop App Converter to convert that installation into the .appx package. Note that this tool is far from perfect, and may require continuing with option 3.
  3. Create the .appx package manually using Windows 10 SDK tools such as MakeAppx.exe and SignTool.exe (to enable local testing) directly. Note that you will need the 10.0.14393 or later version of the SDK, or need to be on Windows 10, for this to work correctly. Third party tools will probably have the same requirement. You can get started by following intstructions or using Visual Studio to create a base package that you can then modify to include desktop extensions.

Note that this is just step 1. Step 2 is actually getting it into the store. Unlike for app packages that do not use desktop extensions, ones that do cannot be submitted directly to the store. Instead you currently should fill out this contact form. (I cannot predict if or how this step may change in the future. Hopefully it will become easier someday.)

Note as well that you may need to change your .NET version; the desktop bridge only supports .NET 4.6.1 and later. See this article for further overview, including benefits, limitations, and requirements.

Community
  • 1
  • 1
Michael Urman
  • 15,286
  • 2
  • 24
  • 41