Creating packages with custom .appinstaller file, the settings do not take effect

[gradyal]

I've setup a Winforms project with .NET Framework 4.7.2 and using Visual Studio 16.1.2. I've also got a CI build setup the same as you did here. When I deploy locally through Visual Studio or when I generate package artifacts through the CI build, it does not use the custom .appinstaller template file that I added to the project which includes the 2018 schema, ShowPrompt="true", and UpdateBlocksActivation="true". It's generating a new .appinstaller file with the older schema without the custom settings. Is there some configuration to tell it to use the .appinstaller provided? Or is this another preview feature?

[gradyal]

So in the meantime, I'm replacing the above upgrade settings (ShowPrompt, UpdateBlocksActivation) in the .appinstaller file with Powershell in the CI build. I verified that the settings are being replaced successfully and it's deploying to an Azure App Service. But when I open the app, it's not blocking/prompting for an upgrade. It opens with the previous version and I have to close/open it again to get the new version via silent upgrade. Again, I'm not sure if I'm attempting to do something that's still in Preview. Please assist.

Here's my local machine Windows version/build info:

[rido-min]

There are 2 issues here:

1. VS does not generate the appinstaller using the template. I believe you need to use VS 16.2 (which is in preview). @edwardskrod can help.

2. UpdateBlocksActivation/ShowPrompt might require 1903. @jvintzel can confirm the required versions

/c @diverdan92

[edwardskrod]

I'm trying to determine which version of Visual Studio our App Installer Template work first went in and I can't exactly pinpoint it. I know for certain that it is in Visual Studio 16.2 Preview 1, available here: https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes-preview#16.2.0-pre.1.0

It might also be in one of the later 16.1 Previews but I'm not certain.

Did you add the .appinstaller template file by right clicking on the project, then Add -> New Item ? Or did you manually add it?

[gradyal]

@edwardskrod I added it through VS Add > New Item. So I should try downloading the 16.2 Preview 1? What about the MSBuild task in the build pipeline?

[edwardskrod]

I'm going to download 16.1.2 and take a look.

[edwardskrod]

I can confirm that the Template work is in 16.1.2. So let's get to the bottom of this.

When you say you have a WinForms project, I assume you also have a Windows Packaging Project also in the solution with the Package.appinstaller template in this project.

Did you rename the Package.appinstaller file? If yes, VS won't recognize the file.

Is it in the Windows Packaging Project in the Solution Explorer?

Did you save the solution after adding it before you Package the project? (The answer is probably 'yes' but I have to ask since the solution needs to be saved for our code to recognize the template.)

Did you package your project entirely from the command line? Or did you first navigate to: Right-click Windows Packaging Project -> Store -> Create App Packages (Opens the Packaging Wizard)

If everything looks good until now, let's try something. Open the Package.appinstaller template and change the HoursBetweenUpdateChecks to 72.

Now Open the Packaging Wizard to Create App Packages. Hit Next until you get to Configure update settings. Do you see the Check for updates has been set to "Every 3 Days"?

If not, it seems like VS isn't recognizing the Template which explains why the .appinstaller file isn't being updated.

If so, then the question is why isn't it updating.

[edwardskrod]

One last thing, what SDK is your application targeting for the Min and Max Versions? The Windows Packaging Project needs to target 17763 min version to take advantage of the App Installer features.

[gradyal]

@edwardskrod Here's what my solution looks like as of right now:

I did at one point rename the appinstaller file, but given what you said above about renaming, I just created a totally new Windows Packaging Project and removed the other one. Same result, though (not forcing an update). And yes, I saved the solution and I always use the Visual Studio packaging wizard.

And when I change the HoursBetweenUpdateChecks to 72, it is reflected in the wizard as Every 3 Days.

Here are the target and minimum versions I selected:

[gradyal]

Here's my Package.appinstaller in case you want to see it:

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="{AppInstallerUri}"
              Version="{Version}"
              xmlns="http://schemas.microsoft.com/appx/appinstaller/2018">

  <MainBundle Name="{Name}"
              Version="{Version}"
              Publisher="{Publisher}"
              Uri="{MainPackageUri}"/>

  <UpdateSettings>
    <OnLaunch HoursBetweenUpdateChecks="0" ShowPrompt="true" UpdateBlocksActivation="true"/>
  </UpdateSettings>

</AppInstaller>

[diverdan92]

@gradyal - can you try to deploy the application to a local file both (e.g. your desktop) and update this path in all the appropriate places (in the .appinstaller settings when creating the package)?

When installing from a local file path, does that create the expected behavior where updates block activation?

[edwardskrod]

With the new packaging project, is the Package.appinstaller file being generated correctly with the UpdateSettings in tact?

[gradyal]

@diverdan92 Yes, I've been doing that. I've got output going to C:\output and installer location as C:\installer. This morning, I uninstalled the app, created a new package from Visual Studio and deployed locally (using C:\output and C:\installer), installed through index.html, then created a new package and opened the app. The app opened without any prompt and I had to close it and open again at which time it silently upgraded. So same behavior there unfortunately.

@edwardskrod Yes, the settings are intact now. Progress! So I've learned that the file naming matters. At one point, I renamed the solution and the projects. I must have renamed it to match the project name.

[gradyal]

FYI, I see the 1903 Windows Update available. I'm downloading that and I'll try again and report my findings.

[diverdan92]

I think updating to 1903 will fix this issue. One thing we should check is if this functionality will be coming to the MSIX Core Library

@gradyal - what versions of Windows will you need this deployment functionality to work on?

[gradyal]

