locked
Appx packages created from command line using MSBuild have incorrect dependencies

    Question

  • I have a c++ Metro app. If i package a Release build for local distribution in Visual Studio, I can deploy it using the generated Add-AppDevPackage.ps1 script. This works as expected. If i, however, package it with a build script using msbuild, I cannot deploy it using the same script. I get the following error:

    Installing developer package...
    Found dependency package(s):
    <outputpath>\Dependencies\x86\Microsoft.VCLibs.x86.11.appx
    <outputpath>\Dependencies\x64\Microsoft.VCLibs.x64.11.appx
    Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF9, Install failed. Please contact your software vendor. (Exc
    eption from HRESULT: 0x80073CF9)
    Windows cannot install package BUILD.52617e0b-a521-4fd3-b720-a233c167c546 because framework Microsoft.VCLibs.110 was pr
    ovided but not used. This could be because a newer version of Microsoft.VCLibs.110 is already installed or package BUIL
    D.52617e0b-a521-4fd3-b720-a233c167c546 does not depend on Microsoft.VCLibs.110. Only the newest versions of packages th
    at package BUILD.52617e0b-a521-4fd3-b720-a233c167c546 depends on can be installed.
    
    NOTE: For additional information, look for [ActivityId] 00ae62c7-6680-0006-e885-ae008066cd01 in the Event Log or use th
    e command line Get-AppxLog -ActivityID 00ae62c7-6680-0006-e885-ae008066cd01
    
    At <outputpath>\Add-AppDev
    Package.ps1:366 char:13
    +             Add-AppxPackage -Path $DeveloperPackagePath.FullName -DependencyPath ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : WriteError: (F:\Projects\Roc...in32_Cheat.appx:String) [Add-AppxPackage], IOException
        + FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
    
    Error: Could not install the developer package.

    The script I'm invoking is very simple. I use this line to generate the packages:

    msbuild MYGAME.sln /p:configuration=Release /p:platform=win32 /target:Publish /p:OutDir=%outputPath%

    The build script returns no errors, and works fine for debug packages. As pointed out by the lead tester on the project, removing the existing dependencies folder and copying across dependencies generated by a Debug build, generated in the same way, works. Note that the generated build exhibits the behavior of a Release build and not a Debug build. Correct me if I'm wrong, but it seems like msbuild is telling the appx that it requires debug dependencies?

    Thanks,

    David Goemans

    Game Developer

    Codeglue

    Tuesday, July 24, 2012 1:02 PM

Answers

  • Hi Yahui,

    We actually did when rewriting our build scripts. We're not sure exactly what went wrong, but the major thing we changed was the build intermediate and temporary directories. Removing the 

    /p:OutDir=%outputPath%

    from the command line call and adding

     /target:Rebuild,Publish

    to force clearing the intermediate files. We think the previous problem was related to msbuild assuming the built files were from the correct architecture and solution config, based on their existence, but again, we're not sure. All we know is we no longer have broken packages :)

    Thanks,

    David

    • Marked as answer by David Goemans Monday, September 03, 2012 9:53 AM
    Monday, September 03, 2012 9:52 AM

All replies

  • Hi David,

    so I just tried a simple C++ Metro package but it didn't seem to reproduce for me when installing the command line version of the package. 

    if we suspect it is an issue between release and debug dependencies, could you open up powershell as an administrator and navigate to either your dependencies folder or c:\program files (x86)\Microsoft SDKs\Windows\v8.0\ExtensionSDKs\Microsoft.vclibs\11.0\appx\retail\x86 (or x64), run the command line

    add-appxpackage Microsoft.vclibs.x64.11.appx

    Go to event viewer Window key + r, eventvwr, expand the nodes Applications and services log, Microsoft, windows, appxdeployment-Server, Microsoft-windows-appxdeploymentserver/operational, do you see event ids of 400, 540, 541 around the time you issued the above command or do we have some event error entries?

    we might also want to do some comparisons between the appx (rename to a zip file) generated by Visual Studio versus command line so we can examine the contents of the zip file to see if there are any obvious differences.

    much appreciated,

    mike

    Tuesday, July 24, 2012 6:22 PM
    Moderator
  • Hi Mike,

    Thanks for the response, and sorry for my delayed answering. We struggled to reproduce the issue consistently, but when it reproduced there were some errors in the log viewer. 

    I'm really not sure what was/is happening, but I haven't had time to do more testing. For now we're just using Visual studio to perform packaging. What i did notice is the following:

    • Debug builds will not install on a machine without visual studio giving the error above. These builds can be exported from VS or command line.
    • Using a pre-build event to copy an appxmanifest ( with different properties ) over the actual project appxmanifest causes a corrupt build in our project. The post-build event must also copy the old manifest back. For some reason this results in an instant crash.
    • If we have 2 pdb files with the same name in the project - in our case 2 different architectures, they copy across to the appxsym file in the root. This causes a corrupt appxsym file which can't cleanly extract. 

    I haven't had time to double check if this applies to a sample project too, but since we have a work around, we haven't had much internal priority on this.

    Thanks,

    David

    Tuesday, July 31, 2012 2:03 PM
  • Hi David,

    Did you figure out this issue? Could you please share your solution with me? That would be appreciated very much. I meet the same issue, and don't know how to solve it.

    Thanks a lot,

    Yahui

    Tuesday, August 28, 2012 5:07 PM
  • Hi Yahui,

    We actually did when rewriting our build scripts. We're not sure exactly what went wrong, but the major thing we changed was the build intermediate and temporary directories. Removing the 

    /p:OutDir=%outputPath%

    from the command line call and adding

     /target:Rebuild,Publish

    to force clearing the intermediate files. We think the previous problem was related to msbuild assuming the built files were from the correct architecture and solution config, based on their existence, but again, we're not sure. All we know is we no longer have broken packages :)

    Thanks,

    David

    • Marked as answer by David Goemans Monday, September 03, 2012 9:53 AM
    Monday, September 03, 2012 9:52 AM