Windowstemplatestudio: Microsoft.Services.Store.Engagement causes app crash in app compiled with AppCenter

Created on 25 Jun 2019  路  16Comments  路  Source: microsoft/WindowsTemplateStudio

For Bugs:

Repro steps

in VS 2019, create a brand new UWP app using the Windows Template Studio wizard.
Check the "Feedback Hub Link" feature (which uses the Microsoft.Services.Store.SDK).
Add this app to Visual Studio AppCenter, and build it from AppCenter.
Upload to the Store and install it.

Expected Behavior

Don't crash.

Actual Behavior

A unhandled exception:

Method 'StoreServicesFeedbackLauncher.IsSupported()' from assembly 'Microsoft.Services.Store.Engagement' was not included in compilation, but was referenced in SettingsViewModel.FeedbackLinkVisibility.get(). There may have been a missing assembly, or a dependency on a more recent Windows SDK release.
at OnePomodoro.Views.SettingsPage.SettingsPage_obj1_Bindings.Update_ViewModel(SettingsViewModel, Int32) + 0xa4
at OnePomodoro.Views.SettingsPage.SettingsPage_obj1_Bindings.Loading(FrameworkElement, Object) + 0x49
at System.Xml.XmlTextReaderImpl.OnDefaultAttributeUseDelegate.Invoke(IDtdDefaultAttributeInfo, XmlTextReaderImpl) + 0x2e
at Windows.Foundation.TypedEventHandler_A__wux__FrameworkElement_j__o__V___Impl.Vtbl.Invoke__n(IntPtr, Void, Void) + 0x71

System

  • VS Version: 16.1.1
  • WTS Wizard Version: 3.2.19120.1
  • WTS Template Version: 3.2.19120.1
  • Windows Build: 15.9.21.664

Here is the project repository, and here is the build log from AppCenter.

Can Close Out Soon Generated Code bug

All 16 comments

@DinoChan at what point does the app crash?

