Microsoft.Web.Xdt 3.0.0 has a lower fileversion than 2.X

[robertmuehsig]

Some context:

We use the Microsoft.Web.Xdt package in our product to transform XMLs and after a update from version 2.1.2 to 3.0.0 we found some issues regarding the file version.

In the 2.X days we used a bindingRedirect like this:

      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Web.XmlTransform" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-15.0.0.0" newVersion="15.0.0.0" />
      </dependentAssembly>

After the update (and with the bindingRedirect in place) the xml transform resulted in an error. I resolved this issue by removing the unnessary bindingRedirect.

So far so good, but we distribute our application via MSI and I guess this could be problematic in update scenarios.

AFAIK the default MSI update behavior is to check if the file version has changed and if a newer file version is found, the .dll will be replaced. But with the 3.0 NuGet package this is not the case anymore:

(Left 2.X package, right 3.X package)

Currently, to make it "safe" I need to tell my clients to uninstall and reinstall the product, because an update probably won't update the Microsoft.Web.XmlTransform.dll.

I'm not sure if your file version "3.X" has a deeper meaning, but for compatibility it would be cool to specify a higher version than 15.

[vijayrkn]

• @joeloff

[joeloff]

@robertmuehsig you're correct. The only way around this during an upgrade is if you're able to change the location where the file is installed. This would result in changing the keypath and component GUID (assuming you're relying on stable key-path based GUIDs) associated with the file. But it can be a disruptive change

For upgrades, when do you schedule RemoveExistingProducts - at the beginning or end of the install?

Something else to try:

1. Schedule RemoveExistingProducts after InstallValidate in your upgrade authoring
2. Set REINSTALLMODE=amus

[robertmuehsig]

Currently we don't specify it explicitly, so I guess it follows the default implementation?

To be honest: I'm not really sure if this workaround is really a great fix here. Rename the dll or update the file version would be a way to fix it on your side and for all users.

[robertmuehsig]

Any chance that you might create an updated NuGet package with a higher file version?

[jzabroski]

@robertmuehsig It looks like they abandoned this project, since it did not get a release for .NET 5.0. I tried installing it with dotnet tool install -g Microsoft.Web.Xdt and it fails to install.

[vijayrkn]

@jzabroski - This project is not abandoned. The versioning of this project is not required to align with .NET Core versions because it is a library and it targets netstandard - https://github.com/dotnet/xdt/blob/main/src/Microsoft.Web.XmlTransform/Microsoft.Web.XmlTransform.csproj#L6

Since it is a library, you can't install it like a tool.

[jzabroski]

@vijayrkn That's strange - I didn't realize it wasn't a tool. I can install @nil4 's fork of this project as a <DotNetCliToolReference Include="Microsoft.DotNet.Xdt.Tools" Version="2.0.0" />

In any event, the project certainly looks abandoned judging by the bug that globs XML into really long lines making visual inspection unusable. #169

[jzabroski]

It looks like some older CLI tools can no longer be used as CLI tools, for whatever reason, and Nuget.org doesn't denote them as such. Microsoft.DotNet.Xdt.Tools is not listed as a CLI tool, even though it is a CLI tool.