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
nuspecfile and packs it using the
packagesfolder in solution in an MSBuild task after build. Old .NET Framework way. Only the
nuspecfile is used and
csprojtakes no part in it, except that version passed is read from
AssemblyVersionby 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.
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.