Msbuild что это за программа

MSBuild что это за программа и нужна ли она?

Поговорим о такой программе как MSBuild, для чего она и можно ли ее удалить. MSBuild является штатным инструментом сборки проекта и используется в редакторе Visual Studio (или SharpDevelop), это такая программа в которой разработчики создают другие программы — пишут код и компилируют потом. Но при этом возможно создавать программы и без этой студии, достаточно чтобы был сам Microsoft Build Engine (MSBuild). Также данный компонент помогает собирать конечные проекты с поддержкой платформы .NET, при этом как версии 2.0 так и более современной.

Если вы думаете как удалить MSBuild, то я этого не советую делать, а то могут возникнуть разные глюки через некоторое время. Могу дать совет — переименуйте папку например в …MSBuild_, поработайте пару дней за компом, если нет глюков можете удалить

Особого смысла писать подробно о том что за программа MSBuild нет, так как вряд ли вам будет интересно, это для программистов. Ну что интересно? Окей, тогда немного напишу. Вот смотрите, MSBuild запускается из командной строки таким образом — файл проекта передается модулю MSBuild.exe с определенными аргументами. В результате при помощи аргументов указываются свойства, задаются обьекты и средства для ведения журнала. Также этот модуль будет полезен для отображения в командной строке ошибок, предупреждений, сообщений.

Разработка приложения в проекте MSBuild при использовании среды разработки Visual Studio 2005:

Итак, какой можем сделать вывод о программе MSBuild?

• позволяет вести файл журнала с ошибками, предупреждениями и сообщениями при выполнении;
• обработка в пакетном режиме задач, обьектов, на основе метаданных;
• преобразование для дальнейшего анализа и эффективного построения проектов;
• интеграция с Visual Studio, где MSBuild отвечает за проект, поэтому можно использовать любой проект, который был собран с использованием MSBuild, даже если он был создан при помощи другого инструмента;

Модуль MSBuild может работать с файлами, расширения у которых соответствует шаблону .*proj.

Скорее всего папку вы нашли в \Program Files, но вот какая штука, в эту папку, пользуясь тем что это системный компонент, может также поселится и вирус. Но если вдруг подозреваете, что это вирус… то тут лучше сразу проверить компьютер онлайн сканером, если будут вирусы, то он их найдет и после проверки вы их сможете удалить.

Как видите, интересного мало, это системная программа и папку ее как бы не желательно удалять, тем более что если она просто простаивает — то она никому не мешает и не нагружает процессор вообще никак.

Так вот, по поводу вирусов, если думаете что они поселились на компе — то нет вопросов, проверьте сперва инструментом AdwCleaner, а потом пройдитесь сканером Eset, я о нем писал тут (во второй половине статьи!).

Основные понятия (Меню)

MSBuild устроен таким образом, что сборка проекта разбита на несколько этапов.

Target — это некоторый этап (событие), происходящее во время сборки проекта. Можно использовать стандартные таргеты, либо определять собственные.

Task — это некоторая задача, которая может выполняться на определенном этапе. Можно использовать стандартные таски или создавать собственные.

Жизненный цикл сборки MSBuild (Меню)

Для работы MSBuild Microsoft определил ряд стандартных таргетов (в файлах Microsoft.Common.targets, Microsoft.CSharp.targets и т.д.). Определено огромное множество различных таргетов, но в данной статье мы не будем на этом подробно останавливаться. Некоторые стандартные таргеты (упорядочены):

• BeforeRebuild
• Clean
• BeforeBuild
• BuildOnlySettings
• PrepareForBuild
• PreBuildEvent
• ResolveReferences
• PrepareResources
• ResolveKeySource
• Compile
• UnmanagedUnregistration
• GenerateSerializationAssemblies
• CreateSatelliteAssemblies
• GenerateManifests
• GetTargetPath
• PrepareForRun
• UnmanagedRegistration
• IncrementalClean
• PostBuildEvent
• AfterBuild
• AfterRebuild

Таргеты BeforeBuild и AfterBuild специально созданы для переопределения и их можно использовать. Остальные таргеты из списка не рекомендую использовать, чтобы ничего не сломалось.

Для более подробного просмотра списка таргетов можно использовать параметр /pp:. Благодаря этому параметру будет сформирован файл, в который будут включены все импорты (включая файлы .targets). В нем можно найти множество таргетов и переменных (спасибо aikixd за подсказку).

