In our application we need to sign the drivers with our snk file. Downloaded the source code and updated and signed the projects but we got this error when I complie MongoDB.Driver project:
|Error|CS0122|‘IClock.UtcNow’ is inaccessible due to its protection level
Previously, we can sign v2.13.1 from the source code without any problems.
Do you have any ideas? Thanks!
Hi, @Helena_Reyes,
Welcome to the MongoDB Community Forums. I understand that you’re having trouble compiling and signing the MongoDB.Driver (and related) assemblies from source.
You mentioned the CS0122 compiler error related to the inaccessibility of the IClock interface. IClock is defined in the MongoDB.Driver.Core.Misc namespace and is marked internal. It is part of the MongoDB.Driver.Core assembly. That assembly is marked with [assembly: InternalsVisibleTo("MongoDB.Driver")] to allow the MongoDB.Driver assembly access to the internal members of the MongoDB.Driver.Core assembly.
When you strong name assemblies, the public key of the assembly becomes part of its strong name. Thus you will have to update src/MongoDB.Driver.Core/Properties/AssemblyInfo.cs to include the public key of your SNK. You will have to do the same for the other AssemblyInfo.cs files for other projects in the solution. You should then be able to compile the solution to produce strong-named assemblies.
Sincerely,
James
Hi James! Thank you so much for your response.
Yes, I also updated the AssemblyInfo.cs with the public key. Previously, we can apply SNK to the code without any errors. We just simply define snk in project properties, update Assemblyinfo.cs then build the code.
This issue happens since v2.14.x onwards. Since then, we cannot strong name the assemblies from the source code.
Hi, @Helena_Reyes,
I am not aware of any changes in v2.14.x and later that would prevent you from manually strong naming the assemblies as you’ve been doing. If you are able to strong name v2.13.1 using your procedure, I don’t see a reason why v2.14.x or v2.15.x would pose a problem. Does the build output provide any more clues regarding why strong naming is failing other than the CS0122 compiler warning?
I want to note that we don’t currently ship nor support strong named versions of our assemblies due to dependency conflicts and binding redirect problems that our users have encountered. We do realize that there are certain environments that require strong named assemblies. Please vote and/or comment on CSHARP-1276 with your use case as that will be helpful in understanding users’ needs for strong naming.
Sincerely,
James