Find the Best Cosmetic Hospitals

Explore trusted cosmetic hospitals and make a confident choice for your transformation.

“Invest in yourself — your confidence is always worth it.”

Explore Cosmetic Hospitals

Start your journey today — compare options in one place.

Running MSBuild 4.0 and 3.5 Side by Side on Legacy CruiseControl.NET CI

This guide explains how to keep a legacy CruiseControl.NET environment building both older .NET projects and Visual Studio 2010-era projects. You will learn why builds fail after an upgrade, how to point CI to MSBuild 4.0, and how to retain MSBuild 3.5 jobs when both are still needed.

Originally published on 2010-03-09; fully revised and updated.

Source context: Running MSBuild 4.0 and MSBuild 3.5 on Continuous Integration.

MSBuild 4.0 and MSBuild 3.5 on CI

Why builds fail after moving to Visual Studio 2010 projects

In the original scenario, teams upgraded code to Visual Studio 2010 RC. The CI server (CruiseControl.NET) still executed MSBuild 3.5 paths, so upgraded solutions failed. The practical fix is to make sure the CI machine has .NET Framework 4.0 and the Visual Studio 2010 MSBuild target files expected by those projects.

MSBuild 3.5 vs MSBuild 4.0 in this migration

ItemMSBuild 3.5MSBuild 4.0CI impact
Typical executable pathC:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exeC:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exeWrong path in ccnet.config causes immediate build failure
Framework dependency.NET Framework 3.5.NET Framework 4.0CI agent must have required runtime installed
Targets used by VS2010-era projectsOlder target setVisual Studio v10.0 target setMissing targets produce import/target-not-found errors
Best use in mixed legacy estateKeep for older solutionsUse for upgraded solutionsRun separate CI project definitions when needed

Legacy remediation workflow

flowchart TD
    A[Commit includes VS2010 project files] --> B[CI checks out source]
    B --> C{DotNet 4 installed on CI server?}
    C -- No --> D[Install DotNet 4 and reboot]
    C -- Yes --> E[Copy v10.0 MSBuild targets]
    D --> E
    E --> F[Update ccnet msbuild executable path]
    F --> G[Run build with MSBuild 4]
    G --> H{Build succeeds?}
    H -- No --> I[Review paths and missing targets]
    H -- Yes --> J[Continue CI pipeline]

Step-by-step fix on CruiseControl.NET

1) Install .NET Framework 4.0 on the CI server

The original guidance requires installing .NET Framework 4.0 on the CI machine, preferably the full framework profile. After installation, restart the server (or at minimum restart build services) so the runtime and paths are fully available.

2) Copy Visual Studio v10.0 MSBuild targets

From a machine where Visual Studio 2010 RC is installed, copy the v10.0 folder under %ProgramFiles%\MSBuild\Microsoft\VisualStudio to the same location on the CI server.

Copy-Item -Path 'C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0' -Destination 'C:\Program Files\MSBuild\Microsoft\VisualStudio\' -RecurseCode language: JavaScript (javascript)

3) Update ccnet.config to invoke MSBuild 4.0

In the CruiseControl.NET project configuration, change the MSBuild executable from the 3.5 path to the 4.0 path.

<msbuild>
  <executable>C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe</executable>
  <workingDirectory>C:\Build\MyApp</workingDirectory>
  <projectFile>MyApp.sln</projectFile>
</msbuild>Code language: HTML, XML (xml)

4) Keep 3.5 and 4.0 builds side by side

If you still build older solutions, define separate CI projects (or tasks) so each one points at the correct MSBuild executable.

<!-- Legacy solution -->
<msbuild>
  <executable>C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
  <projectFile>Legacy.sln</projectFile>
</msbuild>

<!-- VS2010 solution -->
<msbuild>
  <executable>C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe</executable>
  <projectFile>Upgraded.sln</projectFile>
</msbuild>Code language: HTML, XML (xml)

5) Verify executable resolution

C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe /version
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /version

Common pitfalls on legacy CI servers

  • Updating project files but forgetting to change the MSBuild executable path in ccnet.config.
  • Installing only partial framework components and missing build-time dependencies.
  • Copying target files to a different directory than the path expected by MSBuild imports.
  • Using one global build definition for mixed legacy and upgraded solutions instead of separate tasks.
  • Skipping service/server restart after framework installation, leaving agents in stale state.

Find Trusted Cardiac Hospitals

Compare heart hospitals by city and services — all in one place.

Explore Hospitals
I'm Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms. I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.

Related Posts

MSBuild for Beginners: Project File Fundamentals, Build Flow, and Practical Commands

Learn how MSBuild project files are structured, how targets and tasks execute, and which commands are most useful in CI/CD. This revised guide also preserves the original learning links from the post.

Read More

MSBuild File Extensions Explained: .proj, .targets, .props, .tasks, and *proj Types

Understand what common MSBuild-related file extensions do and how they fit together in real .NET build pipelines. This revised guide includes a comparison table, import-flow diagram, and practical XML examples.

Read More

Release Management with IBM Rational Build Forge: Workflow, Resource Map, and Practical Checklist

The original post was a short resource list for IBM Rational deployment automation. This revised guide explains how to use those resources in a release-management workflow and adds a practical, tool-agnostic release checklist.

Read More

MSBuild Quick Start for DevOps: Projects, Targets, Tasks, and CLI Builds

Learn how MSBuild works from the inside out, including projects, properties, items, targets, and tasks. This revised guide adds a build workflow diagram, command examples, and practical usage patterns for automation.

Read More

Continuous Integration/Continuous Delivery (CI/CD) Tools in 2024

Here is a list of some of the best CI/CD tools in 2024: The best CI/CD tool for you will depend on your particular needs and requirements….

Read More

What is Continuous Integration?

Continuous Integration (CI) is a software development practice and approach that involves the frequent and automated integration of code changes from multiple developers into a shared repository….

Read More
Subscribe
Notify of
guest
0 Comments
Newest
Oldest Most Voted
0
Would love your thoughts, please comment.x
()
x