-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
What's the plan for getting this fixed. I'm seeing this failure persistently when migrating |
Any ideas on when this would be fixed? |
does any workaround exist for this? |
Is this a .net core only problem? |
@cdmihai I'm trying to work around this issue. I'm publishing for Setting How would I go about and remove the duplicate assembly from Here's how my publish task is failing:
|
I was able to bypass the framework-specific dupe errors by including
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. |
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 Please - any help so very eagerly accepted and appreciated! |
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 |
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! |
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?
|
The
ImplicitlyExpandDesignTimeFacades
target adds references (specificallyReferencePath
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 tonet461
, and rundotnet publish
. You'll get an error because aCopy
task is trying to copy two different versions ofSystem.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 fromResolveAssemblyReferences
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.The text was updated successfully, but these errors were encountered: