Roslyn Analyzers poor support – RecordGenerator fixed with v0.1.1

What happened

It seems I’ve made a huge mistake in v0.1.0 release – I didn’t test that the NuGet package actually worked. The only thing tested was the vsix extension (which I don’t currently publish) and tests in the repo. I didn’t bother to check during release, only after. And then it came out: the package is not recognized as an analyzer and simply doesn’t work. That was tracked by #15.

Long hours spent on the fix

So it seems that producing analyzer packages is really not that well supported, documentation is scarce and one has to travel a long way to make even a simplest change. So, what were the issues?

• Default scaffold for Analyzer + CodeFix project contains nuspec file and packs it using the NuGet.exe from the packages folder in solution in an MSBuild task after build. Old .NET Framework way. Only the nuspec file is used and csproj takes no part in it, except that version passed is read from AssemblyVersion by some magic MSBuild task.
• I aimed to make Continuous Integration/Delivery pipeline with MyGet for prerelease packages and NuGet for releases – together with AppVeyor CI building and deploying these packages. I didn’t want to specify the version built mutliple times and it seems that triggered most issues.

The story went like that: fist I wondered why is the analyzer DLL not put in the correct folder of nupkg. I tried many fixes in the nuspec, and as it was not working I thought maybe I should migrate to an SDK-style csproj. From what I knew, it supported creating NuGets automagically without nuspec. The work done is currently on some feature branch ’cause I want to do that sometime anyway. Currently it’s just unviable (on my way to an SDK-style I also tried to integrate GitVersion, which might have not helped) – there are some blockers on side of dotnet-sdk team. Then I’ve gone back and found the reason – when upgrading the NuGet (can’t remember why did I need to), I’ve changed the MSBuild packing task. Now it ran from the project folder and used the csproj as source, and the nuspec only for metadata – which did not include the key piece of the puzzle: the <files> node of nuspec which told NuGet to pack the analyzer DLL into the analyzers folder instead of standard lib. Reversing that simply by adding a Diagnostic.nuspec parameter into the call made all the difference.

Success

Now I’m a happy author of an actually working this time analyzer package which allows users to generate Records easily and simply don’t care for generated code afterwards, ’cause it will error when it needs update. And I’ve tested the package immediately before releasing, using MyGet feed, and immediately after release, using NuGet feed – so I can assure you, it works. This time, it really works.

Get it now: