RavenDB 4 - Strong Name

[Fernando Ferreira Diniz de Moraes]

Hello,

Are there any plans to release Raven 4.0 components (both Server and Client) with a strong name in the future?

Thanks in advance.

[Oren Eini (Ayende Rahien)]

For the server, no, we won't be doing that.

For the client, we don't want to do that unless there is a really good reason to do that ourselves. 

Strong naming doesn't provide a lot of advantages to us.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Fernando Ferreira Diniz de Moraes]

I can see some good reasons not to strong-name assemblies, specially for those targeting .NET Standard.

However, my scenario is of an application targeting .NET 4.6.2 composed of multiple assemblies acting as plug-ins, all of them strong-named. Needless to say, not having a strong named version of RavenDB Client would prevent us from interacting with the Database Server in a proper, strongly typed manner in this context.

Also, due to the "virality" nature of strong-named assemblies, we ended up strong-naming test projects. In some of the tests, we currently make use of an in-memory embedded document store as a database replacement. I've learned from this other thread that initializing an instance of RavenServer would be the way to go in RavenDB 4.0, which also poses a problem in this world of strong-named test assemblies, since the Raven.Server.dll would not be strong-named.

Of course, it would be possible for us to isolate the Raven Server on its own process, but it would feel clunky and unnatural.

In this specific context, how does having a strong-named version of the assemblies sound to you?

On Wednesday, October 18, 2017 at 5:13:50 AM UTC-2, Oren Eini wrote:

For the server, no, we won't be doing that.

For the client, we don't want to do that unless there is a really good reason to do that ourselves. 

Strong naming doesn't provide a lot of advantages to us.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Wed, Oct 18, 2017 at 1:11 AM, Fernando Ferreira Diniz de Moraes <fernando.ferreira.diniz.mor...@gmail.com> wrote:

Hello,

Are there any plans to release Raven 4.0 components (both Server and Client) with a strong name in the future?

Thanks in advance.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

[Oren Eini (Ayende Rahien)]

For testing, you won't need the Raven.Server.dll strongly named, it isn't referenced directly.

http://issues.hibernatingrhinos.com/issue/RavenDB-9041

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.

[Justin A]

*cry* :(

Let them compile there own. Lets stop propagating this mess :(

ref to the uber debate/battle : https://github.com/octokit/octokit.net/issues/405

-me-

[Oren Eini (Ayende Rahien)]

I have to agree, it has been giving us a lot of trouble over the year.

Given that we make the snk public anyway, that give zero additional security.

If there is a good way to have users self sign it, that would be preferable.

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--

[Oren Eini (Ayende Rahien)]

FWIW, we do code signing using PKI that ensure that the packages that you get are actually properly signed.

This is a higher level of security than strong naming, and it is required by some clients for security purposes to ensure that they don't get anything but the official build that is cryptographically signed.

I'm betting that most people won't even care, and that the difference is that they don't see an error in VS.