Custom Action using WixToolset.Dtf.CustomAction fails build at MakeSfxCA when trying to target NET Standard 2.0

[bevanweiss]

I'm creating a new Custom Action for WiX v5, and when I create this with Heatwave inside Visual Studio 2022 it does indeed work fine.
However it creates the project as targeting .NET Framework 4.7.2. With the direction Microsoft are taking around .NET, I'd ideally like to have it be targeting .NET Standard 2.0 (so that it's still supported in the future under variants of .NET Core)

After creating a new Custom Action project, and then changing the .csproj TargetFramework from net472=>netstandard2.0, a build results in the following error:

Invalid argument: WixToolset.Dtf.WindowsInstaller.dll must be included in the list of support files. If using the MSBuild targets, make sure the assembly reference has the Private (Copy Local) flag set.

This appears to be due to the ReferenceCopyLocalPaths MSBuild property no longer including any of the assembly references for dependencies, which is referenced within the CustomAction.targets file in the locations shown below:
https://github.com/wixtoolset/wix/blob/4946477e98000db6769facea5c1cab8f50386b94/src/dtf/WixToolset.Dtf.CustomAction/WixToolset.Dtf.CustomAction.targets#L47
https://github.com/wixtoolset/wix/blob/4946477e98000db6769facea5c1cab8f50386b94/src/dtf/WixToolset.Dtf.CustomAction/WixToolset.Dtf.CustomAction.targets#L55

When replacing these two "ReferenceCopyLocalPaths" with just "ReferencePath" then it appears that things get a tiny little bit further, but the subsequent error is:

System.TypeLoadException: Could not load type 'System.Object' from assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' because the parent does not exist.

Which, if I look into the .rsp file I can see:

...
"[path redact].nuget\packages\mysql.data\8.4.0\lib\netstandard2.0\MySql.Data.dll"
"[path redact].nuget\packages\netstandard.library\2.0.3\build\netstandard2.0\ref\netstandard.dll"
"[path redact].nuget\packages\npgsql\8.0.3\lib\netstandard2.0\Npgsql.dll"
...

If I remove the netstandard.dll reference, and then re-run the same MakeSfxCA.exe command, things all seem to build 'fine'

So... it appears to build (a DLL of ~8MB, the approx size as the .NET 4.7.2) if I make the following change on https://github.com/wixtoolset/wix/blob/4946477e98000db6769facea5c1cab8f50386b94/src/dtf/WixToolset.Dtf.CustomAction/WixToolset.Dtf.CustomAction.targets#L47:

-       <CustomActionReferenceContents Include="@(ReferenceCopyLocalPaths)"
+       <CustomActionReferenceContents Include="@(ReferencePath)"
-                                     Condition=" '%(Extension)' == '.dll' or '%(Extension)' == '.exe' " />
+                                     Condition=" ('%(Extension)' == '.dll' or '%(Extension)' == '.exe') and '%(Filename)' != 'netstandard' " />

I suspect this isn't the right "fix"... but it might give some clues to someone that knows far more than me around how to get Custom Actions for netstandard+ targets.

[barnson]

DTF only supports .NET Framework, so that's probably expected.

[bevanweiss]

I tried to target .NET Standard 2.0 on the basis of the Nuget package dependency notes

The CustomAction Nuget doesn't appear to have any listed additional dependencies (that would preclude .NET Standard 2.0).
So I figured with the right MSBuild stuff, it could possibly work (and maybe it does... I still haven't tested the .NET Standard CA dll that got spat out).

I get that the .NET Standard 2.0 version of the WixToolset.Dtf.WindowsInstaller.dll is likely not as well tested (I haven't looked if there's any unit tests against this assembly).

It was a bit surprising that it was the MSBuild execution that seemed to be the breaking thing between .NET Framework and .NET Standard. I did go looking for an MSBuild conditional that was looking for .NET Framework... but maybe it is just a Microsoft change to MSBuild assembly handling between .NET Framework / .NET Standard.