Подготовка окружения для примеров (Меню)

Для примеров необходимо:

• Установленная среда разработки Visual Studio
• Создать проект типа Console Application с именем MSBuildExample
• Открыть папку проекта и найти там файл MSBuildExample.csproj
• Открыть файл MSBuildExample.csproj в блокноте или другом редакторе

Внимание! В файле .csproj регистр букв важен.
Для запуска примера необходимо запускать build в среде разработки Visual Studio. Для некоторых примеров потребуется выбирать solution конфигурацию.

Результат будет выводиться в окно Output в Visual Studio (внизу). Если его нет, то откройте его через пункты меню View => Output.

Таргеты в MSBuild (Меню)

Для примеров будем использовать таск Message, который будет выводить информацию в окно Output в Visual Studio. Как говорилось ранее есть стандартные таргеты BeforeBuild и AfterBuild, воспользуемся ими. Про подготовку читать в разделе Подготовка окружения для примеров.

Результат выполнения (лишнее исключено):

Как видно, был выполнен task Message, который вывел указанный нами текст в момент BeforeBuild и AfterBuild в окно Output в Visual Studio.
При определении таргета с одним и тем же именем он перезаписывается!

Результат выполнения (лишнее исключено):

Создание собственного таргета MSBuild (Меню)

Если таргетов BeforeBuild и AfterBuild недостаточно или нужно, чтобы таски выполнялись на другом этапе жизненного цикла сборки, то можно определить собственный таргет. Для этих целей есть параметры BeforeTargets и AfterTargets.

Результат выполнения (лишнее исключено):

Было определено два собственных таргета — MyCustomBeforeTarget и MyCustomAfterTarget.
Таргет MyCustomBeforeTarget выполняется до таргета BeforeBuild, потому что мы указали:

Таргет MyCustomAfterTarget выполняется после таргета BeforeBuild, потому что мы указали:

Таски в MSBuild (Меню)

В данной статье не рассматривается как можно писать собственные таски, но прежде чем писать таск, ознакомьтесь со списком тасков, предоставляемых Microsoft.

Рассмотрим несколько примеров использования тасков и макросов.

Если будет выбрана solution конфигурация Debug, то результат будет выглядеть так (лишнее исключено):

Информацию о макросе $(Configuration) и других макросах можете найти в разделе переменные и макросы в .csproj.

В примере выше у нас есть текст, который можно унифицировать. Чтобы исключить дублирование вынесем в отдельную переменную текст сообщения.

Для определения собственной переменной используется элемент PropertyGroup.

В данном примере сделаем таск, который проверяет создан ли файл App.Debug.config. Если он не создан, то выдаем ошибку. В случае ошибки билд будет остановлен и ошибка будет отображена как ошибки компиляции в окне Error List.
Используем для этого таск Error и уже знакомый нам параметр Condition.

Результат:

В условии Exists используется относительный путь от папки, в которой находится файл .csproj. Для обращения к папке выше текущей использовать ‘../’. Если нужно обратиться к вложенной папке, то использовать формат ‘[DirectoryName]/App.Debug.config’.

В данном примере будем использовать таск Copy. С помощью таска скопируем файл App.config в папку bin/[Configuration]/Config в два файла App.config и App.test.config.

Свойство SourceFiles — массив файлов, которые необходимо скачать. Указывать без кавычек, через точку с запятой.

Свойство DestinationFiles — массив файлов куда будут копироваться файлы. Указывать без кавычек, через точку с запятой.

Подробнее о макросе $(OutputPath) читать в разделе переменные и макросы в .csproj.

MSBuild — .NET Core

In this fast-paced contemporary world, software and applications are written with the help of high-level programming languages including C# and Java which are human-understandable and cannot be executed by computers directly. The code that is composed in a high-level programming language has to be transformed into a set of machine instructions to make the applications ‘executable’ by the computers. Following this, it has to be bundled and deployed for successful access to the application. But in real-time, application programmers do not assert or concentrate on compiling and bundling. Instead, they emphasize more on the logic involved in building the application. How does the conversion of high-level code to machine instruction and bundling happen in that scenario? For C# based applications, Microsoft offers a tool that looks after these activities. We know it as MSBuild. Let us learn about MSBuild and how it is useful in this article.

