gigya / microdot

Microdot: An open source .NET microservices framework

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Error CS8002: Referenced assembly 'Gigya.ServiceContract, Version=2.5.5.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

siegeon opened this issue · comments

Can you strongly type your assemblies?

Can you elaborate on your use case? Microdot is typically used all the way from the entry point of the service, and therefore isn't usually referenced by another signed assembly.

Sure thing. I have been working on a POC of our services contained within microdot. Based on your getting started project I created an Auth Service. Once I built the structure with mock endpoints everything was fine and dandy. However, as soon as I incorporated any of our (signed) internal assemblies (such as data access) I was no longer able to run the service due to the above-mentioned error. So to be clear Microdot is the container for existing service logic, that is dependent on core assemblies that are signed.

So your internal signed assemblies have no references to Microdot assemblies?

No, but I do have to tell my assemblies to expose internals to the grains and server project. Likely this is the issue.

From what I know signing is only required down-level, so if a signed assembly (like yours) was only compiled with references to other signed assemblies (such as the .NET Framework) then unsigned assemblies (like Microdot) can reference it without needing to be signed themselves. So I don't understand why you're getting that error.

Could you use an automatic signing tool for like this?
https://brutaldev.com/post/NET-Assembly-Strong-Name-Signer

Or perhaps use an unsigned version of your assemblies?

I will give it a go later today.

It's just that strong-named assemblies aren't very compatible with open-source, so we'd like to avoid them:

https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/

If you can simply unsign your own assemblies, it'll save you some trouble.

Adding this line of code to my database project cauases the problem.
[assembly: InternalsVisibleTo("SecurityService.Grains, PublicKey=" + SystemValues.PublicKey)]

I understand what your saying Allon, the nuget package does not appear to do the trick. Unfortunately, unsigning my assemblies is not an option. As I mentioned its a POC so I can find a way to work around this hiccup.

Have you managed to resolve the issue?

I marked it as closed as I can sign the assemblies myself rather than place the burden on this framework.