Workflow XAML compiler is broken with netstandard assemblies

[ericstj]

Repro:

1. Create a workflow console application targeting net461.
2. Add a reference to a netstandard1.5 or later library.

Expected:
Compiles w/o warnings and runs successfully.

Actual:
Warnings

Severity	Code	Description	Project	File	Line	Suppression State
Warning		Could not compile workflow expressions because file 'file:///C:\Program Files (x86)\Microsoft Visual Studio\IntPreview\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\netfx.force.conflicts.dll' has an incorrect format. Workflows in this project may still run, if they do not require expression compilation. If the file is a platform-specific library or executable, consider building the project using MSBuild.exe from a command prompt of the targeted platform.	WorkflowConsoleApplication1	C:\windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Xaml.targets	347	
Warning		Could not run workflow validation because file 'netfx.force.conflicts, PublicKeyToken=cc7b13ffcd2ddd51' has an incorrect format. This will not prevent workflows from running; but any workflow that has a validation error will fail at runtime. If the file is a platform-specific library or executable, consider building the project using MSBuild.exe from a command prompt of the targeted platform.	WorkflowConsoleApplication1	C:\windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Xaml.targets	347	

Applying the netfx.force.conflicts workaround merely causes the warning to occur on the next reference dll (system.data.common).

When in this state workflows will not execute, see https://github.com/dotnet/corefx/issues/23439.

We may need to give up on passing reference assemblies to desktop projects. If that's the case we'd switch to just passing in the libs to the compiler and we'd need to build a version of netfx.force.conflicts.dll that doesn't have the reference assembly attribute.

/cc @dsplaisted @weshaggard

[darrensteadman]

The work around posted on my original bug is only partially working.

The netstandard2.0 assembly I'm referencing has a dependency on System.IO.Ports which isn't included in the msbuild refs folder and instead is brought down as a nuget package.

After applying the workaround I now get the following.

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Xaml.targets(347,5): warning : Could not run workflow validation because file 'System.IO.Ports, PublicKeyToken=cc7b13ffcd2ddd51' has an incorrect format. This will not prevent workflows from running; but any workflow that has a validation error will fail at runtime. If the file is a platform-specific library or executable, consider building the project using MSBuild.exe from a command prompt of the targeted platform.
1>C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Xaml.targets(347,5): warning : Could not compile workflow expressions because file 'file:///C:\Users\username_here\.nuget\packages\System.IO.Ports\4.4.0\ref\net461\System.IO.Ports.dll' has an incorrect format. Workflows in this project may still run, if they do not require expression compilation. If the file is a platform-specific library or executable, consider building the project using MSBuild.exe from a command prompt of the targeted platform.

[ericstj]

I see. Yes, any package might use reference assemblies and cause this problem.

[darrensteadman]

Any chance you have a work around for this problem as it's going to cause us some big issues in the next few days if we can't get around it somehow?

[ericstj]

The big hammer would be to do something similar to what I did here, but for all NuGet references, right after the nuget target raises them to items. That can be limited to the items that have duplicates in Ref/CopyLocal with different files. I'll try to get to this later today.

[darrensteadman]

Awesome, thanks for looking into it.

[ericstj]

Here's what I came up with:

  <Target Name="ReplaceRefWithLib" BeforeTargets="ResolveAssemblyReferences">
    <ItemGroup>
      <_noCopyRefs Include="@(Reference)" Condition="'%(Reference.Private)' == 'false'"/>
      <_noCopyRefsByFileName Include="@(_noCopyRefs->'%(FileName)%(Extension)')">
        <OriginalItem>%(Identity)</OriginalItem>
      </_noCopyRefsByFileName>

      <_libByFileName Include="@(ReferenceCopyLocalPaths->'%(FileName)%(Extension)')">
        <OriginalItem>%(Identity)</OriginalItem>
      </_libByFileName>

      <_overlappingRefByFileName Include="@(_noCopyRefsByFileName)" Condition="'@(_noCopyRefsByFileName)' == '@(_libByFileName)' AND '%(Identity)' != ''" />
      <_overlappingLibByFileName Include="@(_libByFileName)" Condition="'@(_noCopyRefsByFileName)' == '@(_libByFileName)' AND '%(Identity)' != ''" />

      <_overlappingRef Include="@(_overlappingRefByFileName->'%(OriginalItem)')" />
      <_overlappingLib Include="@(_overlappingLibByFileName->'%(OriginalItem)')" />
    </ItemGroup>

    <ItemGroup Condition="'@(_overlappingRef)' != ''">
      <Reference Remove="@(_overlappingRef)" />
      <Reference Include="@(_overlappingLib)">
        <Private>false</Private>
      </Reference>
    </ItemGroup>
  </Target>

  <Target Name="RemoveNetFxForceConflicts" AfterTargets="ResolveAssemblyReferences">
    <ItemGroup>
      <ReferencePath Remove="@(ReferencePath)" Condition="'%(FileName)' == 'netfx.force.conflicts'" />
    </ItemGroup>
  </Target>

This is a bit of hammer, but its close to the behavior you get anyways with packages.config (barring any bugs in my target).

[darrensteadman]

Thanks, I'll give it a go first thing in the morning (UK) when I'm back in the office.

[darrensteadman]

It looks like that has solved our problem.

Will a global fix be put into a release at some point?

Thanks for all the help

[ericstj]

I think that's up to the SDK team. Follow this issue to determine what the resolution will be.