Alberto Corrales Garcia

Introduction In the era of Microservices, you are probably designing or consuming one or more Web Services. As a result, you might be aware of the importance of having a good definition of your web services, since that is what clients and developers will use to know how a web service can be used. For that reason, you should have a clear and easy way to define and understand your Web API. In order to help you to make a good definition we have REST (Representational state transfer) , which is a software architectural style that defines a set of rules to create Web Services. I'm not going to go into details about RESTful, because there is enough material for a full post and it is out of the scope of this post. But I might write another post about REST, since even nowadays I see some crazy stuff when it comes to Web APIs design. Well, imagine we already have a really awesome definition for the resources of our Web API, and your clients are going to be really excited to use it,

Introduction  With the introduction of Visual Studio 2017, the format used for csproj was updated including several advantages. This new format will be used when you create a new .Net Core project or .Net Standard library. In spite of the fact that VS2017 continues supporting old csproj format, you can migrate your old projects to SDK format. As a result, you will have the following benefits: Cleaner csproj files. With new format, a lot of things can be omitted, so your csproj files will be cleaner. Files are included using a wildcard , instead of including every single file.  Solution project references are simplier . NuGet reference packages as PackageReferences , so you won't need packages.config and you will be able to use wildcard in your references (for example, 1.0.*). NuGet package definition as a part of the project file. You won't need more nuspec files. Definition of AssemblyInfo attributes in csproj , you won't need more AssemblyInfo.cs files. In ad

When you are developing an application or manly a NuGet package, you might want to keep the same AssemblyInfo for all your packages, which involves updating each project when you want to publish a new version of your package according to the SemVer convention Semantic Versioning 2.0.0 | Semantic Versioning . In order to make it easier, with the improvements of dotnet core and the new csproj syntax, which I strongly recommend, MSBuild 15 introduced a pretty cool feature: Solution-wide project properties with Directory.Build.props Customize your build - Visual Studio | Microsoft Docs . Basically, this allows you to define certain properties and use them in all your project in a centralised way, so you don't have to update your projects one by one. All you have to do is create a new text file named Directory.Build.props and place it where you have your solution file. Here is an example of the properties you can use: ‍<Project>   <PropertyGroup>     <Version