6

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?

Community
  • 1
  • 1
Sevenate
  • 6,221
  • 3
  • 49
  • 75
  • In [Packaging Universal Windows apps for Windows 10](https://msdn.microsoft.com/en-us/windows/uwp/packaging/packaging-uwp-apps), 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 May 30 '16 at 14:54
  • @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 May 30 '16 at 16:23
  • Speaking of the dialog - it is already looks different from the mentioned article - [image](http://i.imgur.com/Yk3YuyF.png). Seems like MS changing things to fast to update the docs in time. – Sevenate May 30 '16 at 16:30

3 Answers3

5

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 dotnetnative@microsoft.com so we can help sort out what's happened here?

Sevenate
  • 6,221
  • 3
  • 49
  • 75
MattWhilden
  • 1,686
  • 13
  • 18
  • It seems like the bug fix did not make it into Update 3 RC, but the patch works fine, thanks! – Sevenate Jun 22 '16 at 00:11
  • 1
    That's correct. It'll be in Update 3 RTM. Sorry for the confusion. Happy to help. – MattWhilden Jun 22 '16 at 16:58
  • This issue appeared to me after I installed Update 3 RTM. – Václav Dajbych Jul 13 '16 at 06:44
  • @VáclavDajbych Check my answer, it will certainly help –  Jul 14 '16 at 08:56
  • 1
    Ah, sorry for being confusing. There will be an update to the Windows UWP tools (1.4.1) that will hopefully address this issue. VS releases and Windows tools releases being slightly out of alignment caused me to misspeak. Glad the patch works for you. Sorry again! – MattWhilden Jul 17 '16 at 21:49
0

Have you checked "Include full PDB symbol files" when you create App Packages?
enter link description here
(source: s-msft.com)

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.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
ZORRO
  • 528
  • 3
  • 13
  • This was the first thing I've checked before posting this question and it was checked as all 20+ submissions before (it was ON by default, actually). Also I've tried to check it OFF but this (obviously) doesn't change anything - only .appx file was in the .appxupload package after re-packaging for Store submission. – Sevenate May 30 '16 at 14:06
  • And as for 1300 - any ideas how to fix it? I've seen this text, but can't figure out what could be wrong with precompiled assemblies if the changes from previous version and the current are minimal (bugfix release) and all the packages used in app are the same in the new app version. The only thing that probably changed is that previous package was created in VS2015 **Update 1** and now I'm using VS2015 **Update 2**. – Sevenate May 30 '16 at 16:35
  • @Sevenate That's weird, if I checked "Include full PDB symbol files" I can always get .appxsym files. Have you tested in other machines? I think this may related to your environment. – ZORRO Jun 01 '16 at 07:05
  • 1
    Yes I've checked on two other machines with **VS2015 Update 2** and the result was the same. But when I did build using **VS2015 Update 1** - the .appxsym file was inside .appxupload as usual. So seems like Update 2-related issue. Let's see how submission goes this time (I'll update the post when its finish). – Sevenate Jun 01 '16 at 07:42
  • 2
    Thanks for your feedback! Yes, I can reproduce this and we will be filing a bug to track this issue. – Unni Ravindranathan Jun 02 '16 at 02:59
0

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