Notes from investigation so far:

  • Functionality works for me. (Can display the link and the link works.)
  • Functionality passes local WACK test.
  • All evidence is pointing to the issue being something resulting from building on AppCenter. (I'll try that next.)

@DinoChan at what point does the app crash?

When navigate to settings page it throw a unhandled exception.
It works well when it was packaged by visualstudio.

@DinoChan at what point does the app crash?

When navigate to settings page it throw a unhandled exception.
It works well when it was packaged by visualstudio.

Can you share the package built by AppCenter?

@DinoChan at what point does the app crash?

When navigate to settings page it throw a unhandled exception.
It works well when it was packaged by visualstudio.

Can you share the package built by AppCenter?

Here is the package built by AppCenter.

https://deedu-my.sharepoint.com/:u:/g/personal/j2525_ioffice_site/EcPNA-HGZ39EpPkH5-wKdUoB5lQOE4ANPBPoatdqjS-kMA?e=ycLiO1

I found that the package worked well after it was installed. But after uploading it to Store and installing it, it throws Unhandled Exception when navigating to Settings Page.

more information:

Target version: Windows 10,version 1809
Min version:Windows 10,version 1809

I used WTS to generate "DevCenterNotificationsService", which was tested locally or offline installation without any problems. However, after uploading to the store, an error will be reported after installation.

Method 'StoreServicesEngagementManager.GetDefault()' from assembly 'Microsoft.Services.Store.Engagement' was not included in compilation, but was referenced in DevCenterNotificationsService.d__0.MoveNext(). There may have been a missing assembly, or a dependency on a more recent Windows SDK release.

Just to note that this isn't being ignored.
Having some trouble with store submissions but I have got a repro for this now.

ongoing....

Think I've found the issue..... stand by


@sibille FYI. this may need to be a hotfix template release for ~3.4~ (correction: 3.3)

cc/ @DinoChan & @KevinZjYang

This is not an issue with using AppCenter. It can affect any app submitted to the store.

How to fix this in the code in your existing apps

Manually open the csproj file.

change the following lines from

    <SDKReference Include="Microsoft.Services.Store.Engagement, version=10.0">
      <Name>Microsoft Engagement Framework</Name>
    </SDKReference>
    <SDKReference Include="Microsoft.VCLibs, version=14.0">
      <Name>Visual C++ 2015 Runtime for Universal Windows Platform Apps</Name>
    </SDKReference>

to

    <SDKReference Include="Microsoft.Services.Store.Engagement, Version=10.0">
      <Name>Microsoft Engagement Framework</Name>
    </SDKReference>
    <SDKReference Include="Microsoft.VCLibs, Version=14.0">
      <Name>Visual C++ 2015 Runtime for Universal Windows Platform Apps</Name>
    </SDKReference>

In both cases, it must be Version (with a capital 'V') rather than version.

This didn't use to be an issue. It looks like something changed in the store submission/ingestion/optimization process that now makes it require a capital. (It should have been one regardless.)


Changes to the templates for apps generated in the future will follow shortly.


Follow-up/debrief/review of this issue and actions to take as a result of this to happen next week.

Great catch @mrlacey!! Version 3.3 is not shipped yet, we should definitely take this in!

@mrlacey
Thanks for your help

@mrlacey I have tested it and it is very effective. Thanks.

My retrospective notes

To the best of my detective abilities, the cause of this issue was a change to something in the store's ingestion/optimization process. While we can't change this directly, there are things we can do.

Things to do now:

  • Continue to follow up (separate to this thread) with the Store team to understand when/how this happened and how it can be avoided again in the future.
  • Review all other dependencies in currently supported options to check that there is nothing else effected. This will involve creating apps with all functionality, releasing to the store, and then verifying all code runs as expected.
  • Review automated testing to see if this is something we could check with less manual effort.

Things to do in the future:

  • Whenever a new dependency is introduced in a new (or updated) item, an app with the generated code must be checked after submitting to the store, before the related templates are shipped.
  • Code generated from templates in the future must be thoroughly checked and compared with code created directly through VS. As even the casing of a single letter can cause hard to detect bugs it's important that the output is _exactly_ the same.
  • Ideally, we should also check that any updates to dependencies don't include anything that has an issue once released through the store.

I'm open to suggestions for anything else...

Verified in
Templates version: 0.20.19199.1
Wizard version: 0.20.19199.1

@mrlacey , Hi , I have a quick question,
By any chance, could the crash that this issue might have caused, be resulting in windows event log with following exception:
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.449, time stamp: 0xb90db728
Exception code: 0xc000027b
Fault offset: 0x0000000000712ec0
Faulting process id: 0x2aa8
Faulting application start time: 0x01d5b1acb3f6532c
Faulting application path: C:\Program
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll

P.s. I have an app stuck in certification process for store submission, which is using WinTS, it got those small case Vs in its project file.
(btw, it works perfectly fine as sideload or in dev env, just when launched from store, it crashes right away on splash screen?!)
All tips & clues are much appreciated.

@mrlacey , Hi , I have a quick question,
By any chance, could the crash that this issue might have caused, be resulting in windows event log with following exception:
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.449, time stamp: 0xb90db728
Exception code: 0xc000027b
Fault offset: 0x0000000000712ec0
Faulting process id: 0x2aa8
Faulting application start time: 0x01d5b1acb3f6532c
Faulting application path: C:\Program
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll

Without more information I couldn't say, but as it's a different error, probably not.

P.s. I have an app stuck in certification process for store submission, which is using WinTS, it got those small case Vs in its project file.
(btw, it works perfectly fine as sideload or in dev env, just when launched from store, it crashes right away on splash screen?!)
All tips & clues are much appreciated.

Definitely fix the lower case v s as they can prevent dependencies loading at run-time.
Contact the store for assistance with stuck apps. I've known this happen with apps created through WinTS and without

Was this page helpful?
0 / 5 - 0 ratings