In my previous post, I explored how to create a minimalistic ReSharper plugin. After I published it, one of my colleagues inquired if it is possible to use this or any other plugin from ReSharper Gallery with inspectcode.exe from ReSharper Command Line Tools (RCLT). I didn’t know and decided to try it out. Here is what I learned.
Prerequisites: VS2017 and ReSharper 2018.1.0
When I started to work on a compiled ReSharper extension aka plugin, I quickly realized how hard it is to set up an initial infrastructure. Reasons:
- Official DevGuide is great, but it is often a step behind.
- Existing plugins on GitHub contain too much stuff in them, and it is hard to extract relevant pieces, especially when you are new to it.
- Lack of my own experience in building NuGet packages.
This post does not pretend to be an ultimate guide. On the contrary, it contains 20% of the knowledge you need to get started, and the remained 80% are links to useful information.
When the plugin is installed into a Visual Studio, it checks if a class name contains ‘Foo’ and displays a warning:
Prerequisites: Basic knowledge of C# and Entity Framework is desired.
When I was working on Test Analytics Solution, I did not expect to use any stored procedures for the project. However, as the database grew, the ORM framework became inefficient for some of the use-cases, relying on joining and aggregating data from many tables. No matter what I tried, SQL profiler showed extremely slow, dynamic SQL statements, bloated as Trump’s ego. The performance was a victim of generalization.
From the other side, a stored procedure (SP) completed the job perfectly. It took fractions of seconds instead of minutes. Obviously, I had to go forward using the stored procedure. It meant leaving a critical part of the business logic in a SQL world, poorly testable and exposed to regressions. It was one of those moments, as I explored in my previous post, that I struggled to apply TDD practices.