-
-
Save thecodejunkie/f87c2b680f9235f33a0543b53ece1d6e to your computer and use it in GitHub Desktop.
Are there any differences to the two approaches below? I.e impliclity ending up with the package reference to | |
NETStandard.Library 1.6.1, dvs running with DisableImplicitFrameworkReferences = true and adding an explicit | |
reference to NETStandard.Library? | |
Any pros/cons for either? Any hidden/implicit impacts? | |
See https://github.com/dotnet/sdk/pull/633#issuecomment-272515440 for some context | |
<Project Sdk="Microsoft.NET.Sdk"> | |
<PropertyGroup> | |
<TargetFramework>net452;netstandard1.6</TargetFramework> | |
</PropertyGroup> | |
</Project> | |
vs. | |
<Project Sdk="Microsoft.NET.Sdk"> | |
<PropertyGroup> | |
<TargetFramework>net452;netstandard1.6</TargetFramework> | |
<DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences> | |
</PropertyGroup> | |
<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.6' "> | |
<PackageReference Include="NETStandard.Library" Version="1.6.1" /> | |
</ItemGroup> | |
</Project> |
@dsplaisted we did find one different when it comes to projects that do target net452
.
<PropertyGroup>
<TargetFramework>net452</TargetFramework>
<DisableImplicitFrameworkReferences>false</DisableImplicitFrameworkReferences>
</PropertyGroup>
<PropertyGroup>
<TargetFramework>net452</TargetFramework>
<DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>
</PropertyGroup>
For a library project we have zero interest in implicitly getting a reference to things like System.Data
, System.Drawing
and so on - it's just additional noise for no good reason.
This does not seem to play well either
<PropertyGroup Condition=" '$(TargetFramework)' == 'net452' ">
<DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>
</PropertyGroup>
Yeah, the DisableImplicitFrameworkReferences
property is used both to automatically reference the package when you're targeting .NET Core and .NET Standard, as well as to add the references to those reference assemblies when targeting .NET Framework.
If you don't want those references for .NET Framework, you could do this:
<DisableImplicitFrameworkReferences Condition=" '$(TargetFramework)' == 'net452' ">true</DisableImplicitFrameworkReferences>
However, note that the implicit references for .NET Framework were selected based on the APIs that are part of .NET Standard, so when you target .NET Standard or .NET Core (possibly only 2.0 or higher), you'll be getting most of those APIs anyway.
We might change the behavior of the implicit reference in the future. For example we might reference a newer version of the package which includes bug fixes, or we might change how the dependency is expressed when you create a NuGet package (see dotnet/sdk#992).
Gotcha
However, note that the implicit references for .NET Framework were selected based on the APIs that are part of .NET Standard, so when you target .NET Standard or .NET Core (possibly only 2.0 or higher), you'll be getting most of those APIs anyway.
Sure, but it's more about keeping a clean Dependencies/References list in the editor. Technically you've always had all APIs in the .NET Framework (since they've been installed on your local machine), but that does not mean I want all of them referenced in my project if I'm not going to use them - it just adds noise 😄
So a good middle-way would be this?
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net452;netstandard1.6</TargetFramework>
<DisableImplicitFrameworkReferencesCondition=" '$(TargetFramework)' == 'netstandard1.6' ">true</DisableImplicitFrameworkReferences>
</PropertyGroup>
</Project>
I think you have the condition backwards, but if you want a cleaner tree in solution explorer, this would make sense:
<DisableImplicitFrameworkReferencesCondition=" '$(TargetFramework)' == 'net452' ">true</DisableImplicitFrameworkReferences>
@dsplaisted opps! Yeah that's what I meant.. a copy/paste mistake 😊
Just guessing with .NET Core 3, DisableImplicitFrameworkReferences == true
and the fact it's not published on NuGet anymore doesn't go well together? Or is it still published?
Right now there shouldn't be any different between them, but I would not recommend including the reference explicitly.
We might change the behavior of the implicit reference in the future. For example we might reference a newer version of the package which includes bug fixes, or we might change how the dependency is expressed when you create a NuGet package (see dotnet/sdk#992).