Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ImplicitlyExpandDesignTimeFacades target should only add facades if a higher version isn't already referenced #1345

Closed
dsplaisted opened this issue Nov 15, 2016 · 10 comments

Comments

@dsplaisted
Copy link
Member

The ImplicitlyExpandDesignTimeFacades target adds references (specifically ReferencePath items) to the System.Runtime surface facades under the Facades folder in the reference assembly folder. However, we now also ship facades as part of NuGet packages. The facades from a NuGet package may conflict with the facades that are implicitly added via this target.

An example of an issue due to this is in dotnet/sdk#367. To repro this issue, create an ASP.NET Core web application targeting .NET Framework, update the TargetFramework property to net461, and run dotnet publish. You'll get an error because a Copy task is trying to copy two different versions of System.Runtime.Serialization.Primitives.dll to the publish folder.

I discussed this with @weshaggard and it is likely that in the future we will ship updated facades in the targeting packs that should be chosen over previous versions in NuGet packages. So we likely need a task that examines the ReferencePath items that come from ResolveAssemblyReferences and if there are any references with the same filename as an item in the Facades folder, pick the one with the higher Assembly Version.

@TheRealPiotrP
Copy link
Contributor

What's the plan for getting this fixed. I'm seeing this failure persistently when migrating dotnet new -t web PJ's to CSProj.

@mlorbetske
Copy link

Any ideas on when this would be fixed?

@oruchreis
Copy link

does any workaround exist for this?

@cdmihai
Copy link
Contributor

cdmihai commented Dec 14, 2016

Is this a .net core only problem?
Would setting $(ImplicitlyExpandDesignTimeFacades) to false fix this issue?
If not, could you instead use a Remove and Include combination when Nuget? adds those items to ReferencePath? So instead of some code saying <ReferencePath Include="@(ThingsFromNuget)/>" you'd do <ReferencePath Remove="@(ThingsFromNuget)/> <ReferencePath Include="@(ThingsFromNuget)/>"
Ultimately, would we really want an MSBuild post RAR target to fix all duplicate references by blindly choosing the latest version? What if Nuget actually resolved a version to an older one than what's on the machine?

@qmfrederik
Copy link
Contributor

qmfrederik commented Jan 4, 2017

@cdmihai I'm trying to work around this issue. I'm publishing for net462 using the .NET Core CLI (so dotnet publish).

Setting $(ImplicitlyExpandDesignTimeFacades) to false seems to cause a lot of side issues.

How would I go about and remove the duplicate assembly from @(ReferencePath)? I tried a naive <ReferencePath Remove='{full path to facade dll in NuGet package}'/> but that doesn't seem to work. Do I need to plug this in at a specific target?

Here's how my publish task is failing:

                   Task "Copy" (TaskId:351)
                     Task Parameter:
                         SourceFiles=
                             C:\Users\Frederik Carlier\.nuget\packages\system.diagnostics.tracing\4.3.0\ref\net462\System.Diagnostics.Tracing.dll
                                     CopyLocal=false
                                     CopyToPublishDirectory=Always
                                     FusionName=System.Diagnostics.Tracing, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
                                     ImageRuntime=v4.0.30319
                                     NuGetIsFrameworkReference=false
                                     NuGetSourceType=Package
                                     OriginalItemSpec=C:\Users\Frederik Carlier\.nuget\packages\system.diagnostics.tracing\4.3.0\ref\net462\System.Diagnostics.Tracing.dll
                                     Private=false
                                     ReferenceSourceTarget=ResolveAssemblyReference
                                     RelativePath=refs\System.Diagnostics.Tracing.dll
                                     ResolvedFrom={RawFileName}
                                     Version=4.1.1.0
                             C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\System.Diagnostics.Tracing.dll
                                     CopyLocal=false
                                     CopyToPublishDirectory=Always
                                     RelativePath=refs\System.Diagnostics.Tracing.dll
                                     ResolvedFrom=ImplicitlyExpandDesignTimeFacades
                                     WinMDFile=false (TaskId:351)
                     Task Parameter:DestinationFiles=bin\Release\net462\win7-x64\publish\refs\System.Diagnostics.Tracing.dll (TaskId:351)
                     Task Parameter:OverwriteReadOnlyFiles=False (TaskId:351)
