Strong Naming

[mattdutson]

The NLOptNet DLL is not strongly named/signed. This is a problem for any strongly named project which tries to reference NLOptNet.dll.

This can be changed in the project properties under "Signing -> Sign the assembly". Happy to submit a PR for this if it helps.

[BrannonKing]

It seems that signing the assembly is not the recommended approach these days. See https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md#1-microsoft-strong-names-their-assemblies-should-i . If we update the project to .netstandard2.x does that eliminate the need for you to have it signed? (It appears that we're due to upgrade the nlopt dlls included therein.)

[mattdutson]

This is the problem I'm having (from https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming):

One important aspect of strong naming is that it's viral: a strong named assembly can only reference other strong named assemblies. If your library isn't strong named, then you have excluded developers who are building an application or library that needs strong naming from using it.

So while strong naming may not be the most modern thing to do, doing so should only increase your compatibility (unless you're referencing other .NET assemblies, which I don't think you are). The project I'm working on is strong named (I don't have any control over this), and hence all its dependencies (e.g. NLoptNet) must also be strong named.

I'm not sure if updating the project will fix the problem, although I guess it's worth a shot.

[BrannonKing]

Done. Test it please.

[mattdutson]

Yep, it's working on my end. Thanks for the help!

[BrannonKing]

@mattdutson , is strong naming still a feature that you need? I'm thinking to drop it as it's more painful to support .net core.

[mattdutson]

You can go ahead and drop it. Needed it for a research project that we completed a while ago. Thanks for checking!