here<\/a>.<\/p>\n <Target Name=\"LowFrameworkVerUsedWarn\">\r\n <Warning Text=\r\n \"Project '$(AssemblyName)' needs it\u2019s framework upgraded. \r\n Version used now: '$(TargetFrameworkVersion)'.\"\/>\r\n <\/Target>\r\n<\/pre>\nThe next thing to do is to add the code to the build pipeline so the created target will be triggered during the build. To do that, override one of the *DependsOn<\/strong> properties. The *DependsOn<\/strong> properties consist of a list of tasks which must be finished before a certain target is called, e.g. CleanDependsOn<\/strong> is executed before each clean. All the steps that are available within a standard build process for .NET projects are defined in the Microsoft.Common.CurrentVersion.targets<\/strong> file which can be found in the MSBuild bin directory. The goal is to emit a warning if the compilation used an obsolete framework version. To do so, I\u2019ll search Microsoft.Common.CurrentVersion.targets<\/strong> for a task that runs after the compilation phase. The description of the PrepareForRun<\/strong> task, \u2018Copy the build outputs to the final directory if they have changed\u2019 indicates this is the place to hook into.<\/p>\n![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2017\/11\/word-image-35.png\")
<\/p>\n
To check the version property and call the warning, add a task to the PrepareForRunDependsOn<\/strong> property:<\/p>\n <PropertyGroup Condition=\"'$(LowFrameworkVerUsed)' == 'true'\">\r\n <PrepareForRunDependsOn>\r\n $(PrepareForRunDependsOn);\r\n LowFrameworkVerUsedWarn;\r\n <\/PrepareForRunDependsOn>\r\n <\/PropertyGroup>\r\n<\/pre>\nNotice that this <PropertyGroup><\/strong> checks the LowFrameworkVerUsed<\/strong> value in its condition. Therefore, I wrote $(PrepareForRunDependsOn)<\/strong> before adding the target.\u00a0Be careful to always list $(PrepareForRunDependsOn)<\/strong> before actually adding new targets as I have done above, or you’ll override the property effectively removing all previous values which will lead almost inevitably to a broken build.<\/p>\nWhen done, the LowFrameworkVerUsed.targets<\/strong> file looks like this.<\/p>\n<?xml version=\"1.0\" encoding=\"utf-8\"?>\r\n<Project xmlns=\"http:\/\/schemas.microsoft.com\/developer\/msbuild\/2003\">\r\n\r\n <PropertyGroup Condition=\"'$(TargetFrameworkIdentifier)' == '.NETFramework' and \r\n ('$(TargetFrameworkVersion)' == 'v2.0'\r\n or '$(TargetFrameworkVersion)' == 'v3.0' \r\n or '$(TargetFrameworkVersion)' == 'v3.5')\">\r\n <LowFrameworkVerUsed>true<\/LowFrameworkVerUsed> \r\n <\/PropertyGroup>\r\n\r\n <PropertyGroup Condition=\"'$(LowFrameworkVerUsed)' == 'true'\">\r\n <PrepareForRunDependsOn>\r\n $(PrepareForRunDependsOn);\r\n LowFrameworkVerUsedWarn;\r\n <\/PrepareForRunDependsOn>\r\n <\/PropertyGroup>\r\n\r\n <Target Name=\"LowFrameworkVerUsedWarn\">\r\n <Warning Text=\"Project '$(AssemblyName)' targets older .NET framework \r\n version '$(TargetFrameworkVersion)'.\"\/>\r\n <\/Target>\r\n<\/Project>\r\n<\/pre>\nThe very last step is to tell MSBuild to use the file during the build. There are two approaches to do so. One way is to add an import tag to the project\u2019s csproj file:<\/p>\n
<Import Project=\"C:\\Common-build\\LowFrameworkVerUsed.targets\" \/>.\r\n<\/pre>\nThis will work only for projects with the modification in the project file, so it\u2019s not really that useful. The second solution hooks up to every project automatically. Just copy the LowFrameworkVerUsed.targets<\/strong> file to the directory where MsBuild looks for them by default which is %localappdata%\\Microsoft\\MSBuild\\15.0\\Microsoft.Common.Targets\\ImportAfter\\<\/strong>.<\/p>\nIf such a folder doesn\u2019t exist, you can create it. Just remember to point to the proper version of MSBuild. It is the same as the Visual Studio version if running 2013 or higher, 15.0 in my case.<\/p>\n
Now I can be lazy updating my projects without worrying that any of them will slip by me, plus I have my own Visual Studio warnings, yay!<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2017\/11\/word-image-36.png\")
<\/p>\n
Creating a Build History<\/h2>\n
That example was relatively easy, so now I\u2019ll show you how to implement something a little bit more complex and use some C# while doing it. This time I want the last 10 build artefacts to be preserved in a predefined directory creating a local history of builds.<\/p>\n
To implement this custom MSBuild task, you could write a regular .NET library that will contain a class extending Microsoft.Build.Utilities.Task<\/strong> with all the logic in it. Afterwards, you\u2019ll just have to call it from the targets<\/strong> file:<\/p>\n <UsingTask\r\n AssemblyFile=\"C:\\MyLibrary.dll\"\r\n TaskName=\"Namespace.MyClassExtendingTask\" \/>\r\n\r\n <Target Name=\"CallMyTask\">\r\n <MyClassExtendingTask\/>\r\n <\/Target>\r\n<\/pre>\nThe main problem with this approach is that you must provide the assembly somehow to the build process. It shouldn\u2019t be a problem in smaller projects or for local-only solutions, but managing build specific assemblies can quickly become problematic, especially when you just want to add a small task that doesn\u2019t have too much code. Another way to achieve the same effect is to write .NET code directly within the MSBuild project file. I\u2019ll use this approach below just to have it as a self-contained example.<\/p>\n
First I\u2019ll start small with just a task that will compress and copy build outputs to chosen directory. To make it work, import a reference to Microsoft.Build.Tasks.v4.0.dll, define input parameters, and include code that will do the intended work. Here is how it should look:<\/p>\n
<UsingTask TaskName=\"ArchiveBuildTask\" TaskFactory=\"CodeTaskFactory\" AssemblyFile=\"$(MSBuildToolsPath)\\Microsoft.Build.Tasks.v4.0.dll\">\r\n <ParameterGroup>\r\n <PublishPath ParameterType=\"System.String\" Required=\"true\" \/>\r\n <ArtifactsPath ParameterType=\"System.String\" Required=\"true\" \/>\r\n <ArtifactsCount ParameterType=\"System.Int32\" Required=\"true\" \/>\r\n <\/ParameterGroup>\r\n <Task>\r\n <Reference Include=\"System.IO.Compression.FileSystem\"\/> \r\n <Using Namespace=\"System\"\/> \r\n <Using Namespace=\"System.IO\"\/> \r\n <Using Namespace=\"System.Linq\"\/>\r\n <Using Namespace=\"System.IO.Compression\"\/>\r\n <Code Type=\"Fragment\" Language=\"cs\"><![CDATA[\r\n int fileCount = 0;\r\n var sortedFiles = new DirectoryInfo(ArtifactsPath).GetFiles()\r\n .OrderByDescending(f => f.LastWriteTime).ToList();\r\n\r\n foreach (var fi in sortedFiles)\r\n {\r\n fileCount++;\r\n if (fileCount>ArtifactsCount-1)\r\n {\r\n fi.Delete();\r\n } \r\n }\r\n\t\tZipFile.CreateFromDirectory(Path.GetDirectoryName(PublishPath), \r\n ArtifactsPath + @\u201d\\\u201d + \u201dPublish\u201d + \r\n DateTime.Now.ToString(\u201cyyyyMMddHHmmss\u201d + \u201d.zip\u201d);\r\n ]]><\/Code>\r\n <\/Task>\r\n <\/UsingTask>\r\n<\/pre>\nNext, create a target, that will call ArchiveBuildTask<\/strong> and include it in the build process pipeline.<\/p>\n <Target Name=\"ArchiveBuild\" Condition=\"'$(ArchivePath)' != '' and $(ArchiveCount) > '0'\">\r\n <ArchiveBuildTask ArtifactsPath=\"$(ArchivePath)\" PublishPath=\"$(OutputPath)\"\r\n ArtifactsCount=\"$(ArchiveCount)\" \/>\r\n <\/Target>\r\n\r\n<PropertyGroup>\r\n <PrepareForRunDependsOn>\r\n $(PrepareForRunDependsOn);\r\n ArchiveBuild;\r\n <\/PrepareForRunDependsOn>\r\n<\/PropertyGroup>\r\n<\/pre>\nCondition ‘$(ArchivePath)’ != ” and $(ArchiveCount) > ‘0’<\/strong> states that the target won\u2019t run as long as parameters are not set. This way you can control when archiving will take place.<\/p>\nThe complete targets file then looks like this:<\/p>\n
<?xml version=\"1.0\" encoding=\"utf-8\"?>\r\n<Project xmlns=\"http:\/\/schemas.microsoft.com\/developer\/msbuild\/2003\"> \r\n\r\n<PropertyGroup>\r\n <PrepareForRunDependsOn>\r\n $(PrepareForRunDependsOn);\r\n ArchiveBuild;\r\n <\/PrepareForRunDependsOn>\r\n<\/PropertyGroup>\r\n\r\n <UsingTask TaskName=\"ArchiveBuildTask\" TaskFactory=\"CodeTaskFactory\" \r\n AssemblyFile=\"$(MSBuildToolsPath)\\Microsoft.Build.Tasks.v4.0.dll\">\r\n <ParameterGroup>\r\n <PublishPath ParameterType=\"System.String\" Required=\"true\" \/>\r\n <ArtifactsPath ParameterType=\"System.String\" Required=\"true\" \/>\r\n <ArtifactsCount ParameterType=\"System.Int32\" Required=\"true\" \/>\r\n <\/ParameterGroup>\r\n <Task>\r\n <Reference Include=\"System.IO.Compression.FileSystem\" \/>\r\n <Using Namespace=\"System\"\/> \r\n <Using Namespace=\"System.IO\"\/> \r\n <Using Namespace=\"System.Linq\"\/>\r\n <Using Namespace=\"System.IO.Compression\"\/>\r\n <Code Type=\"Fragment\" Language=\"cs\"><![CDATA[\r\n int fileCount = 0;\r\n var sortedFiles = new DirectoryInfo(ArtifactsPath).GetFiles()\r\n .OrderByDescending(f => f.LastWriteTime).ToList();\r\n\r\n foreach (var fi in sortedFiles)\r\n {\r\n fileCount++;\r\n if (fileCount>ArtifactsCount-1)\r\n {\r\n fi.Delete();\r\n } \r\n }\r\n ZipFile.CreateFromDirectory(Path.GetDirectoryName(PublishPath),\r\n @ArtifactsPath + @\"\\\" + \"Publish\" + DateTime.Now.ToString(\"yyyyMMddHHmmss\") + \".zip\");\r\n ]]><\/Code>\r\n <\/Task>\r\n <\/UsingTask>\r\n \r\n <Target Name=\"ArchiveBuild\" Condition=\"'$(ArchivePath)' != '' and $(ArchiveCount) > '0'\">\r\n <ArchiveBuildTask ArtifactsPath=\"$(ArchivePath)\" PublishPath=\"$(OutputPath)\" \r\n ArtifactsCount=\"$(ArchiveCount)\" \/>\r\n <\/Target>\r\n <\/Project>\r\n<\/pre>\nI have saved it as ArchiveBuild.targets<\/strong> inside the<\/p>\n%localappdata%\\Microsoft\\MSBuild\\15.0\\Microsoft.Common.Targets\\ImportAfter\\<\/strong> folder. That way MSBuild will be able to find it automatically no matter which project I\u2019ll build.<\/p>\nNow just set the ArchivePath<\/strong> and ArchiveCount<\/strong> properties in the project csproj<\/strong> or csproj.user<\/strong> file to make it work.<\/p>\n <PropertyGroup>\r\n <ArchivePath>C:\/PrivateBuilds\/RevDeBug<\/ArchivePath>\r\n <ArchiveCount>10<\/ArchiveCount>\r\n <\/PropertyGroup>\r\n<\/pre>\nEach build will then cause the results to be saved to C:\\PrivateBuilds\\RevDeBug<\/strong>, and I can use it in as many projects as I\u2019ll want to.<\/p>\nAs you can see the MSBuild pipeline is so versatile, the possibilities are countless. You can use it to enforce rules, automate all the mundane tasks, generate code, or pull some resources from external sources. In my organization we are using it for several solutions including to pull translation resources from databases which keep the latest versions, compile a user manual using files located on various network shares, and to create virtual machines with the new build installed. I also saw it being used to check whether the latest binaries are not significantly smaller than the last ones (which might indicate a problem with build file or dependencies) and automatically producing release notes suitable for the web page. I\u2019m quite sure you\u2019ll find a handful of tasks that can be automated with MSBuild right away.<\/p>\n
A good starting point is the Microsoft documentation<\/a> for MSBuild. You can also quickly find interesting build properties examining the diagnostic output of MSBuild in Visual Studio. To do so, open \u2018Tools > Options > Projects and Solutions > Build and Run\u2019 <\/em>And set \u2018MSBuild project build output verbosity\u2019<\/em> to Diagnostic<\/em>. Now, whenever you build a project, you will see all the MSBuild properties with their values in the build output.<\/p>\n![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2017\/11\/word-image-37.png\")
<\/p>\n
It\u2019s also worth mentioning, that MSBuild sees environmental variables, so you can write a target that will run only if a specified variable is set in your system.<\/p>\n
Summary<\/h2>\n
MSBuild can be extended far beyond the basic scenario in which you only clean, build, and deploy. You can use it to execute pre-defined tasks, console applications, or even new tasks written directly in .NET. You can easily tailor the build process to fit your needs.
\n If there are any actions you repeat more than once during build, there\u2019s a great chance you should automate it with MSBuild to save time and to make your build less error-prone. One less thing to remember during build is one less thing you must worry about. As Scott Hanselman once said \u201cThe most powerful tool we have as developers is automation\u201d.<\/p>\n","protected":false},"excerpt":{"rendered":"
The Microsoft Build Engine (MSBuild) works seamlessly within Visual Studio, but it can also be used to build software where Visual Studio is not installed. It\u2019s possible to create custom tasks that will run during the build process, saving time and decreasing the chances of error. Hubert Kuffel demonstrates how to create two useful tasks and how to easily is it to apply these to all your .NET projects.…<\/p>\n","protected":false},"author":316669,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143538],"tags":[],"coauthors":[50595],"class_list":["post-76004","post","type-post","status-publish","format-standard","hentry","category-dotnet-development"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/76004","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/316669"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=76004"}],"version-history":[{"count":15,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/76004\/revisions"}],"predecessor-version":[{"id":76034,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/76004\/revisions\/76034"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=76004"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=76004"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=76004"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=76004"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}