What is MS Build?

An XML-based project system, MSBuild, or Microsoft Build Engine, processes and builds software. It’s created especially for the .NET Framework and Visual Studio but can process other kinds of software and frameworks. When .NET Core was developed, ASP.NET Core was one of the first application targets available. To make the platform more interesting to open-source web programmers, ASP.NET Core employed a JSON-based project system described in a project.json file. Looking at Node.js, everything is JSON-based as opposed to XML so this was a sensible design choice to engage new programmers.

Before .NET Core, .NET projects were all based on MSBuild or an MSBuild-like system. Generally, the programmer didn’t have to bother about this. Most projects began from the in-built Visual Studio templates and automatically, Visual Studio managed updates to project files (.vbproj, .csproj, etc.). Sometimes you had to deal with merge conflicts in the project file, as it comprised a list of every file in the project, which was described by its own XML node. If two programmers independently changed the list of files in a project, this could cause a merge conflict, but these concerns were typically simple to deal with.

After .NET Core came out, it immediately placed itself as the framework for all. NET-based application targets include Xamarin and Universal Windows Platform (UWP). Non-web programmers didn’t see the project.json file as an upgrade. They were used to working with MSBuild and wished to continue to use it. So Microsoft announced they are going to re-standardize MSBuild as the build system for .NET Core for the greater good of the existing .NET community.

Microsoft has incorporated new capabilities for MSBuild. In 2015, it went cross-platform I, and Microsoft announced improvements for the build engine. The first MSBuild-based SDK ‘alpha’ was released in November 2016. Visual Studio utilises MSBuild to load and develop managed projects. The project files in Visual Studio (.vbproj, .csproj, .vcxproj, and others) consist of MSBuild XML code that executes when you build a project by using the IDE. Visual Studio projects import all the necessary settings and build processes to do typical development work, but you can extend or change them from within Visual Studio or by using an XML editor.

Starting with Visual Studio 2022, when you develop in Visual Studio, the 64-bit version of MSBuild is utilised. Below mentioned examples explain when you might run builds by applying MSBuild from the command line rather than the Visual Studio IDE.

• Visual Studio isn’t installed. (Download MSBuild without Visual Studio.)
• You want to utilise the 64-bit version of MSBuild, and you’re using Visual Studio 2019 or earlier. Usually, this version of MSBuild is unnecessary, but it provides MSBuild to access more memory.
• You want to run a build in several processes. But, you can utilise the IDE to get the same result on projects in C++ and C#.
• You want to change the build system. For instance, enable the following actions:

1. You have to reprocess files before they reach the compiler.

2. Copy the build outputs to another place.

3. Make compressed files from build outputs.

4. Do a post-processing step. Like, stamp an assembly with a different version.

You can document code in the Visual Studio IDE but run builds with the help of MSBuild. Alternatively, you can create code in the IDE on a development computer but run MSBuild from the command line to build code that’s combined from several programmers. Also, you can use the .NET Core command-line interface (CLI), which utilizes MSBuild, to build .NET Core projects.

MSBuild Components

MSBuild provides a basic XML schema that you can use to control how the build platform builds software. To specify the components in the build and how they are to be built, use these four parts of MSBuild: properties, items, tasks, and targets.

MSBuild properties

Properties are name-value pairs that can configure builds. Properties are beneficial for evaluating conditions, passing values to tasks, and storing values that will be referenced throughout the project file.

Define and reference properties in a project file

Properties are declared by building an element that contains the name of the property as a child of a PropertyGroup element. For instance, the following XML builds a property named BuildDir containing a value of Build.

Throughout the project file, properties are referenced with the help of syntax $(<PropertyName>). For instance, the property in the last example is referenced by using $(BuildDir).

By redefining the property, the property values can be changed. The BuildDir property can be given a new value by using this XML:

Properties are assessed in the order in which they show up in the project file. The new value for BuildDir must be declared after the old value is assigned.

MSBuild items

The inputs into the build system are MSBuild items, and they typically portray files (the files are specified in the Includeattribute). Items are arranged into item types on the basis of their element names. Item types are named lists of items that can be utilised as parameters for tasks. The tasks make use of the item values to execute the steps of the build process. Because items are named by the item type to which they belong, the terms “item value” and “item” can be utilised interchangeably.

Create items in a project file

