When getting a files in use message on .NET chainer the response is wrongly returned to .NET installer

[nirbar]

• Which version of WiX are you building with?
  3.11.1

• Which version of Visual Studio are you building with (if any)?
  VS 2019

• Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?
  3.11.1

• Which version of .NET are you building with?
  4.5.2

• If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?
  Windows Server 2016

• Describe the problem and the steps to reproduce it.
  When upgrading .NET Framework and getting a files in use message, the response is wrongly returned to the chained .NET installer

• Describe the behavior you expected and how it differed from the actual behavior.
  User selection is expected to be passed correctly to .NET installer. Currently only "Retry" is passed correctly.

Additionally it may be a good idea to automatically respond with "No" if the BA itself is on the list of processes that hold files in use.

[rseanhall]

This is surprising, since that code was presumably written by the .NET team. Can you provide more details on how to reproduce this and the log file or whatever you're using to be able to tell that something wrong is happening?

[nirbar]

Reproduce by installing .NET 4.7.2 on a clean Server 2016 machine using a managed BA built for .NET 4.5
This way the MBA is launched and holds files in use that need to be replaced by .NET 4.7.2 install. Make sure the MBA prompts on files in use. Note that files in use array for .NET chainer is different compared to that received by MSI packages- it is an array of process names, no process id intermixed.

Burn interprets results using MB_ABORTRETRYIGNORE filter, while .NET expects IDYES, IDNO, or IDRETRY.
Hence retry works ok but other values are interpreted as IDNO.

[rseanhall]

If we assume that:

• The .NET 4.0 installer expects MB_ABORTRETRYIGNORE and
• The .NET 4.7.2 installer expects MB_YESNORETRY

then the person fixing this would need to find out when the behavior changed and likely will have to add a new exe protocol.

IDYES and IDNO are answers to a question, but it's not clear what that question is.

If Burn is sending .NET files in use and MSI files in use messages to the BA in the same callback, then there probably needs to be a new one if they don't act the same.

[nirbar]

Are you suggesting that .NET4 expected different values compared to .NET 4.5?
I hadn't thought of that

The .NET chaining example indeed mentions .NET 4.5: https://github.com/microsoftarchive/msdn-code-gallery-community-0-9-non-alphabetic/blob/master/.NET%20Framework%204.5%20Chainer%20Sample/%5BC%2B%2B%5D-.NET%20Framework%204.5%20Chainer%20Sample/C%2B%2B/ChainingdotNet4.5.cpp

I can't find any .NET 4 chainer example though

[nirbar]

I found the documentation:
https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-to-get-progress-from-the-dotnet-installer
It says that .NET 4 chaining had no files-in-use support.
That means that the fix should only respond with IDYES, IDNO, IDRETRY, or IDCANCEL. No need to worry about .NET version