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

Question

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?

Answer 1

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?