Items in the project file can be declared as child elements of an ItemGroup element. The name of the child element is the type of the item. The Include attribute of the element determines the items (files) to be incorporated with that item type. For instance, the following XML develops an item type that’s named Compile, which consists of two files.

The item file2.cs doesn’t replace the item file1.cs; rather, the filename is appended to the list of values for the Compileitem type.

The XML mentioned below creates the same item type by declaring both files in one Include attribute. Notice that a semicolon separates the file names.

The Include attribute is a path that is interpreted relative to the project file’s folder, $(MSBuildProjectPath), even though the item is in an imported file including a .targets file.

Create items during execution

Items that are outside Target elements are assigned values during the evaluation phase of a build. During the subsequent execution phase, items can be built or changed in the below-mentioned ways:

• Any task can emit an item. The Task element must have a child Output element that has an ItemName attribute, to emit an item.
• The CreateItem task can emit an item. This usage is deprecated.
• Starting in the .NET Framework 3.5, Target elements may comprise ItemGroup elements that may consist of item elements.

Reference items in a project file

To reference item types throughout the project file, you utilize the syntax @(<ItemType>). For instance, you would reference the item type in the last example by utilizing @(Compile). By making use of this syntax, you can pass items to tasks by mentioning the item type as a parameter of that task.

By default, semicolons separate the items of an item type (;) when it’s expanded. You can make use of the syntax @(<ItemType>, ‘<separator>‘) to indicate a separator other than the default.

Targets group tasks together in a certain order and let the build process be factored into smaller units. For instance, one target may delete all files in the output directory to arrange for the build, whereas another arranges the inputs for the project and puts them in the empty directory.

Declare targets in the project file

With the Target element, targets are declared in a project file. For instance, the XML mentioned below creates a target called Construct, which then calls the Csc task with the Compile item type.

Targets can be redefined, just like MSBuild properties. For example,

If AfterBuild executes, it describes only the “Second occurrence”, as the second definition of AfterBuild hides the first.

MSBuild is import-order dependent, and the last definition of a target is the definition used. If you seek to redefine a target, it won’t take effect if the built-in target is defined later. With projects that employ an SDK, the order of definition is not that clear, since the imports for the targets are implicitly incorporated at the end of your project file.

Hence, to extend the behavior of a current target, build a new target and mention BeforeTargets (or AfterTargetsas appropriate) as follows:

Add a descriptive name to your Target, as you would name a function in code.

Target build order

If the input to one target relies on the output of another target, Targets must be ordered.

There are different mentions to mention the order in which targets run.

• Initial targets
• Default targets
• First target
• Target dependencies
• BeforeTargets and AfterTargets

During a single build, a target never runs twice, even though the next target in the build relies on it. Its contribution to the build is complete, once a target runs, its contribution to the build is complete.

Target batching

A target element may have an Outputs attribute that mentions metadata in the form %(<Metadata>). If so, MSBuild runs the target once for every unique metadata value, grouping or “batching” the items that have that metadata value. For instance,

batches the Reference items by their RequiredTargetFramework metadata. The output of the target looks appears like:

MSBuild tasks

A build platform requires the capability to accomplish many actions during the build process. MSBuild utilises tasks to execute these actions. A task is a unit of executable code employed by MSBuild to execute atomic build operations.

Task logic

On its own, the MSBuild XML project file format cannot fully accomplish build operations, so one must implement task logic outside of the project file.

The execution logic of a task is implemented as a .NET class that incorporates the ITask interface, which is described in Microsoft.Build.Framework namespace.

The task class also describes the output and input parameters available to the task in the project file. All public settable non-static non-abstract properties shown by the task class can be given values in the project file by positioning a corresponding attribute having the same name on the Task element, and setting its value as depicted in the examples later in this article.

You can document your own task by authoring a managed class that incorporates the ITask interface.

Execute a task from a project file

Before accomplishing a task in your project file, you must first map the type in the assembly that incorporates the task to the task name with the help of the UsingTask element. This allows MSBuild to know where to look for the execution logic of your task when it finds it in your project file.

To accomplish a task in an MSBuild project file, develop an element with the name of the task as a child of a Target element. If a task accepts parameters, these are passed as attributes of the element.

MSBuild item lists and properties can be utilized as parameters. For instance, the below-mentioned code calls the MakeDir task and puts the value of the Directories property of the MakeDir object equal to the value of the BuildDir property:

