Invoke-Build VS MSBuild

I use pwsh on all platforms. All automation is done with it, and in many cases web app functionality depends on it running in background all the time (for large public services).

Even our GitLab runner uses pwsh.

To organizse build/scripts we use Invoke-Build, a cross-platform task runner: https://github.com/nightroman/Invoke-Build

Invoke-Build

So I need to take a step back and Start-DscConfiguration won't be my entry point to deployment. I need a .ps1 script that installs modules. Or, bear with me, I'll be using a PowerShell build tool: Invoke-Build.

I discovered the Invoke-Build build system, PSScriptAnalyzer for linting, and Pester for testing/mocking. I wrote a GitLab CI/CD pipeline that takes advantage of all of this to push releases to our company's PSRepo. I also discovered the Plaster template system for scaffolding new projects, and created a custom company template for standardizing our repo structures.

MSBuild's ResolveAssemblyReference (RAR) task maps every assembly reference in your project to an actual .dll path on disk. The critical detail: RAR runs unconditionally on every build, including incremental builds. As dotnet/msbuild Issue #2015 explains, the build system cannot know whether you've installed a new targeting pack since the last build, so it re-resolves every time.

Then you are already using XMake, it's the original codename for MSBuild, still present in the code: https://github.com/dotnet/msbuild/blob/main/src/MSBuild/XMak... :)

The project code state at the time of the analysis matches this commit.

I did get confirmation that the actual kill has been postponed to .Net 9.0 rather than .Net 8.0 . However, that PR is factually wrong regarding when System.Runtime.Serialization use became opt-in -- I had to counter-adjust Rogue Survivor Revived to opt into using System.Runtime.Serialization for .Net 7.0, last November i.e. Nov 2022.

Like this https://github.com/dotnet/msbuild/blob/d0060335c1fb2f0523b1cf4656c464c5c4316783/src/Framework/NativeMethods.cs

Here is a taste of what to expect: https://github.com/dotnet/msbuild

The main thing they do is to list projects so that you can open a solution and see a set of projects, or build a solution and build everything there. They also give a lot of customization and fortunately it's rare that you need to know anything about that. It does feel somewhat unnecessary since you should be able to open a project with its dependencies. Hopefully solution files are going to be cleaned up: https://github.com/dotnet/msbuild/issues/1730

Since the previous check, the project has grown a lot. Our analyzer has become more advanced, too. This only makes this task more interesting! Despite the high quality of the MSBuild product and the well-known name of its creator, we again managed to find some issues in MSBuild's source code. The project is almost entirely written in C#. You can see it on GitHub. We took the code from this commit.