UWP with Desktop Bridge package build automation with MSbuild

Question

Does anyone know how to automate UWP with Desktop Bridge (Desktop Extension) package build (.appxupload/.appxbundle) by using MSbuild tool?

I've got the setup like on the following blog.

For the simple UWP app (without Desktop Extension) I’m able to this with the following command:

msbuild UWP.sln /p:Configuration=Release;AppxBundle=Always;AppxBundlePlatforms=”x86|x64|ARM”;UapAppxPackageBuildMode=StoreUpload

However, when I try it on Package.wapproj I’ve got a bunch of errors. For instance, although Package project has a certificate, UWP project also demands one (why?), when I workaround that problem, msbuild demands a build.appxrecipe from bin/Debug, although I’m building Release etc.

Disfavor

Please post the error information. – Xeroderma

@XavierXie-MSFT I have the same problem as OP, helping out to get this fixed faster. I can reproduce this on a new solution with only a UWP and a Packaging project and then building the packaging project via "msbuild /p:Configuration=Release /p:Platform=x86" --- Error: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\DesktopBridge\Microsoft.DesktopBridge.targets(350,5): error : Could not find a recipe file for the referenced UWP application at '[..]\PackagingTest\PackagingTest.UWP\bin\Debug\PackagingTest.UWP. build.appxrecipe'. Please build the project. – Ruperto

Answer 1

Same experience here, but I manage to bypass the "Could not find a recipe file" error by build x86 and x64 project separately, and then run the msbuild command to package both. Here are my notes:

1. Because my solution has one Desktop Extension project, several c# projects, and a few test projects, I have to specify <AppxBundle>Always</AppxBundle> or <AppxBundle>Never</AppxBundle> in the project files, one by one.

2. Clean both x86 and x64.

3. Build x86 first. msbuild .\MyApp.sln /p:Configuration=Release /p:Platform=x86

4. Build x64. msbuild .\MyApp.sln /p:Configuration=Release /p:Platform=x64

5. Run this msbuild command in command line:

   msbuild .\MyApp.sln /p:Configuration=Debug /p:AppxBundlePlatforms="x86|x64" /p:AppxPackageDir="C:\Develop\MyApp\AppPackages\" /p:UapAppxPackageBuildMode=StoreUpload

6. Note that I have to add AppxPackageDir in the command, otherwise it will only bundle x64, not x86. I don't know why yet.

7. Then you will see all the bundle folders are created under the AppxPackageDir, both x64 and x86. The one single upload bundle will be created outside of the folders.

It takes forever to build the release builds, but it works in command line. Automation, here we go!

Fidel

Answer 2

In order to build with VS2017 using msbuild the command that succeeded for me was:

\path\to\msbuild.exe UWP.sln ^
    /m /p:platform=x86 /p:platform=x64 /p:platform=arm ^
    /p:Configuration=Release ^
    /p:AppxBundle=Always ^
    /p:AppxBundlePlatforms="x64|x86|ARM" ^
    /p:UapAppxPackageBuildMode=StoreUpload ^
    /Consoleloggerparameters:verbosity=minimal

But in order to build it with VS2019, after a lot of stress, bleeding and cursing, this worked:

First, change the content of the Package.wapproj to have

<AppxBundlePlatforms>x86|x64|arm</AppxBundlePlatforms>
<UapAppxPackageBuildMode>StoreAndSideload</UapAppxPackageBuildMode>

and then just run a single msbuild command:

\path\to\msbuild.exe UWP.sln /m ^
    /p:Configuration=Release ^
    /p:platform=x64 /p:platform=x86 /p:platform=arm ^
    /Consoleloggerparameters:verbosity=minimal ^
    /Fileloggerparameters:verbosity=quiet ^
    -nodeReuse:false

This built all the platforms and package for side-loading and upload in one shot.

I had to quiet the file logger because for multi-processor build there is a race condition for multiple ilc.exe processes where it said that ilclog.csv could not be opened because it is used by another process. Idiotic.

I tried building each platform separately without /m switch, and then build the package, and nothing worked, every time i had the recipe error. They have an open bug for recipe error - https://github.com/microsoft/msbuild/issues/4930

The above solution finally did it for vs2019.

Thank you Microsoft for making our life easy with each new release of whatever, and for making documentation so helpful and resourceful.

Aplanospore

Answer 3

It's a known issue. The relevant team have been investigating it. As some workarounds, the most obvious is to avoid multi-platform builds.

Please keep in mind that Centennial does not work in ARM, so makes no sense to include that platform. Also building for X86 and X64 to produce a bundle is somehow problematic.

You could try to build for only one platform X86 or X64 and set the AppxBundle=Never, finally build the solution not the wapproj.

Xeroderma

Well that's not really an acceptable solution as the store upload returns the following error: A previous submission for this app was released with a Windows 10 appxbundle. Subsequent submissions must continue to contain a Windows 10 appxbundle. – Ruperto

Could you delete the previous submission? Other option is to create a Flight, this will be a new submission, and then promote it. Please remember that you could also produce an appxbundle even if you target only one platform – Xeroderma

Building the solution (not the wapproj) for only one platform works but we had to drop x64 support because of this. Please follow up on this post as soon as the issue is fixed on MS side so that we can support both architectures again. – Ruperto

Answer 4

The solution is to select all projects to build, but hand select the packaging project as the main project to build:

msbuild uwp_build_test.sln /t:WapProjTemplate1:Rebuild /p:Configuration=Release /p:UapAppxPackageBuildMode=StoreAndSideload /p:AppxBundlePlatforms=“x86|x64” /p:AppxBundle=Always /p:AppxSymbolPackageEnabled=True /p:AppxPackageSigningEnabled=True

Dodson