.appxupload UWP package for Store submission doesn't contain .appxsym file

6
votes

For some reason when I've generated in VS2015 Update 2 RTM a new build of the UWP app, whose previous version is in the Store quite a while already, the newly generated .appxupload package doesn't contains application's debug/symbol data (the .appxsym) file.

Also when I've tried to upload mentioned .appxupload to the Store the following error occurred:

The submission failed with error code(s) 1300. More info about the error(s) can be found here.

And there is a short quote from the link "here" above:

UWP apps

If you are submitting a UWP app, you may see an error during preprocessing if your package file is not an .appxupload file generated by Visual Studio for the Store. Be sure that you follow the steps in Packaging Universal Windows apps for Windows 10 when creating your app's package file, and only upload the .appxupload file on the Packages page of the submission, not an appx or .appxbundle.

Another error that you might see after submitting your app is error 1300. This occurs when one or more assemblies (or the entire package) is already precompiled. To fix this issue, rebuild the app's package in Microsoft Visual Studio and then submit the newly-generated package.

So now I'm kind of blocked by this issue and can't update the app.

Does anyone have any clue?

3
windows-store-appswin-universal-appwindows-10windows-10-universalwindows-10-mobile
In Packaging Universal Windows apps for Windows 10, under Create an app package, step 3, says: Select Yes in the first dialog asking if you want to build packages to upload to the Windows Store, then click Next. If you choose No here, Visual Studio will not generate the required .appxupload package you need for store submission. Are you choosing yes or no at this point? – chue x
@chuex as far as I know selecting "Yes" at this step is the only way to get the .appxupload file created at the end and the problem I'm facing is not with just creating this file, but with the file's conten, where I'm expecting to see two files inside the package - .appx and .appxsym, but there is only one - .appx). – Sevenate
Speaking of the dialog - it is already looks different from the mentioned article - image. Seems like MS changing things to fast to update the docs in time. – Sevenate

3 Answers

5
votes

I work on the .NET Native runtime and compiler team and the symbols issue is definitely a bug in some of our authoring. It's been corrected and will be fixed with Update 3. If you'd like to apply the patch to your local machine you can make a two line edit to our targets file that lives at: "C:\Program Files (x86)\MSBuild\Microsoft\.NetNative\Microsoft.NetNative.targets". I've put a patched version here: https://gist.github.com/MattWhilden/b4f2e2ee9cc9d30fd628a5963be24d11. You can diff it with your local copy and see two additions on line 521 and 636.

I'm a bit surprised that this failed your submission as missing symbols shouldn't have that property. The only side effect I'd expect is that any nativized symbols you get from the dev center will only be able to map Type and Method names and not C#/VB line numbers. Can you send us a mail at [email protected] so we can help sort out what's happened here?

0
votes

Have you checked "Include full PDB symbol files" when you create App Packages?
enter link description here

If you don't check this, there will be no .appxsym files in .appxupload file.

And for error code 1300, according to Resolve submission errors:

Another error that you might see after submitting your app is error 1300. This occurs when one or more assemblies (or the entire package) is already precompiled. To fix this issue, rebuild the app's package in Microsoft Visual Studio and then submit the newly-generated package.

0
votes

For those who still experience this issue, check the version of the NuGet package Microsoft.NETCore.UniversalWindowsPlatform.

The version 5.2.0 seems to be problematic at this time.

Try downgrading from 5.2.0 to 5.1.0 for each project of your solution. It worked for me