1.0.0 Versioning policy causing wrong versions to be picked up in VS

[AArnott]

Analyzers get loaded into the default AppDomain in Visual Studio. As such, a given assembly can only be loaded once per version. The StyleCop.Analyzers beta001 and beta009 (and everything in between) all are versioned as 1.0.0, which means VS can't possibly choose the right one to use unless exactly one such version is ever used for an entire instance of VS. I can't have a solution with projects that use different versions, and after loading a solution that uses beta001, I can't load a solution that uses beta009 without restarting VS.

Roslyn points this out in the error list:

AnalyzerDependencyConflict
Analyzer assemblies 'C:\Users\andarno.nuget\packages\StyleCop.Analyzers\1.0.0-beta009\analyzers\dotnet\cs\StyleCop.Analyzers.dll' and 'C:\Users\andarno.nuget\packages\StyleCop.Analyzers\1.0.0-beta001\analyzers\dotnet\cs\StyleCop.Analyzers.dll' both have identity 'StyleCop.Analyzers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=97d9e3aa481481c8' but different contents. Only one will be loaded and analyzers using these assemblies may not run correctly.

By the way, this warning, which appears once for each project in my solution, is visible as soon as I open the first project in an instance of VS. In the project.json world, where packages always come from a single nuget cache directory (as you can see in the paths mentioned above), there will virtually always be multiple versions of StyleCop.Analyzers in the package cache, whether or not you still use some of them. So to avoid this warning appearing for most/all StyleCop.Analyzers users going forward, we need to change something.

Can you please change the versioning strategy such that each release has a larger assembly version number, and can thus be loaded in VS alongside other versions?

[sharwell]

I need to put some thought into this. Technically, the reason this occurs is there have not been any releases to date, and the versioning strategy does not provide any SxS guarantees for prereleases. Stable releases are already configured to use a different assembly identity and would not result in this warning.

[AArnott]

Is it important that prereleases share an assembly version, or can we make sure they are unique as well?

What will the assembly version be for the first release? I guess if it's 1.0.0, it will conflict with all prereleases that people use.

[sharwell]

Is it important that prereleases share an assembly version, or can we make sure they are unique as well?

I don't have an answer for you yet on this one.

What will the assembly version be for the first release? I guess if it's 1.0.0, it will conflict with all prereleases that people use.

It's 1.0.0 but it uses a different strong name key. Not only is a conflict impossible, it's also impossible for someone to add an assembly binding redirect to cause a conflict between a prerelease and a stable release.

[sharwell]

I'll figure out something to do for this in Beta 11.

[sharwell]

Moving to Beta 12 due to high-priority issues demanding a Beta 11 release now.

[sharwell]

I'll start bumping up the assembly revision numbers during the tagged builds to avoid this issue. Right now no other libraries are depending on this one... I'm counting on that not changing.

[AArnott]

That sounds like a good policy. Thank you.