0

While trying to use HeaderNames.XFrameOptions, I found that it works in one of my projects and fails in another. Both are targeting .NET 6.

In my app, I need to work with the X-Frame-Options HTTP header. When possible, for maintainability reasons, I try to evade specifying constants for such standard strings myself, relying on standard constants instead. For this header's name, there is HeaderNames.XFrameOptions, available since ASP.NET Core 3.0.

By navigating to the class's implementation in VS, I found that the project where it works uses version 6.0.0.0 (.NET 6, x64) of the Microsoft.Net.Http.Headers assembly:

C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.12\Microsoft.Net.Http.Headers.dll

The project where it does not work uses version 2.2.0.0 (.NET Standard 2.0, MSIL) of the assembly:

C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.net.http.headers\2.2.0\lib\netstandard2.0\Microsoft.Net.Http.Headers.dll

The working project is the main project of my console app and the broken project is a library in the same solution, directly referenced by the console app.

When I looked into the broken project's obj\project.assets.json, I found that Microsoft.Net.Http.Headers is really used in version 2.2.0 and it is referenced by Microsoft.AspNetCore.Http.Extensions/2.2.0, which is also used in the broken project.

I used that info to reproduce the failure:

dotnet new globaljson --sdk-version 6.0.404 --roll-forward disable
dotnet new console -f net6.0
dotnet add package Microsoft.AspNetCore.Http.Extensions --version 2.2.0
echo "Console.WriteLine(Microsoft.Net.Http.Headers.HeaderNames.XFrameOptions);" > Program.cs
dotnet run

C:\Repos\playground\Program.cs(1,58): error CS0117: 'HeaderNames' does not contain a definition for 'XFrameOptions' [C:\Repos\playground\playground.csproj]

The build failed. Fix the build errors and run again.

I tried adding all the packages referenced by the working project to the repro project and it fixed it! By elimination and following the dependencies of the last remaining project, I found that the fix can be achieved by adding just a single package (AspNetCore.HealthChecks.UI.Client/6.0.5):

dotnet add package AspNetCore.HealthChecks.UI.Client --version 6.0.5
dotnet run

X-Frame-Options

I see that AspNetCore.HealthChecks.UI.Client references the Microsoft.Net.Http.Headers assembly version 6.0.0.0, but directly, as an assembly, not as a NuGet package. Sadly, the latest packaged version is 2.2.0.0.

How can I make HeaderNames.XFrameOptions work in both my projects at the same time? Is installing an irrelevant package like AspNetCore.HealthChecks.UI.Client the only solution? And is there a more straightforward way to diagnose such assembly resolution issues?

Palec
  • 12,743
  • 8
  • 69
  • 138
  • By the way, I have read the [NuGet docs on dependency resolution](https://learn.microsoft.com/en-us/nuget/concepts/dependency-resolution). – Palec Dec 14 '22 at 19:23
  • Just add this package can fix this issue? But I don't find any relationship between this package and your issue. – Xinran Shen Dec 15 '22 at 03:19
  • @XinranShen, AspNetCore.HealthChecks.UI.Client references a newer version of the Microsoft.Net.Http.Headers assembly that I need. It fixes assembly resolution by that -- the new version is found. I would reference the new version of Microsoft.Net.Http.Headers package (using NuGet's rule ["direct dependency wins"](https://learn.microsoft.com/en-us/nuget/concepts/dependency-resolution#direct-dependency-wins)), but sadly, there is no new version of the package. The new version of the assembly is not packaged. I can only reference another package using it and use the "cousin dependencies" rule. – Palec Dec 15 '22 at 06:19
  • If you do not believe, try. :-) The repro steps are really simple. You can omit the `dotnet new globaljson` step if you want to try it over a different SDK version. I believe it will be the same everywere in .NET Core. I just wanted to include the info on my specific environment. – Palec Dec 15 '22 at 06:23
  • 1
    Looks like this tackles exactly the same problem: https://github.com/dotnet/aspnetcore/issues/28630 I will need to read more on what a FrameworkReference is and whether it is OK to use it in my case. I do not think pulling the whole ASP.NET Core into my library should be needed, as I just need QueryStringBuilder, HeaderNames and maybe some other minor bits here and there. But the library is internal to our application, which I found to be a WebApplication and also use Microsoft.ApplicationInsights.AspNetCore. It just uses Microsoft.NET.Sdk in the project file (i.e. console project). – Palec Dec 15 '22 at 06:46
  • I haven't met this issue before, Thank your for sharing the solution with me, Learn a lot from this issue. – Xinran Shen Dec 15 '22 at 07:31
  • 1
    Would not mind a +1 on the question, @XinranShen. ;-) – Palec Dec 16 '22 at 11:34
  • 1
    It really seems that since .NET Core 3.0 and ASP.NET Core 3.0, the individual packages are no longer published, and the [Microsoft.AspNetCore.App shared framework](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/metapackage-app) is supposed to be used instead. Found a [relevant section in the migration guide](https://learn.microsoft.com/en-us/aspnet/core/migration/22-to-30#remove-obsolete-package-references), too. Still, it is strange that the packages are not marked as deprecated. – Palec Dec 16 '22 at 11:46
  • 1
    A bit of reading on FrameworkReference. https://github.com/dotnet/aspnetcore/issues/3612 – Palec Dec 16 '22 at 12:30
  • FrameworkReference in NuGet: https://github.com/NuGet/Home/wiki/%5BSpec%5D-FrameworkReference-in-NuGet – Palec Dec 16 '22 at 23:04
  • More info that leads me to believe that FrameworkReference is the way to go: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/target-aspnetcore#use-the-aspnet-core-shared-framework https://learn.microsoft.com/en-us/aspnet/core/fundamentals/target-aspnetcore#use-an-api-introduced-in-31 Seems that only now we will be fixing things neglected during the migration to ASP.NET Core 3.0, which was already the largest one I remember. – Palec Dec 16 '22 at 23:06
  • A nice Q&A about FrameworkReference: https://stackoverflow.com/q/64478618/2157640 – Palec Dec 16 '22 at 23:16
  • My question seems to be a very-well hidden duplicate of this: https://stackoverflow.com/q/70847263/2157640 – Palec Dec 16 '22 at 23:19

0 Answers0