Missing Microsoft.AspNetCore.Http.Abstractions NuGet package

[CoskunSunali]

I realize that the Microsoft.AspNetCore.Http.Abstractions package is now a part of the Microsoft.NET.Sdk.Web SDK when using v3 preview.

I have a class library project which requires only the Microsoft.AspNetCore.Builder.IApplicationBuilder interface and is using SDK Microsoft.NET.Sdk because it doesn't need any of the other dependencies - there a tens of them.

Since I really need the Microsoft.AspNetCore.Builder.IApplicationBuilder, do I really have to change the SDK to .Web and live with the many additional unnecessary dependencies? Was this change intentional and if so, may I ask why?

[natemcmaster]

do I really have to change the SDK to .Web?

You should be able write a class library without using the .Web SDK. A class library targeting AspNetCore can likely be simplified to a project file that looks like this.

<Project Sdk="Microsoft.NET.Sdk">

 <PropertyGroup>
   <TargetFramework>netcoreapp3.0</TargetFramework>
 </PropertyGroup>

 <ItemGroup>
   <FrameworkReference Include="Microsoft.AspNetCore.App" />
 </ItemGroup>

</Project>

Was this change intentional and if so, may I ask why?

Yes, these changes are intentional. We're still working on updating documentation on writing class libraries for aspnetcore, and teaching Visual Studio about FrameworkReference.

Why? See these issues for more context on our choices:
#3612
#3756
#3608
#3307

cc @davidfowl @DamianEdwards

[CoskunSunali]

Ahh, I see. I tried to figure that out before creating an issue but I missed those discussions, apparently. Thank you for leading me to the issues discussing the matter.

I am not trying to start a new discussion. Just want to give some feedback.

I see that using the FrameworkReference causes a self-contained application to include unused references in the output which, unfortunately, increases the output size. For example, SignalR is rarely used (by us) and publishing a self-contained app causes its assemblies to be within the output directory.

I am afraid that might not be desired since you may add many more such assemblies into the framework in the future.

Is there a way we can reference only a list of given assemblies from the framework and get only those assemblies to be included in the publish output?

E.g.: <FrameworkAssemblyReference Include="Microsoft.AspNetCore.Hosting.Abstractions" />

Another issue I can see when I check real quick is VS not being able to understand the inner references of reference projects.

I will try to explain what I mean by giving an example.

With v2.2: Project A references NuGet package Microsoft.AspNetCore.Hosting.Abstractions and Project B references Project A. I could use types from the Microsoft.AspNetCore.Hosting.Abstractions package.

With v3.0: Project A references framework reference Microsoft.AspNetCore.App and uses some types from some assemblies from there. Project B references Project A but in case it wants to use the same types (let's say, someone developing a module for a project) the developer has to add framework reference to Microsoft.AspNetCore.App within Project B too. That adds an additional requirement which didn't exist with v2.2.

I am aware that v3.0 is just preview 1 and you are probably considering its cons and pros.

[natemcmaster]

I see that using the FrameworkReference causes a self-contained application to include unused references in the output which, unfortunately, increases the output size. For example, SignalR is rarely used (by us) and publishing a self-contained app causes its assemblies to be within the output directory.

We have to make tradeoffs, and in this case, we think a little extra disk space is worth it for the benefits of treating the shared framework as a single, atomic unit. I won't try to convince you that it's less than ideal that you end up with unused stuff in a self-contained app. There have been many discussions about this and experiments like https://github.com/mono/linker and https://github.com/dotnet/corert. But none of those has made it to production yet for .NET Core. So for now, our answer for your concerns about disk space is framework-dependent deployment. You only pay the cost of the shared framework once per machine instead of once per app.

Is there a way we can reference only a list of given assemblies from the framework and get only those assemblies to be included in the publish output?

No. The framework is treated as an single unit of references.

Another issue I can see when I check real quick is VS not being able to understand the inner references of reference projects.

The SDK and NuGet teams are working on support for flowing FrameworkReference across ProjectReference. See dotnet/sdk#2729 and dotnet/sdk#2420.

[CoskunSunali]

Thank you for the insights!

No. The framework is treated as an single unit of references.

That sucks but we will have to live with that apparently.

I will go ahead and close this issue since I got all the questions answers. Thank you!