Maintaining AssemblyInfo for multiple projects



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>1.1.0</Version>
    <FileVersion>1.1.0</FileVersion>
    <Product>Fenergo.Platform.Common</Product>
    <Company>Fenergo</Company>
    <Copyright>Copyright © Fenergo 2018</Copyright>
  </PropertyGroup>
</Project>‍‍‍‍‍‍‍‍‍

In addition, you can inherit another funcionalities such as analysers. For example, if you want to use the Stylecop.Analyzers for all your project, you can add a Directory.Build.props like this:

 <Project>
  <PropertyGroup>
    <TreatWarningsAsErrors>True</TreatWarningsAsErrors>
  </PropertyGroup>
  <ItemGroup>
    <AdditionalFiles Include="..\StyleCop.json" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="StyleCop.Analyzers" Version="1.0.2" />
  </ItemGroup>
</Project>
‍

If you don't have your Directory.Build.props in your root directory, you can import it in the projects which you need it.

<Project>
  <!-- Import parent Directory.build.props -->
  <Import Project="../Directory.Build.props" />

  <!-- Properties common to all test projects -->
  <!-- ... -->
</Project>

I hope you found this post helpful,

Happy coding!

Alberto.

Comments

Post a Comment

Popular posts from this blog

Making DDD and CQRS Microservices easy with dotnet templates

Image
  Introduction If you are working with Microservices, you might have noticed that you are repeating over and over the scaffolding for your new microservices. In order to make easier the creation of new microservices, you can build your own custom dotnet core template . Apart from saving time, building a custom template will help to promote good practices, a proper architecture, right dependencies, etc. With this purpose, I have built my custom template, so it can help us to create easily new microservices based on CQRS and DDD, without having to build the same scaffolding each time we have to create a new service. Microservice architecture In microservices architecture, each service can be different, according to the problem it has to solve. However, it is likely that you have a reference architecture that will provide some consistency and it will promote good practices. In our case, the main patterns that drive our microservice architecture are Domain Driven Design (DDD) and Comma...
Read more

Managing snapshots for Amazon ElasticSearch with Dotnet Core Lambdas

Image
Introduction It is awesome to have some useful services like ElasticSearch managed by AWS , so you don't have to care about patching, monitoring, etc.  When it comes to backup management for indexes, Amazon ElasticSearch includes automated snapshots. Automated snapshots are only for cluster recovery. You can use them to restore your domain in the event of red cluster status or other data loss. Amazon ES stores automated snapshots in a preconfigured Amazon S3 bucket at no additional charge. In particular, if you are using a higher version than 5.3, Amazon ElasticSearch takes hourly automated snapshots and retains up to 336 of them for 14 days. However, this policy might not be enough if you need to keep your snapshots for a longer 15 days, or you need to take a snapshot to create a new cluster in another region, subnet, etc. If you have different requirements to manage your snapshots, you will have to work with manual snapshots. For this part, AWS does not offer a good managed exper...
Read more

Improvement in the Test Explorer for Visual Studio v15.7

Image
The next Visual Studio update (v15.7) will include an improvement in the Visual Studio Test Explorer that will allow us to see the best organized tests. So far we are seeing them like this: And with the improvement we can see them organized in a hierarchical way, grouped by project, namespace, class and method. This will also facilitate the execution of a set of specific tests (for example if we only want to launch those of a specific class). This is how the explorer test will look in future versions: Although in Visual Studio the test categories already existed ( https://msdn.microsoft.com/en-us/library/dd286683.aspx ), it is good news that by default we are grouped together in a much more practical way. This information is based on the article https://blogs.msdn.microsoft.com/visualstudio/2018/03/21/visual-studio-2017-version-15-7-preview-2/ and since it is not a version in production, you might experience some changes. Happy coding!!
Read more