Libraries should have a strong name

[thompson-tomo]

Is your feature request related to a problem? Please describe.
I can't use steeltoe in one of my application's due to it not having a strong name.

Describe the solution you'd like
I want the library to be signed with a signing key so that i can call it from my applications which require signing to be used.

Describe alternatives you've considered
In the past didn't have much luck in signing third party libraries. Due

Additional context

• https://learn.microsoft.com/en-us/dotnet/standard/assembly/sign-strong-name?darkschemeovr=1
• https://github.com/dotnet/runtime/blob/main/docs/project/strong-name-signing.md
• https://learn.microsoft.com/en-us/dotnet/standard/assembly/create-public-private-key-pair

[TimHess]

We've looked into this in the past and would have added done it already, but had external dependencies that weren't compatible at the time. I think those might all be gone in v4, but we also came to the conclusion it wasn't really necessary anymore. Can you elaborate a bit more about the affected application(s) and specify which version of Steeltoe you're wanting to use with it?

The original issue for this is #18

[thompson-tomo]

My use case is I am running a webservice which is hosted in an app pool in IIS. To avoid complexity of switching to net core+ it has remained with net framework 4.6.2. I want this web application to register itself with my lead application which exposes an Eureka registration endpoint. The goal here is to eliminate the need to manually configure the address of this IIS service as this introduces chances for error.

Reading through #18 my feeling is that the main libraries which are not signed can be connected to Hystrix which is deprecated in favour of Polly, hence don't have an issue if the only one's we don't sign are those which are deprecated.

On another case which might come up for me, is the it is possible that i will want to use the spring config server package to source config from my lead application, however this also won't be possible,

Note, i am needing to sign my projects which are in net framework due to the utilising internal libraries which dictate signing is mandatory otherwise they will not work.

[TimHess]

Have you considered using Steeltoe 2.5 so the .NET Framework app can register directly?

We haven't patched it in a while because there has been no demand, but it should still work.

[thompson-tomo]

Nope I have not considered using 2.5 and I notice that it also target's net standard. Is that version signed?

At the same time having the packages signed would reduce the build warnings I am getting due to adopting more & more steeltoe libraries (config server, eureka, management endpoints etc)

[TimHess]

Unfortunately, the 2.5 line is also not signed, but it would at least make more sense to me for us to sign those packages.

Additionally, you could eliminate the Eureka proxy it sounds like you're attempting to build. I would much rather resurrect the 2.x line of Steeltoe for supporting .NET Framework apps than require anybody to try to proxy Eureka.

If you're interested in that idea, it would help to know if you're using any DI packages for the .NET Framework apps

[thompson-tomo]

Hey @TimHess at this point in time the net framework api is very minimal hence I don't want to spend to much time on it and it is not up the top of my list. I would still like the packages to be signed as a way to silence all the compiler warnings I am getting but it would also be ok to have this as a v4 feature if you guys are not interested in a partially signed release.

[bart-vmware]

We don't intend to strong-name-and-sign packages in Steeltoe v4, based on this.

Aside from the recommendations against it, signing is viral. A signed package requires that all of its dependencies are signed as well. Even if that wouldn't be an issue today, we don't want to paint ourselves in a corner where we can't take a dependency on future packages that aren't signed.

If there's no interest in consuming signed Steeltoe v2.x packages, I suspect this issue can be closed.