MS Build: What you need to know

17 maart 2021 om 10:00 by ParTech Media - Post a comment

In the modern world, applications and software are written using high-level programming languages such as C# and Java which are human-understandable and cannot be executed by computers directly.

To make the applications 'executable' by the computers, the code that is written in a high-level programming language has to be converted to a set of machine instructions. It then has to be bundled and deployed for the successful access of the application.

But in real-time, application programmers do not emphasize or concentrate on the compiling and bundling part. Instead, they concentrate more on the logic behind building the application. In that case, how is the conversion of high-level code to machine instruction and bundling taken care of?

For C# based applications, Microsoft provides a tool that takes care of these activities. It is known as MSBuild. Let us see what is MSBuild and how it is useful in this blog.

Table of Contents

  1. What is MSBuild?
  2. What project file contains?
  3. Sections in the project file
  4. Conclusion

What is MSBuild?

Straight from the house of .Net 2.0, Microsoft provides the Build Engine tool known as MSBuild. MSBuild is a build platform tool that helps in automating the process of creating a software product including compiling the source code, packaging, testing, and deploying the same.

MSBuild comes as a separate tool along with Visual Studio IDE setup. Also, it can be installed separately. Technically, it has no dependency on Visual Studio and can be run on machines that do not contain Visual Studio. All it needs are files of the formats csproj, vbproj, vcproj, vjsproj, proj, and .targets which can be passed as input to MSBuild to process the code. MSBuild can be used to build the .Net Framework-based applications and for .Net Core-based applications.

What does a project file contain?

In this section, let's take the csproj file as an example and see in detail what it contains and how it is being used in C# based projects.

Consider a three-tier architecture-based application, where the presentation, business, and database layer are three different projects included in the complete solution. When users create such solutions, MSBuild looks for the csproj file or the project file to build the project. In this way, individual projects will be built by MSBuild.

The project file is an XML-based file, which contains the following information.

Consider a business layer project which is present in the solution. Now, there are operations in the code work with JSON-based objects and files, spreadsheets, working with pdfs, and many more. Not all these functionalities come with the pre-defined .Net assemblies and references. Some of them have to be externally referred to and consumed inside the code. And during the time of build, the compiler has to make use of them and complete the build process.

In such cases, the information of the packages that are being referred to within the project is defined in the project file.

Consider another situation. There are internal references between the projects within the solution, for example, the presentation layer interacts with the business layer and the business layer interacts with the database layer. Now there is a need to have references between the solution which is also being tracked in the project file.

Along with these, it also includes the version of the .Net that needs to be used for the project, whether the project has to be compiled in 32-bit or 64-bit mode, and the list of class files that needs to be referred inside the project. All these data will be mentioned in the project file.

Sections in the project file

Let's see the different sections available in a project file.

Property Group

<PropertyGroup>

  <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>

  <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>

  <ProjectGuid>{BC644873-5471-4675-AD4C-E40D91DC7463}</ProjectGuid>

  <OutputType>WinExe</OutputType>

  <RootNamespace>WindowsFormsApp1</RootNamespace>

  <AssemblyName>WindowsFormsApp1</AssemblyName>

  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>

  <FileAlignment>512</FileAlignment>

  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>

  <Deterministic>true</Deterministic>

 </PropertyGroup>

The property group section contains the type of the configuration, the type of output that is to be generated when this configuration is used, the framework of .Net that will be used to build the project, file align details, etc. Also, there can be multiple propertygroup referred to inside a project file.

Item Group

<ItemGroup>

  <Compile Include="Form1.cs">

   <SubType>Form</SubType>

  </Compile>

  <Compile Include="Form1.Designer.cs">

   <DependentUpon>Form1.cs</DependentUpon>

  </Compile>

  <Compile Include="Program.cs" />

  <Compile Include="Properties\AssemblyInfo.cs" />

</ItemGroup>

Similar to property groups, item groups can also be multiple in a project file. The files in the project that are mentioned in the 'Compile Include' will be compiled by MSBuild and the packaged output will be generated. Similarly, the Item group also holds the assembly references that are being referred to inside the project.

<ItemGroup>

  <Reference Include="System.Data" />

  <Reference Include="System.Deployment" />

  <Reference Include="System.Drawing" />

  <Reference Include="System.Net.Http" />

  <Reference Include="System.Windows.Forms" />

  <Reference Include="System.Xml" />

 </ItemGroup>

Conditions

Conditions can be included as attributes to set values to a property on a runtime basis. Here, in the above example in the property group section configuration has an attribute called Condition which has a check to validate the configuration value in runtime.

Custom Tasks

Similar to the assembly, file references, details about the framework version to use, configuration, custom tasks can also be added to the project file. These fall under the bucket of custom tasks.

Property Functions

Instead of writing custom tasks for many common actions, MSBuild from version 4.0 provides certain common functions in-built. Say, for example, printing date-time, which can be achieved through

 $([System.DateTime]::Now). $([]) 

The above indicates that content that is written inside is a system in-built property and does not need to look for any custom tasks.

Conclusion

MSBuild makes the building and packaging of .Net-based applications smoother, easier and hassle-free. The MSBuild can be invoked separately from the command prompt as well as being invoked in a CI/CD pipeline present in a cloud server.

Nieuwste