Steeltoe assemblies do not have strong name information

[sankar1204]

When I use nuget package Steeltoe.Extensions.Configuration.CloudFoundry I am getting an error that assembly Steeltoe.Extensions.Configuration.CloudFoundry does not have strong name

CSC : error CS8002: Referenced assembly 'Steeltoe.Extensions.Configuration.CloudFoundry, Version=1.1.1.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.
Yes its optional to sign the C# assemblies. but
but if assemblies are signed it will be useful for consumers who have to work with projects with strong signature.

[TimHess]

All future releases of Steeltoe should be signed. You can get signed packages right now if you pull 2.2.* versions from the dev feed

If you are not facing some restriction on using .NET versions newer than framework 4.5.2, we'd recommend using newer Steeltoe packages. Be aware that package names changed when 2.0 was released, so the package manager won't show them as updates.

Do you have a requirement for signed 1.x Steeltoe packages?

[sankar1204]

My requirement is to consume it on netstandard2.0 projects, I tried even Steeltoe.Extensions.Configuration.CloudFoundryCore 2.1.1, same error,

Do you have a requirement for signed 1.x Steeltoe packages? - NO

so the signed packages will be released, which I can use in netstandard2.0 projects, any timeline on this?

Thanks

[TimHess]

As mentioned, you can get the pre-release versions now - we should be merging dev into master this week if you'd rather pull from that feed as it is a bit more stable. We are expecting to release 2.2.0-RC1 in the next couple weeks and (barring any unforeseen circumstances) a GA release within a couple weeks after that.

It would actually be helpful for us if you could confirm that the signing is working as expected for you before we push packages to nuget.org if you've got time.

[sankar1204]

Tried below three packages got below errors,

Steeltoe.Extensions.Configuration.CloudFoundryCor - v 2.2.0-dev-00328
CSC : error CS8002: Referenced assembly 'Steeltoe.Extensions.Configuration.CloudFoundryBase, Version=2.2.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

Steeltoe.Extensions.Configuration.CloudFoundryAutoFac - v 2.2.0-dev-00328
CSC : error CS8002: Referenced assembly 'Steeltoe.Extensions.Configuration.CloudFoundryBase, Version=2.2.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

Steeltoe.Extensions.Configuration.CloudFoundryBase - v 2.2.0-dev-00328
CSC : error CS8002: Referenced assembly 'Steeltoe.Extensions.Configuration.CloudFoundryBase, Version=2.2.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

it seems they are not signed yet.

[TimHess]

Ah, right... I added package signing, not assembly signing.

We will look to add strong name support for the next release after 2.2. If it turns out to be trivial we can look at adding it in a patch release as well.

[sankar1204]

can you please provide the timelines of next release after 2.2 and patch release.
Thanks,
Shanakr

[TimHess]

Sorry, I don't have a real timeline to offer... We try to do feature releases approximately every 6 months. I hope to look at package signing early on in the cycle after we wrap up docs on the 2.2 release and should know more in 2-4 weeks

[madhub]

Please sign the assemblies , in many development environments can't use the unsigned assemblies

[TimHess]

I'm viewing the signing of Steeltoe assemblies as an all or nothing scenario, where we either sign all of the assemblies or none of them. Some of the assemblies allow access to internals for their corresponding test projects and thus we'll need to either sign the test assemblies as well or change how some of that works. As such, the following dependencies all need to be signed or removed before Steeltoe can ship with signed assemblies:

• BeatPulse: Please consider signing your assemblies Xabaril/AspNetCore.Diagnostics.HealthChecks#179
• HdrHistogram: Please consider signing your assemblies HdrHistogram/HdrHistogram.NET#69
• MongoDb: https://jira.mongodb.org/projects/CSHARP/issues/CSHARP-1835
• MockHttp: Add strong name to assembly richardszalay/mockhttp#1

[TimHess]

Possible tool to aid in this issue: https://github.com/dsplaisted/strongnamer

[TimHess]

• HdrHistogram appears to be stable and/or not very actively developed anymore. We can likely publish a strongnamed variant of in its current state and take it as our dependency if we can work around the rest of the issues.
• Strongnamer does not work with assemblies built for netstandard. There is a PR that has been hanging for a while that is intended to solve the issues, but I couldn't get it to work with the amount of time I had available.

[bart-vmware]

Is assembly signing still relevant to pursue for Steeltoe v4, given that since Steeltoe v3 it no longer supports running on .NET Framework?

• From https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md:

  For the most part, the majority of applications do not need strong-names. Strong-names are left over from previous eras of .NET where sandboxing needed to differentiate between code that was trusted, versus code that was untrusted. However in recent years, sandboxing via AppDomains, especially to isolate ASP.NET web applications, is no longer guaranteed and is not recommended.

• From https://docs.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.

• From https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming:

  When .NET developers complain about strong naming, what they're usually complaining about is strict assembly loading. Fortunately, this issue is isolated to .NET Framework. .NET 5+, .NET Core, Xamarin, UWP, and most other .NET implementations don't have strict assembly loading, which is the main downside of strong naming.
  One important aspect of strong naming is that it's viral: a strong named assembly can only reference other strong named assemblies. If your library isn't strong named, then you have excluded developers who are building an application or library that needs strong naming from using it.