search

maxkagamine / Moq.Contrib.HttpClient

A set of extension methods for mocking HttpClient and IHttpClientFactory with Moq.
MIT License
188 stars 11 forks source link

Compiler warning CS8002: Referenced assembly does not have a strong name #17

Closed udlose closed 9 months ago

udlose commented 9 months ago

I'm using Moq.Contrib.HttpClient in a .NET 8 unit test project where my assemblies need to be strong-named. I'm getting a warning referencing Moq.Contrib.HttpClient:

Warning CS8002 Referenced assembly 'Moq.Contrib.HttpClient, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

All of the other assemblies I use for unit testing are strong-named and it'd be nice to see this package add a strong-name :) . I realize I can strong-name it myself but I think that is rather hacky.

maxkagamine commented 9 months ago

Hey Dave. I was double-checking the advice on strong naming since I haven't dealt with it in a (very) long time, and it seems like they pretty much got rid of it with .NET Core/5+. According to the docs, you can safely suppress the warning:

https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

Strong naming has no benefits on .NET Core/5+. C# compiler produces CS8002 warning for strong-named assemblies referencing non-strong named assemblies. It is fine to suppress this warning for libraries that target .NET Core/5+ only.

https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named

For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.

The only reason I'm hesitant is I don't want to cause problems for .NET Framework users unnecessarily, with regards to binding redirects and such. I'd be open to publishing a SN version if it was needed for some legacy project, but I'm not sure it's worth it otherwise. When I looked around to see what other open source projects were saying, some of them pointed to this Twitter thread that suggests the .NET team might be leaning towards removing it entirely at some point:

https://twitter.com/terrajobst/status/1575598887313604609

I'm debating whether it's worth the hassle trying to remove strong naming from .NET [...] The .NET Core runtime completely ignores it; hence it's not useful. The challenge is that the build environment (MSBuild, compilers, MD readers) still honor it which makes removing it a breaking change.

Since your project is .NET 8 anyway, I would just add <NoWarn>$(NoWarn);CS8002</NoWarn> to the csproj, assuming it's not causing any other issues and you can't disable SN outright.

udlose commented 8 months ago

Hey Dave. I was double-checking the advice on strong naming since I haven't dealt with it in a (very) long time, and it seems like they pretty much got rid of it with .NET Core/5+. According to the docs, you can safely suppress the warning:

https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

Strong naming has no benefits on .NET Core/5+. C# compiler produces CS8002 warning for strong-named assemblies referencing non-strong named assemblies. It is fine to suppress this warning for libraries that target .NET Core/5+ only.

https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named

For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.

The only reason I'm hesitant is I don't want to cause problems for .NET Framework users unnecessarily, with regards to binding redirects and such. I'd be open to publishing a SN version if it was needed for some legacy project, but I'm not sure it's worth it otherwise. When I looked around to see what other open source projects were saying, some of them pointed to this Twitter thread that suggests the .NET team might be leaning towards removing it entirely at some point:

https://twitter.com/terrajobst/status/1575598887313604609

I'm debating whether it's worth the hassle trying to remove strong naming from .NET [...] The .NET Core runtime completely ignores it; hence it's not useful. The challenge is that the build environment (MSBuild, compilers, MD readers) still honor it which makes removing it a breaking change.

Since your project is .NET 8 anyway, I would just add <NoWarn>$(NoWarn);CS8002</NoWarn> to the csproj, assuming it's not causing any other issues and you can't disable SN outright.

Thank you so much for your quick response! I'll go ahead and suppress the warning.