We live in a technology-driven world where constantly changing market conditions and evolving customer expectations are the order of the day. For this reason, we’re seeing enterprises’ developer workforce, and Microsoft build tools, take on a more pivotal role to enable company-wide success in today’s competitive and fast-paced economy.
In other words, developers are under increasing pressure to deliver more solutions faster to enable businesses Fortunately, developers can better handle this pressure using Microsoft build tools.
Microsoft build tools (also known as MSBuild) is an open-source build engine platform for building .NET applications. It uses an XML control schema, making its build files easy to edit, and you can easily document build items and rules for different configurations. Initially, MSBuild wasn’t as efficient; it didn’t run cross-platform, it was verbose, and basically hard to edit. Consequently, Microsoft came up with Project.json, which was seemingly more efficient at the time, to replace MSBuild. However, this was not the case.
- Why did Project.json not work?
- What happens when we need to do more than just compile?
- How can we share values across all our projects?
- Can we use Microsoft build tools outside of Visual Studio?
- How can we build projects using MSBuild in Delphi?
- Ready to customize and automate your build process?
Why did Project.json not work?
In reality, you can have multiple projects. Migrating or making them work together with Project.json is not that easy. Plus, all project types need to be able to reference .NET standard projects. But references between something that was Project.json and MSBuild, in either direction, just couldn’t work. Then there’s “.xproj,” which is practically admitting that Project.json won’t cut it. Visual Studio and other IDEs and editors are built around MSBuild, and “.xproj” acts as a glue for the Project.json and MSBuild world.
However, Microsoft build tools have unlimited extensibility and power. In other words, you can pretty much build anything you want with this solution. But Project.json does not support this. For example, if you want to extend your build pipeline, you don’t have a good end-to-end way of doing that with Project.json. So, due to all these incapabilities, plus other .NET CLI issues, Microsoft decided, in 2015, to revert to MSBuild, but this time, with a much more improved version.
Since then, we’ve had major MSBuild upgrades with exciting features that allow developers to improve their workflow by leveraging MSBuild to customize and automate build processes. Here are a few more reasons why we love Microsoft build tools.
What happens when we need to do more than just compile?
MSBuild is the build system that powers the Visual Studio world. A more practical statement would be; when you “click compile” for your c# project, you’re basically calling MSBuild.exe and passing in your .csproj file to return your compiled code. If your major build needs end at “compiling,” you probably don’t need MSBuilld.
However, there’s much more to building a product than clicking the “F5” button to compile. The most common needs are automating and customizing build processes. Other tasks can include:
- Creating installs
- Updating version numbers
- Building escrows
- Linking to an external library
- Distributing final packages
Microsoft build tools, a unified and extensible build engine platform, makes all this easy to implement. While you can write scripts to perform most of these tasks, using MSBuild gives you a solid framework for executing your overall process. Plus, community support for this build system is easily accessible on the web.
How can we share values across all our projects?
MSBuild offers numerous features that aid customization, one of which is “automatic file discovery.” Initially, you’d have to edit each project and probably create some logic to add properties or targets across your projects. However, it is a lot easier with MSBuild. Here, you can share values across your projects by defining a single file in the root folder containing your source. For properties, this file is called Directory.Build.props, while it is Directory.Build.target for targets.
When MSBuild runs, Microsoft.Common.props/target seeks out the corresponding file (Directory.Build.props or Directory.Build.target) from your directory structure, imports the file, and reads its properties. You can find more information on how this works in the MSBuild docs.
Can we use Microsoft build tools outside of Visual Studio?
Although MSBuild is included in the .NET framework, it is also included in Visual Studio. You don’t need the full installation of the Visual Studio suite to use MSBuild. In other words, you can write your code outside of VS IDE (i.e., the command line and other MSBuild-supported IDE) and still have access to the consistent build process MSBuild provides.
One powerful MSBuild-supported IDE is Delphi. This IDE has its internal build system, but also supports MSBuild. Delphi makes it easy to build projects, as you can use its existing build, compile, and make commands to call MSBuild.
Additionally, you can quickly migrate existing projects to MSBuild by simply opening your existing projects. Delphi converts them to MSBuild and changes their extensions accordingly. For example, from .bdsproj to .dproj for a Delphi project. All in all, building projects with Delphi is simpler and faster.
How can we build projects using MSBuild in Delphi?
Many developers are missing out on the numerous MSBuild perks because of its steep learning curve. With Delphi, however, you don’t need in-depth MSBuild knowledge to build projects; the IDE handles all the details.
Here, you can build in one of two ways:
- Invoking MSBuild in a custom command environment
- Explicitly using the command line by running MSBuild.exe with your .dproj file
To execute the former, choose Start | Programs | Embarcadero RAD Studio Sydney | RAD Studio Command Prompt. This command window automatically sets both the path to the executable and the variable for your installation directory. The latter requires you to set the following environment variables yourself.
BDS=C:\Program Files (x86)\Embarcadero\Studio\21.0
FrameworkDir=C:\Windows\Microsoft.NET\Framework\v4.0.30319
FrameworkVersion=v4.5
You can get more details on the Delphi MSBuild doc.
Ready to customize and automate your build process?
With evolving customer expectations putting IT under increasing pressure to build and deploy solutions faster, developers need new ways and techniques to improve efficiency and productivity. Having a well-automated build and test process can significantly increase developer productivity. This is where Microsoft Build tools are crucial.
With exciting features that simplify customization and automation, MSBuild provides a consistent and effective build process that eliminates a lot of waste in your development process. Start your free trial today!
Additionally, Delphi IDE provides an easier and faster way to leverage this powerful build engine platform. With automatic project migration and little to no MSBuild knowledge required, you can quickly start building projects. Check out the full documentation on how you can easily build projects using an MSBuild command.