00:58:44.244     1>C:\Program Files\dotnet\sdk\1.0.0-preview5-004275\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Publish.targets(128,5): error MSB3094: "DestinationFiles" refers to 1 item(s), and "SourceFiles" refers to 2 item(s). They must have the same number of items. [C:\Users\Frederik Carlier\Source\Repos\Quamotion\src\Quamotion.WebDriver\Quamotion.WebDriver.Core.csproj]
                     Output Item(s): FileWrites=bin\Release\net462\win7-x64\publish\refs\System.Diagnostics.Tracing.dll (TaskId:351)
                   Done executing task "Copy" -- FAILED. (TaskId:351)

@nateb19866
Copy link

nateb19866 commented Jan 5, 2017

I was able to bypass the framework-specific dupe errors by including

<Reference Include="[referenceHere]" />

in the csproj for each reference throwing the error, but am now having issues because two 3rd-party dependencies contain a copy of the identical .dll (same version and everything), and apparently MSBuild can't figure out which one to copy.

@kierenj
Copy link

kierenj commented Jan 6, 2017

I have issue dotnet/sdk#367 and it's a huge deal. Please - please! What are the possible workarounds, ETAs, things I can do to help diagnose, or fix, etc? I'm at a complete dead end.

I've been forced to use MSbuild because I've been forced onto dotnet-sdk preview4, because I've had a new build of a preview package of a dependency pushed on me overnight, because I've been forced onto preview builds because of many bugs in the released version of EF Core (4 here]. I can't seem to break that chain at any point. If I want to run database queries, I need to use MSBuild and get this issue.

I know I'm talking dotnet core now in the msbuild repo, but that issue was closed.

I didn't have PreserveCompilationContext in my csproj, and even with it explicitly set to false, I get this same error.

Please - any help so very eagerly accepted and appreciated!

@qmfrederik
Copy link
Contributor

dotnet/sdk#582 fixed it for me. I've left a comment there on how I installed the fix from source.

I guess this fix will also make it into the daily cli builds soon

@kierenj
Copy link

kierenj commented Jan 6, 2017

That looks fantastic, I hadn't tracked to that PR thanks. I hope that Azure App Service update their nightlies frequently too.. I'm stuck until it's there!

@vijayrkn
Copy link

vijayrkn commented Jan 6, 2017

@dsplaisted

I am running into a similar duplicate issue for System.IO.Compression. This time the first entry is resolved from {TargetFrameworkDirectory} and not from ImplicitlyExpandDesignTimeFacades . Is this a separate issue?

    SourceFiles=
        C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.IO.Compression.dll
                CopyLocal=false
                CopyToPublishDirectory=Always
                FrameworkFile=true
                FusionName=System.IO.Compression, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
                ImageRuntime=v4.0.30319
                OriginalItemSpec=System.IO.Compression
                Redist=Microsoft-Windows-CLRCoreComp.4.6.1
                ReferenceSourceTarget=ResolveAssemblyReference
                RelativePath=refs\System.IO.Compression.dll
                ResolvedFrom={TargetFrameworkDirectory}
                Version=4.0.0.0
        C:\Users\vramak\.nuget\packages\system.io.compression\4.1.0\ref\net46\System.IO.Compression.dll
                CopyLocal=false
                CopyToPublishDirectory=Always
                FusionName=System.IO.Compression, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
                ImageRuntime=v4.0.30319
                NuGetIsFrameworkReference=false
                NuGetSourceType=Package
                OriginalItemSpec=C:\Users\vramak\.nuget\packages\system.io.compression\4.1.0\ref\net46\System.IO.Compression.dll
                Private=false
                ReferenceSourceTarget=ResolveAssemblyReference
                RelativePath=refs\System.IO.Compression.dll
                ResolvedFrom={RawFileName}
                Version=4.1.0.0
        Task Parameter:DestinationFiles=c:\users\vramak\documents\visual studio 2017\Projects\WebApplication86\src\WebApplication86\obj\Release\net461\win7-x86\PublishTemp\PublishOutput\refs\System.IO.Compression.dll
        Task Parameter:OverwriteReadOnlyFiles=False
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Publish.targets(128,5): Error MSB3094: "DestinationFiles" refers to 1 item(s), and "SourceFiles" refers to 2 item(s). They must have the same number of items.
        Output Item(s): FileWrites=c:\users\vramak\documents\visual studio 2017\Projects\WebApplication86\src\WebApplication86\obj\Release\net461\win7-x86\PublishTemp\PublishOutput\refs\System.IO.Compression.dll

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
112.2
Mihai
Sprint 110.2
Andy (In Progress)
Development

No branches or pull requests