locked
Resources removed during publishing proccess

    Question

  • We have just figured out an issue we had with an application we published to the store. The .appx package worked fine when ran locally. When uploaded to the store and downloaded to the same phone we could not reach our pages.
    After 20 trials we figured out that ResourceManager could not pick up strings needed for our Xaml. The store publish process seams to have removed resources we needed. Is this a bug or are we running in to some documented behavior that we have missed?

    • Moved by Miles P - MSFT Wednesday, December 3, 2014 4:42 PM Off topic
    Tuesday, November 25, 2014 3:13 PM

Answers

  • Was this code ported from a Windows Phone 8 app?

    Try using Windows.ApplicationModel.Resources.ResourceLoader instead of System.Resources.ResourceManager. 

    I have seen one other case where ResourceManager fails to work after signing the Appx package, the solution in that case was to use ResourceLoader.


    Eric Fleck, Windows Store and Windows Phone Developer Support. If you would like to provide feedback or suggestions for future improvements to the Windows Phone SDK please go to http://wpdev.uservoice.com/ where you can post your suggestions and/or cast your votes for existing suggestions.

    Wednesday, December 3, 2014 5:27 PM
    Moderator

All replies

  • Hello Jonas,

    You must declare in the app manifest all of the capabilities that your app requires. If your app tries to access a capability that it has not declared, it will be blocked once your app is processed by the store. It is also possible that your app may be attempting to do something that is not permitted for apps that are published to the store.

    What are the strings that you are trying to access?

    -Eric


    Windows and Windows Phone Dev Center Support

    Send us your feedback about the Windows Platform

    Wednesday, November 26, 2014 8:49 PM
  • The line we had to remove to get the application working after publish was in the LoginPage and in the method OnNavigatedTo

    This is some pseudo code showing what we had to remove.

    LoginPage::OnNavigatedTo(...)

    {

    ...               

    if(AppTexts.ResourceManager != null)

    {

    stringaboutText = AppTexts.ResourceManager.GetString("About", CultureInfo.CurrentCulture);

    }

    ...

    Then these lines where in, the application froze and we saw a black screen. When removing all references to ResourceManager the application works fine. Something has happened to the application during the store publish process to cause this behavior. My guess was that resources had been removed (?). There are no reference to resources for the application capabilities so that could not be it. The main problem for us is that this was so hard to debug. Difference in behavior after the .appxbundle file is uploaded to the store is a nightmare. The only way we could figure out how to debug this was to comment out code and do a new release. No exceptions where thrown.

    Monday, December 1, 2014 8:56 AM
  • Was this code ported from a Windows Phone 8 app?

    Try using Windows.ApplicationModel.Resources.ResourceLoader instead of System.Resources.ResourceManager. 

    I have seen one other case where ResourceManager fails to work after signing the Appx package, the solution in that case was to use ResourceLoader.


    Eric Fleck, Windows Store and Windows Phone Developer Support. If you would like to provide feedback or suggestions for future improvements to the Windows Phone SDK please go to http://wpdev.uservoice.com/ where you can post your suggestions and/or cast your votes for existing suggestions.

    Wednesday, December 3, 2014 5:27 PM
    Moderator
  • This is a WP8.1 project, sorry if that was not clear. We have solved the issue, we have as you say stopped using the ResourceManager. We had even before starting this thread.  

    The main reason we reported this was for your (MS) benefit. I guess you are doing what you can to make the release experience for WP store apps as smooth as possible. This was a big blocker for us until we figured out what line of code that caused this. Ideally you could make some fix on your end to make sure that this does not happen even if is no longer an issue for our team.

    Thanks

    Friday, December 5, 2014 8:36 AM