sdk: Workflow XAML compiler is broken with netstandard assemblies

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

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Comments: 36 (20 by maintainers)

Commits related to this issue

Most upvoted comments

Here’s what I came up with:

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

      <_libByFileName Include="@(ReferenceCopyLocalPaths->'%(FileName)')">
        <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).

I’m not completely sure this is fixed.

If I remove the workaround from the csproj files it now compiles without any problems but it just throws exceptions at run time about netfx.force.conflicts. If I remove ReplaceRefWithLib I then get run time errors saying it can’t load assemblies. Looking at those assemblies it appears they are ones that reference netstandard 2.0.

It kind of looks like the problem has moved from compile time to run time.

I’m running VS 2017 15.5.1

@AjRoBSeYeR Copy-Paste those 2 targets in https://github.com/dotnet/sdk/issues/1522#issuecomment-324141767 into your project’s .csproj file.

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