Add a strong name to nuget package

[zerg32]

Complied dll is missing a strong name so It is not possible to use it in strong named project.

Is it possible to add strong name during the build ?

[mganss]

The CsQuery NuGet package which HtmlSanitizer references is not signed, so unfortunately signing HtmlSanitizer doesn't seem to be possible currently.

[tiesont]

There's also: http://strongnamingconsideredharmful.com/

[304NotModified]

Nice link 👍

[304NotModified]

Is this possible in v3?

[mganss]

I think so, AngleSharp seems to be strong named, see AngleSharp/AngleSharp#115.

[304NotModified]

OK. I recommend to strong name it, and only use the main version in the strong name. So the assembly version is for releases 3.0 - 3.x: 3.0.0 . (iif we practice semver in the library)

[304NotModified]

Edit: I don't think semver is used? Can that be arranged in version 3?

[mganss]

I very much like the automatic ".*" assembly versioning provided by AssemblyVersionAttribute. Not using this would mean we'd have to have some build script that does all kinds of versioning things (patch the assembly file version, set the NuGet version etc.).

[304NotModified]

Well with * you get issues with strong naming, as described at http://strongnamingconsideredharmful.com/, and the version number is also not semver.

proposal:

• set fixed AssemblyVersionAttribute to 3.0.0.0 - from code or appveyor.yml
• before publish: change the assembly_file_version and assembly_informational_version (can be partly created by appveyor) - you can use variables. See https://github.com/NLog/NLog.Web/blob/master/appveyor.yml
• publish from appveyor after successful build

[mganss]

Done.

[Skybladev2]

@mganss I still do not see that NuGet package is signed, did you update it?

[mganss]

Only the beta is strong named (currently 3.1.67).

[304NotModified]

FYI strong looks good

[304NotModified]

@mganss why is the version updated to 3.1.x ? It that a test?

[mganss]

I had already published a NuGet package 3.0.5781.31354-beta before the move to SemVer.

[304NotModified]

Mmmm

I think 3.1.67 is also not semver? I think it should be 3.1.0.67 or just 3.1.0. It's required to start with patch 0. Source: http://semver.org

[mganss]

Where does it say that?

[304NotModified]

Patch version MUST be reset to 0 when minor version is incremented.

7 on semver.org

[304NotModified]

[mganss]

I can't see how that helps with the goals of SemVer. As long as the version number is strictly increasing there shouldn't be a problem with specifiying dependencies.

[304NotModified]

I can't see how that helps with the goals of SemVer. As long as the version number is strictly increasing there shouldn't be a problem with specifiying dependencies.

I don't really understand what you mean. The choose is relative easy, HtmlSanitizer uses SemVer, or it doesn't.

If HtmlSanitizer is using SemVer (from 3.0?), then 3.1.0.67 is not allowed as a version number after 3.0.x.

[mganss]

OK, then it's "almost SemVer" 😉

[304NotModified]

That doesn't exist IMO. It the same like saying that IE6 sticks to the HTML standards.

Why not unlisting the old packages and just create a 3.0 (-betaX) ?

[mganss]

I think the problem is not so much starting with SemVer at a specific version but rather resetting the third component to 0 (in the future). I don't see a way to achieve this and still use the automatic versioning provided by AppVeyor. It seems SemVer wasn't designed with CI in mind.

Also, there isn't a single browser w/o bugs 😄

[mganss]

3.1.76 is strong named.