Also, tasks can return information to the project file, which can be saved in properties or items for later use. For instance, the below-mentioned code calls the Copy task and stores the information from the CopiedFiles output property in the SuccessfullyCopiedFiles item list.

Compiler Options in MSBuild

When you have an MSBuild-based project which uses TypeScript including an ASP.NET Core project, you can configure TypeScript in two ways. Either with a tsconfig.json or with the project settings.

With a tsconfig.json

We suggest you use tsconfig.json for your project when possible. To incorporate one into an existing project, including a new item to your project, which is called a “TypeScript JSON Configuration File” in contemporary versions of Visual Studio.

The new tsconfig.json will then be utilized as the source of truth for TypeScript-specific build information, like files and configuration.

Using Project Settings

Also, you can determine the configuration for TypeScript within your project’s settings. This is achieved by editing the XML in your .csproj to define PropertyGroups which describes how the build can work:

There is a set of mappings for popular TypeScript settings. These are settings which map directly to TypeScript cli options and are utilised to assist you document a more understandable project file. You can utilise the TSConfig reference to get more information on what values and defaults are for each mapping.

What’s new in MSBuild 17.0

This article has all significant updates on MSBuild 17.0. MSBuild 17.0 shipped with Visual Studio 2022 and .NET 6.0.

Changed path

MSBuild is installed in the \Current folder under each version of Visual Studio, and the executables are in the \Binsubfolder. For instance, C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\MSBuild.exe is the path to MSBuild.exe installed with Visual Studio 2022 Community. You can also use the following PowerShell module to locate MSBuild: vssetup.powershell.

Changed properties

The following MSBuild properties have been updated because of the new version number.

• MSBuildToolsVersion for this version of the tools remains “Current”. The assembly version is 15.1.0.0, which is the same as in Visual Studio 2019 and Visual Studio 2017.
• VisualStudioVersion for this version of the tools is “17.0”

64-bit

Earlier, MSBuild.exe had both 32-bit and 64-bit versions, but currently, the default version is the 64-bit version. Visual Studio 2022 utilises the 64-bit version of MSBuild for all builds. The 32-bit version is still available, but it is advised to change all builds to the 64-bit version.

For task owners, this implies that when MSBuild loads your task, it will try to load it in a 64-bit process. We suggest you think of updating your tasks to run in a 64-bit process, but for compatibility, you can tell MSBuild that your task runs as 32-bit only in their UsingTask.

Performance enhancements

MSBuild is quicker! The aim of this release has been to enhance performance for many common scenarios. MSBuild 17.0 can build larger projects quickly.

.NET versions

MSBuild (and Visual Studio) now targets .NET 6.0 and .NET Framework 4.7.2. If you want to utilise new MSBuild API features, you have to upgrade the assembly, but the existing code will continue to function.

Logs

Binary logs are smaller and have extra information.

Breaking changes

• The method GetType() can no longer be called in property functions.
• MSBuild for .NET targets .NET 6.

Other behavior changes

By default, MSBuildCopyContentTransitively is now assuring consistency in output folders on incremental builds.

Change waves

A change wave is a collection of behavior modifications in MSBuild that you can opt out of by indicating a certain flag as an environment variable. The aim of this is to remind you of possibly disruptive modifications so that you have flexibility in adapting to these changes before they turn to be a standard functionality. All the features in a specific change wave can only be implemented or disabled together, not individually.

When a new version of MSBuild is upgraded, modifications that are probably breaking are enabled by default, but if a feature influences your build negatively, you can simply disable that wave of changes. Every change wave is determined by a MSBuild version number (for instance, 16.8), but setting the change wave just manages specific features that have the chance to affect the build process, not all the changes in that MSBuild version. A list of the features in every change wave shows up later in this article. Disabling a change wave also disables change waves of higher versions.

Conclusion

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

Msbuild что это за программа

What is MSBuild?

MSBuild, or the Microsoft Build Engine platform, is a collection of tools used to build applications using Microsoft and third-party compilers like Intel and NVIDIA CUDA. It uses an XML control schema to instruct the system on how to compile the project. While MSBuild is included and used by Visual Studio, it is separate and useable without installing the full Visual Studio suite.

What can it do, and how does it work?