@diverdan92 That's a good question on versions of Windows. I'm checking with my contact. He's out of the office today so it might be Monday before I can get that info. Ideally I will give him an idea of what is or isn't supported upgrade scenarios per Windows version (i.e. blocking activation with a prompt is only available in 1903+, etc).

Speaking of MSIX, the packaging wizard in Visual Studio is actually creating an appxbundle file. Is there an upcoming update of Visual Studio that will begin exporting msix/msixbundle?

[gradyal]

@edwardskrod @diverdan92 Finally got upgraded to 1903 and I did get the update package prompt after that. Thanks for your help! Also, I heard back from my contact and I believe we have control over what version of Windows our end users will be running so we can specify 1903+.

[diverdan92]

Great! Let me know if there's anything else you'd like to track in this issue - otherwise I'll consider it closed :)

[diverdan92]

For Archive purposes: Blocking prompts require the 1903 version of Windows 10.

[gradyal]

@diverdan92 Can you see my question above about MSIX? Should I open a separate issue for that?

[diverdan92]

@gradyal - oh yes, I see that now. What is the minimum version set for your Windows Application Packaging Project? It should default to MSX in Visual Studio 2019, but they are virtually identical. msix functionality is effectively a super-set of .appx, so if you just rename your .appxbundle to .msixbundle (and only install the package on recent versions of Windows 10 that support msix, or you use the msix core library), then it should exhibit the same behavior.

[gradyal]

Minimum version is 1803. If it's all the same, I'm not worried about it. I just didn't want to get too far and have to convert the thing and then potentially run into trouble there. I may just rename it like you mentioned.

[edwardskrod]

@edwardskrod @diverdan92 Finally got upgraded to 1903 and I did get the update package prompt after that. Thanks for your help! Also, I heard back from my contact and I believe we have control over what version of Windows our end users will be running so we can specify 1903+.

Fantastic!

[jvintzel]

I think updating to 1903 will fix this issue. One thing we should check is if this functionality will be coming to the MSIX Core Library

@gradyal - what versions of Windows will you need this deployment functionality to work on?

Right now MSIX Core does not support auto-updating. Its in the backlog a bit as we ready the enterprise redist release. It would be great to know what OSes are required here.

[gradyal]

All, I got this working very smoothly and then the oddest thing started happening last week where the CI build (Azure Pipelines with YAML as in this example) just stopped exporting the custom appinstaller. I've spent hours trying to debug and I've not found any reasonable explanation. What's really strange is I can take the same msbuild command and arguments being run on the Microsoft-hosted build agent (from the build logs) and run it locally and it works as expected. But for some reason, the build agent uses the default template with the old schema and without ShowPrompt=true, etc.

Right now, to work around this issue, I have a Powershell script updating the file after the build task.

Here's what the build task looks like:

- task: MSBuild@1
    displayName: 'Build solution' 
    inputs:
      solution: '$(solution)'
      msbuildarguments: /p:AppInstallerUri="$(distributionUrl)" /p:UapAppxPackageBuildMode=SideLoadOnly /p:GenerateAppInstallerFile=true /p:AppxPackageSigningEnabled=false /p:AppxPackageDir=".\AppPackages"
      platform: '$(buildPlatform)'
      configuration: '$(buildConfiguration)'
      clean: true

Any ideas?

[diverdan92]

• @edwardskrod - did any Visual Studio behavior change where an update in the Azure DevOps hosted build environment would cause this issue?

@gradyal - we'll take a look. Thanks for reporting this!

[edwardskrod]

I don't think so Daniel. I can't imagine what would cause that issue.

If you can get a copy of the diagnostic logs on both the Azure pipe and the local pipe, you could compare them to see what step was missing.

[rido-min]

I don't think the hosted build agent has the latest VS updates:

@gradyal. Can you check which VS version do you have locally and compare it the hosted build agent VS version? @edwardskrod. Which version introduced the targets to support appinstaller templates?

[edwardskrod]

I am not exactly sure but it was at least 16.2. However, I believe 16.1 Preview 4 had the bits as well.

IF the build agent didn't have the right version of VS, that would certainly cause the issue.

[gradyal]

@rido-min I have VS 2019 (16.1.3) locally and I'm running the "Hosted Windows 2019 with VS2019" build agent. Looking here indicates that would be 16.0.3.

@edwardskrod I've tried comparing standard build output (whatever the default is) but not diagnostic. Is there something in particular I should be looking for where the appinstaller is exported or copied?

[gradyal]

@rido-min @edwardskrod Any additional thoughts or updates on my issue above with the MSBuild build task? Would it be better to open a new issue on that here or elsewhere?

[edwardskrod]

If the version of VS on the build agent is 16.0.3, then the build agent doesn't have a copy of Visual Studio that supports the app installer template scenario. The app installer template file will not be recognized and Visual Studio will generate an .appinstaller file without storing the custom information defined in the app installer template.

@diverdan92 Can @gradyal specify a more recent version of VS as his build agent? He needs at least VS 16.1 Preview 4.

[gradyal]

@edwardskrod @rido-min @diverdan92 I just checked your Azure Pipelines Image documentation again (here) and it looks like the version of Visual Studio Enterprise has been updated to 16.1.6+29102.190. I just commented out my Powershell workaround, generated a build, and deployed. Success! My .appinstaller changes are again taking effect and it's showing the prompt to force an update on launch.

Still not sure why it was working after we first resolved the problem and then it stopped, but I'm good now. Thank you all!

[edwardskrod]

@gradyal Good to know!

[diverdan92]

That's great news, @gradyal. Glad things are working again!