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 theNuGet.exe
from thepackages
folder in solution in an MSBuild task after build. Old .NET Framework way. Only thenuspec
file is used andcsproj
takes no part in it, except that version passed is read fromAssemblyVersion
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.