MSBuild is the Microsoft toolchain for compiling code, linking it with any necessary dependencies, and then converting it into assembly language for use in an executable file.

When you run MSBuild, either via Visual Studio or on the command line, the project file and any deployment directives are combined into a single set of instructions. As MSBuild iterates through each project in the build instructions, then builds the project using the appropriate compiler and linker. If the project is web-based, it invokes additional tools like MSDeploy or VSDBCMD to deploy web applications and interact with any necessary databases. Additionally, MSBuild can execute tests and any additional workloads specified in the project file.

History of MSBuild and the Latest Version

Microsoft has released various compilers since the MS-DOS and Windows 9x days. Development suites like Microsoft Visual C++ and Visual Basic included these compilers as built-in components tailored to the specific language those products targeted, rather than stand-alone tools.

In 1997, Microsoft released Visual Studio 97, which included a unified development environment for multiple languages. Microsoft released MSBuild in 2003 as part of the .NET Framework, allowing developers to compile .NET projects. Still, it wasn’t until Visual Studio 2013 when the MSBuild system (then version 12) emerged as a stand-alone software package that could build not only .NET applications but C#, C++, and Visual Basic programs as well.

Since 2013, MSBuild has continued to be released as part of Visual Studio but is also available as a separate download. As of this writing, the latest stable version of the MSBuild Tools is 2019 – 16.9.3.

How to Download and Install MSBuild

The easiest way to install MSBuild is to install it as part of Microsoft’s Visual Studio IDE, available at https://visualstudio.microsoft.com/downloads/. If you want to install MSBuild without Visual Studio, you can download them from https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2019.

The Visual Studio installer is more complex as it allows the installation of various compilers, language support modules for the IDE, and other related tools like Git. If you choose the build tools (commonly called MSBuild) installer, it will still use the Visual Studio setup system but only preselect the MSBuild Tools. Clicking the Install button without selecting other items will set up MSBuild.

MSBuild Examples

In contrast to compiler systems like GCC, MSBuild takes most of its parameters from the project XML and development environment specification files. As such, a typical command line build looks like this:

MSbuild.exe Project.proj /fl /ds /p:TargetEnvPropsFile=EnvConfig\Dev.proj

The .proj files are produced automatically by Visual Studio, but since they are simply XML files, you can either create them yourself or edit existing files.

In the above example, the /fl switch tells MSBuild to log the output of the build process to a file called msbuild.log. The /ds switch, short for /detailedsummary, produces a detailed report at the end of the build.

You can specify /m:X to use X CPU cores on the system to increase the speed of the compiler and /v:X to adjust the verbosity of MSBuild using values “q” for quiet, “m” for minimal, “n” for normal, “d” for detailed, or “diag” for diagnostic.

MSBuild for Windows

MSBuild is native to Windows and runs well on this platform. Installation is covered under the previous heading “How to Download and Install MSBuild”.

MSBuild for Linux

On Linux, you have the choice of downloading binaries of MSBuild or compiling the tools from scratch. Installing the pre-built binaries is easy—just grab the .NET Core SDK for Linux (https://dotnet.microsoft.com/download).

If you are adventurous and want to compile MSBuild from source, you can find the project at GitHub (https://github.com/dotnet/msbuild). Microsoft has provided directions on building the suite on Linux ( https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Building-Testing-and-Debugging-on-.Net-Core-MSBuild.md).

Advantages

MSBuild is an excellent tool for automating the building of software on Windows. Its deep integration with the operating system, superb compatibility with Visual Studio, open-source license, and flexibility make it an excellent choice. Using it outside Visual Studio allows for command line integration with external build scripts and systems, enabling more robust automation possibilities.

Is it Open Source?

Microsoft released MSBuild as free and open-source software at GitHub (https://github.com/dotnet/msbuild) under the MIT License.

MSBuild and Incredibuild

Incredibuild turbocharges development with Virtualized Distributed Processing™ technology, turning every host into a supercomputer with hundreds of cores. With Incredibuild, accelerated product development from compilation to testing and release automation delivers better products to market radically faster.

Incredibuild virtualizes your local MSBuild environment on every host you specify, and is bundled as the accelerator of choice within Microsoft Visual Studio. Using the same code, processes, and tools, developers and managers accelerate product development with X8 faster builds, 80% shorter release cycles, and X4 the number of iterations, consistently releasing better products to market radically faster.