Migrating to SDK csproj

The SDK csproj files introduced with Visual Studio 2017 are a much needed improvement to the project files.    If you are creating a new .NET Core project or a .NET Standard library, either with VIsual Studio 2017 or the .NET CLI via dotnet new, it will generate the new SDK csproj.  What isn’t very clear to many is that you can use the new SDK format with full .NET Framework apps.  So this post will point out a really simple way for migrating to SDK csproj.

SDK Benefits

First, if you are unfamiliar with the new SDK csproj, here are a few of the benefits.

  • Include files using a wildcard as opposed to specifying every single file.
  • Simpler referencing of solution project references.
  • Reference NuGet package as references.  No more packages.config.
  • Define Some AssemblyInfo attributes.
  • NuGet package definition as part of the project file.  No more nuspec.

Old Style

Here’s the older style csproj from a .NET Framework 4.7.1 class library that references another class library.  There is a NuGet Package to Newtonsoft.Json

Migrating to SDK csproj

If you want to do manual conversions, take a look at this post by Nate McMaster.  However, ain’t nobody got time for manual conversions.  Luckily there is a tool that does a lot of the heavy lifting for your.  The CsprojToVs2017 project on Gith=Hub has been working wonders for me.  It either has worked in generating a full conversion or got me most of the way there.

Simply run the exe specifying the csproj file to convert:

.\Project2015To2017.exe YourClassLibrary.csproj

Here is the converted csproj file.  You can see

AssemblyInfo

There are a couple of errors after the conversion.

Since the csproj now contains some assembly info that is also in our existing AssemblyInfo.cs.  Specifically these two:

[assembly: System.Reflection.AssemblyCompanyAttribute("ClassicClassLibrary")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]

We can either remove the appropriate lines from our csproj or from our AssemblyInfo.cs  The choice is yours.

PackageReference and Reference

The conversion looked at our packages.config and created the appropriate <PackageReference ../>.  However, it also created <Reference ../>, which we no longer need.  So we can delete any of those that are actually NuGet Packages.

More

There are a ton of situations such as content files that it was handle appropriately.  If you have many project files that you would like to convert, I suggest giving this tool a shot.  Even if it gets you 80% of the way there and requires a bit of cleanup, I find it well worth it.

Are you converting?

If so, are you doing rewriting the project files manually or using this or a different tool?  I’d love to hear your comments or in Twitter.

 

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Microsoft Orleans Tutorial: Grains and Silos

Grains and SilosThis is the first post in the series were I’m actually getting into some code.  You will be able to follow along the journey of creating a practical web application using Microsoft Orleans.  This first post is really just setting the ground level to get familiar with the basics of Grains and Silos.  By the end of this post I’ll have a simple demo app that is a functioning ASP.NET Core as our client/frontend with a Orleans Silo hosting our Grains.

Blog Post Series:

Grains and Silos

For this blog post and throughout this series I’m going to be creating a web application with ASP.NET Core.   Our ASP.NET Core application will be our frontend and Orleans sits as a stateful middle tier in front of our data storage.

Now to break down the two pieces we need to get started with Orleans are Grains and Silos.  First let’s take a look at what Grains are.

Grains

Grains are the key primitives of the Orleans programming model. Grains are the building blocks of an Orleans application, they are atomic units of isolation, distribution, and persistence. Grains are objects that represent application entities. Just like in the classic Object Oriented Programming, a grain encapsulates state of an entity and encodes its behavior in the code logic. Grains can hold references to each other and interact by invoking each other’s methods exposed via interfaces.

One other interesting note about grains is that they are automatically managed by Orleans.  You don’t have to worry about instantiating or managing them.   Orleans terms them virtual actors as apposed to traditional actors.

Silos

Where do Grains live? Silos of course.

Silos are what host and execute Grains.  Again, Grains are your objects that expose behavior and encapsulate state.  Orleans creates your grains in the Silo and executes them here.  Your client code will reference only interfaces that your grains implement.  Don’t worry, sample code coming up.

Oh and of course, you can also have a cluster of silos.

Code

Now that we know the basics, let’s create a really simple demo just to get our feet wet and get a fully functioning app running.

Note: Remember to BUILD once you create any project as there is some codegen that occurs.  Do this before you start freaking out about types missing.

Grains Project

First we are going to create a project called Grains for our grains.  Here’s a netstandard2.0 project with references to a couple Orleans packages.  Note as of this blog post, I’m using 2.0.0-beta2 which supports .NET Standard 2.0.

Now we can create our first Grain.  I’m going to create a grain that simply increments a number within the grain.  Yes that simple.

Silo Project

Now that we have a grain, we need a Silo.  Create a .NET Core 2.0 console application called Silo.  Here’s the cs project with the relevant NuGet packages as well as Reference to our Grains project.

As you can see, we also have a OrleansConfiguration.xml that needs to be included in the output.  This is configuration file we will use for hosting our Silo.

Lastly, we need to start our Silo in our Program.cs

ASP.NET Core

Now let’s create a client that will interact with our Grains.  Create a new ASP.NET Core running .NET Core 2.0 application called Web

I’ve got a couple other dependencies referenced.  Botwin and Polly.

Polly is a fault handling library and Botwin is Middleware for ASP.NET Core that allows Nancy type routing.

The reason we want to use Polly is for our initial connection to the Silo.  Since we might running multiple projects from Visual Studio/Rider/Code/Whatever, this will help since the Silo might not be ready by the time our ASP.NET fires up.

Here is our Startup.cs that creates a singleton of our the Orleans IClusterClient.  It is thread-safe and intended to be used for the life of the application.

Now we can create a Botwin module to handle two different endpoints.  A GET request will return what our current count is, and a POST will increment our count by 1.

We simply inject our IClusterClient which is used to call GetGrain<T>.  Once we have our grain, we can call the relevant methods defined on the grain interface.

Done!

That is a fully functional, yet incredibly simple demo using Orleans on .NET Core and ASP.NET Core.  Stay tuned for more as we legitimately start building an app.

If you want to try the demo, all the source is available on my PracticalOrleans GitHub Repo.

Do you have any questions or comments? Are you using Orleans?  I’d love to hear about it in the comments or on Twitter.

Find MediatR Requests without Handlers

Find MediatR Requests with no HandlersYou’ve run into it.  MediatR throwing an InvalidOperationException when you didn’t have a matching handler for a request.   There’s a fairly simple solution to prevent this: Find MediatR Requests without Handlers.

So here’s some quick code you can throw in a unit test to verify you don’t have any missing handlers.

Find MediatR Requests without Handlers

The above code uses reflection to get all the IRequest<>, RequestHandler<> and RequestHandler<,>.  Also worth mentioning it leverages Autofac for the IsClosedTypeOf method in the linq query.

Usage

Here’s a quick unit test that shows it’s usage for finding Requests without any handlers.  In the sample below I have two Requests without Handlers: MyRequestWithoutHandler and MyRequestWithResultWithoutHandler

Source

All the source code for my example is available on GitHub if you want to try it yourself.

Another useful test would be to verify that your container actually has the the request and behavior handlers registered correctly.  Another post to come with that.

Always love hearing your comments.  Please post them here or on Twitter.