Strongly-named assemblies

[cerebrate]

First, let me say thanks for the great package: it works much better in our app than our previous (non-learning) solution.

We've got one issue to report: in our next release, all the various subsystems need to be in signed assemblies, which means we can't at the moment use SharpLearning since it would need to be called by a signed assembly and is itself unsigned. Any chance we could see signed versions of the SharpLearning Nuget packages?

Thanks,

Alistair

[mdabros]

Hi @cerebrate,

I'm glad you like the package. I am not that familier with the pros and cons of signed vs. unsigned assemblies. So I will have to investigate a bit to see what the downside of adding this would be.

With my current knowledge, I guess the primary downside would be restricting the libraries that SharpLearning can depend on, which is something I would prefer to avoid. However, I will investigate a bit an get back.

Alternatively, you can always fork SharpLearning and create a private signed build. This is of course more cumbersome than using the packages directly.

best regards
Mads

[cerebrate]

To the best of my knowledge, that's pretty much the only constraint signing imposes, since strong-named assemblies can't reference non-signed assemblies. At least Math.NET Numerics already ships signed, which is something, otherwise I'd just be shipping my current issue one step further upstream.

[mdabros]

Hi @cerebrate,

Sorry about the slow response.

After researching a bit more about signed vs. unsigned, it seems that signed assemblies is a bit of a legacy thing from the early days of .net. This, together with restricting which libraries SharpLearning can depend on, makes me conclude that that it would be a wrong direction for the library. So sadly, signed versions is not something SharpLearning will officially support.

best regards
Mads

[cerebrate]

Thanks; we'll find a workaround. I appreciate you taking the time to consider it.

Regards,

Alistair