Explicit cs Implict reference of NETStandard.Library

highlight.xml

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.

@dsplaisted

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?