Add a strong name to nuget package about htmlsanitizer HOT 25 CLOSED

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

from htmlsanitizer.

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

from htmlsanitizer.

Nice link 👍

from htmlsanitizer.

Is this possible in v3?

from htmlsanitizer.

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

from htmlsanitizer.

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)

from htmlsanitizer.

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

from htmlsanitizer.

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.).

from htmlsanitizer.

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

from htmlsanitizer.

Done.

from htmlsanitizer.

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

from htmlsanitizer.

Only the beta is strong named (currently 3.1.67).

from htmlsanitizer.

FYI strong looks good

from htmlsanitizer.

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

from htmlsanitizer.

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

from htmlsanitizer.

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

from htmlsanitizer.

Where does it say that?

from htmlsanitizer.

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

7 on semver.org

from htmlsanitizer.

from htmlsanitizer.

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.

from htmlsanitizer.

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.

from htmlsanitizer.

OK, then it's "almost SemVer" 😉

from htmlsanitizer.

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) ?

from htmlsanitizer.

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 😄

from htmlsanitizer.

3.1.76 is strong named.

from htmlsanitizer.