A while ago I’ve announced a release of the first beta package of NSubstitute.Analyzers. Now, 4 months later I am happy to say that the first stable version is available for download. As usual, analyzers comes with two flavors:
Both of them come together with 19 diagnostics, which will warn you against common misusages of NSubstitue API. Feel free to grab them from NuGet and try them in your project. In case of any issues don’t hestitate to report a bug via GitHub issue tracker.
I am glad to announce that yesterday, together with NSubstitute team we released first beta version of Roslyn analyzers for NSubstitute – NSubstitute.Analyzers. The analyzers come in two flavors: NSubstitute.Analyzers.CSharp and NSubstitute.Analyzers.VisualBasic. Feel free to grab them from NuGet and try them in your project.
As for today analyzers can detect two most common misusages of NSubstitute:
Feels free to suggest additional diagnostic you would like to have in the package.
When you work with a solution which contains multiple projects, you usually have some kind of convention which is applied to all of the projects. For instance, in my case, I always make sure that Stylecop.Analyzers package is installed and properly configured in every project. In this particular case, this boils down to adding these lines into the csproj file
|
1 2 3 4 5 6 7 8 9 |
<PropertyGroup> <TreatWarningsAsErrors>True</TreatWarningsAsErrors> </PropertyGroup> <ItemGroup> <AdditionalFiles Include="..\StyleCop.json" /> </ItemGroup> <ItemGroup> <PackageReference Include="StyleCop.Analyzers" Version="1.0.2" /> </ItemGroup> |
Unfortunately, you have to add these lines to every project in a solution in order to make the Stylecop.Analyzers work for given project. This might be fine if you create all of them up front, but in real life scenario sooner or later you will add a new project to the solution. In that case, you might forget about adding those magic lines, so you will end up with inconsistent coding style in your repository. An additional problem with this approach is a code duplication so in case you rename StyleCop.json file you will have to make sure you update it everywhere. A partial solution for that problem is a manual import of custom made .props file, however, this approach is not perfect as well. The import part is not automatic, that is why you still have to remember about adding import directive to all of your projects.
Fortunately starting form MSBuild 15 you can bypass the limitations mentioned above thanks to automatic imports of properties from Directory.Build.props file. All you have to do is to create a beforementioned file in the root folder of your solution and you are good to go. The properties defined in the Directory.Build.props file will be automatically propagated to all of the child projects. In my case, this file looks as follows
|
1 2 3 4 5 6 7 8 9 10 11 |
<Project> <PropertyGroup> <TreatWarningsAsErrors>True</TreatWarningsAsErrors> </PropertyGroup> <ItemGroup> <AdditionalFiles Include="..\StyleCop.json" /> </ItemGroup> <ItemGroup> <PackageReference Include="StyleCop.Analyzers" Version="1.0.2" /> </ItemGroup> </Project> |
The sample application which leverages this feature can be found here
A couple of days ago I was trying to use Redis as session storage for one of my ASP .NET websites. Even though it seemed to be a rather straightforward task (Scott Hanselman wrote about that a while ago), I ended up with some weird exception while running the app: ERR unknown command ‘EVAL’
This wasn’t for sure a connectivity issue, as I was able to connect to Redis server from Redis Client – redis-cli. For me it looked like my server is not able to “understand” EVAL command. I started digging around and it turned out that this command has been introduced in version 2.6.0
I’ve connected to the server using redis-cli and checked the version with
|
1 |
info |
command and basically that revealed the problem.
As you can see I’ve accidentally installed version 2.4.6 (I have no idea how I ended up with so old version). After upgrading to the newest one, my problem was gone and I was able to successfully store session in Redis.
Most of .NET developers are familiar with collection initializers syntax. Long story short, this language feature allows you to replace this ugly syntax
|
1 2 3 4 5 |
var numbers = new List<int>(); numbers.Add(1); numbers.Add(2); numbers.Add(3); numbers.Add(4); |
with much shorter and cleaner one
|
1 |
var numbers = new List<int> { 1, 2, 3, 4 }; |
The more interesting thing is the fact that you can leverage this syntax not only for build-in collections but also for your custom classes. In order to do that your class must implement IEnumerable interface and expose public Add method. Let’s assume that we have some real case scenario and we have class which looks like that
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
public class StatusMessages : IEnumerable<StatusMessage> { private List<StatusMessage> messages = new List<StatusMessage>(); public IEnumerator<StatusMessage> GetEnumerator() { return this.messages.GetEnumerator(); } IEnumerator IEnumerable.GetEnumerator() { return this.messages.GetEnumerator(); } } public class StatusMessage { public string Text { get; set; } = string.Empty; public string SourceSystem { get; set; } = string.Empty; public int StatusCode { get; set; } public StatusMessage() { } public StatusMessage(string text) { this.Text = text; } public override string ToString() { return $"Text: {this.Text} StatusCode: {this.StatusCode} SourceSystem: {this.SourceSystem}"; } } |
This is a simple wrapper over the List
|
1 2 3 4 5 6 7 8 9 |
public class StatusMessages : IEnumerable<StatusMessage> { // rest of the code omitted for brevity public void Add(StatusMessage message) { this.messages.Add(message); } // rest of the code omitted for brevity } |
we can create a new instance of that class just like we would do with List
|
1 2 3 4 5 |
var messagesAddInitializer = new StatusMessages { new StatusMessage("y"), new StatusMessage("x"), }; |
What is more, it is possible to have multiple overloads of Add method in our class, so for instance if we add
|
1 2 3 4 5 6 7 8 9 |
public class StatusMessages : IEnumerable<StatusMessage> { // rest of the code omitted for brevity public void Add(string text) { this.Add(new StatusMessage(text)); } // rest of the code omitted for brevity } |
we are able to use this syntax
|
1 2 3 4 5 |
var messagesAddStringInitializer = new StatusMessages { "y", "x" }; |
In addition it is even possible to use a mix of Add overloads
|
1 2 3 4 5 |
var messagesAddAndTextInitializers = new StatusMessages { new StatusMessage("y"), "x" }; |
Add method can also have multiple arguments
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
public class StatusMessages : IEnumerable<StatusMessage> { // rest of the code omitted for brevity public void Add(int statusCode, string text) { this.Add(new StatusMessage(text) { StatusCode = statusCode }); } public void Add(int statusCode, string text, string sourceSystem) { this.Add(new StatusMessage(text) { StatusCode = statusCode,SourceSystem = sourceSystem }); } // rest of the code omitted for brevity } |
in that case we are able to use this syntax
|
1 2 3 4 5 |
var messagesMultipleArgumentsInitializers = new StatusMessages { { 1, "x" }, {1,"x","source" } }; |
The last thing I would like to point out is that Add function doesn’t have to be an instance method, we can easily implement it as an extension method and still leverage the collection initializer syntax.
|
1 2 3 4 5 6 7 8 9 10 |
namespace AbusingCollectionInitializers { public static class StatusMessagesExtensions { public static void Add(this StatusMessages statusMessages, int statusCode) { statusMessages.Add(new StatusMessage() { StatusCode = statusCode }); } } } |
Now with proper namespace import we can write this code
|
1 2 3 |
using AbusingCollectionInitializers; // rest of the code omitted for brevity var messagesExtensionInitializers = new StatusMessages { 1,2,3 }; |
Source code for this post can be found here