Some Roslyn-based analyzers for .NET are general in nature. They tend to focus on coding style, language use, or platform APIs. Others may be specific to a NuGet package. A package-specific analyzer provides messages and fixes tailored to use of that package. This is a great way for package authors to help improve your code or avoid even nasty bugs in production. Many popular open source packages are now shipping with a complementary analyzer. Today, I’m going to take a look at how we can package these package-specific analyzers.
I’ve seen three methods in use:
I’m presenting a workshop tomorrow here at MicroCPH. Windows has a way of knowing the best times to apply major updates. Sure enough, Windows 10 version 1803 (April 2018 Update) appeared on my laptop yesterday. All seemed fine until I tried to do some work with git.
I use SSH rather than HTTPS to talk to git remotes. The SSH agent was up and running, with my SSH key added to it. Business as usual. The problems started when I ran
git remote update. I was prompted for the password for my SSH key. Then I tried
git push. Again I was prompted for my password. Git and the SSH agent were no longer friends.
This is a message I try and convey as often as possible to people starting out in open source contribution. To show how easy it is, I sometimes send a tiny pull request live on stage. I don’t even have to leave the GitHub web UI.
And this is not something I do only for show. If you were to follow my activity on GitHub you’d see that I do this for real. If I’m browsing some source code and I see a typo, why not fix it there and then? Project maintainers (myself included) appreciate these little fixes and polishes. Every little bit helps.