DotNet.Glob should be strong named

[dazinator]

DotNet.Glob should be strong named

[dazinator]

Agreed!

[Denis535]

I'm getting error:
System.IO.FileLoadException: 'Could not load file or assembly 'DotNet.Glob, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required.
How I can use your package now? Or when will you fix it?
Also why Version=1.0.0.0? I installed 1.6.9.

[dazinator]

Re: the versioning, see #30.
Apologies for the delay.

Feel free to submit a PR if this is causing you a delay.

[dazinator]

@Deni35 - do you still require a signed version? There is lot's of debate about how to handle signing keys for open source projects, for example read the first couple of answers here: https://stackoverflow.com/questions/396143/net-opensource-projects-and-strong-named-assemblies

If this is something that's still in demand I'd consider it further.

[dazinator]

.. and by the way, as of the latest pre-release, the version stamping of the assembly should be fixed.

[dazinator]

I am closing this for now. If you require a signed version of this package let me know. One way to achieve this is to fork the repo, and build it yourself with your own signing key.

[Denis535]

I've make my own simple Glob.
I do not understand what is difficulties you to sign your package?

[dazinator]

Ok cool.

The difficulty with signing is that this is an open source project that anyone can clone / fork and build and I dont want to add a private key file to the repo as that will render the value of the signature worthless from a security perspective. If anyone can produce the assembly with the same signature, then the signature doesn't really help you verify the publisher. I acknowledge it would have solved your immediate issue of requiring a signed assembly.

If you google this topic there is quite a bit of debate about it. Some people with open source projects just expose the private key anyway.

The long and short of it is that the simplest anwser for me right now is to not sign at all, because then I have no key to manage. However If I get more demand for this I will try to put something in future by setting up the private key on the build server, and keeping it secret by not adding it to the repo.

[Denis535]

If I will fork this repo and build myself then I will not receive new version.
And If I will need 100500 packages and to sign its myself then this will turn my life into hell.

I understand you but it's simple project which makes no sense to protect. It makes sense to sign to use together with signed packages.
I do not see anything terrible to publish your private key. As I said it's very simple project.

[dazinator]

As of version 2.0.3 which will appear on nuget shortly (if not already) - the assembly is now strongly signed. Thanks for raising the issue. I managed to use AppVeyor secure-file and secure variables in order to keep the private key secure.