rickgaribay.net

Space shuttles aren't built for rocket scientists, they're built for astronauts. The goal isn't the ship, its the moon.
posts - 303, comments - 180, trackbacks - 35

My Links

News

Where's Rick?


AgileAlliance deliver:Agile 2019- 4/29
Desert Code Camp, PHX - 10/11
VS Live Austin, TX - 6/3
VS Live SF - 6/17


About Me
Hands on leader, developer, architect specializing in the design and delivery of distributed systems in lean, agile environments with an emphasis in continuous improvement across people, process and technology. Speaker and published author with 18 years' experience leading the delivery of large and/or complex, high-impact distributed solutions in Retail, Intelligent Transportation, and Gaming & Hospitality.

I'm currently a Principal Engineer at Amazon, within the North America Consumer organization leading our global listings strategy that enable bulk and non-bulk listing experiences for our WW Selling Partners via apps, devices and APIs.

Full bio

Note: All postings on this site are my own and don’t necessarily represent the views of my employer.



Check out my publications on Amazon Kindle!





Archives

Post Categories

Published Works

MSBuild Reference Paths

One of the nice things about MSBuild is that with Visual Studio 2005, the project and solution files are the build files. So, in theory, MSBUILD will start at the sln file and walk all references during a build process.

But, what happens when you have an automated build process, or are doing continous integration and want to standardize project references to assemblies and other vendor components? Trying to get an entire development on board to use specific paths, etc is an option, but since no one is perfect (and enforcing these rules can be a nightmare), we need a better way to standardize the management of how dependancies are accessed.

With a build process in place, the build can facilitate this standardization. Assemblies, both internal and from external vendors can be catalogued on a file share and the build process itself can reference this shared location in a standardized manner, without trying to micro-manage development environment settings.

The solution is to use the ReferencePath property at the MSBUIILD command line.

For example:

MSBUILD.EXE <solution name>  /p:"ReferencePath=<Path1;Path2;Path3>"

The ReferencePath property allows you to add a series of paths that MSBUILD will check, overriding any project-based references.

This is extremely helpful when references are all over the place or when it is undesirable to recreate development-time configuration at build time.

Print | posted on Saturday, August 25, 2007 3:50 PM | Filed Under [ Processs Visual Studio Continuous Integration ]

Feedback

Gravatar

# re: MSBuild Reference Paths

Rick: Do you run this from inside a CMD window or a Powershell window?
8/26/2007 10:10 AM | Guy
Gravatar

# re: MSBuild Reference Paths

Hi there.

MSBuild is run from the command window. That raises a good question though- are cmd commands backwards compatible when running powershell?
8/26/2007 11:59 AM | Rick
Gravatar

# re: MSBuild Reference Paths

/p:"ReferencePath=<Path1;Path2;Path3>" it just save my day!

Thx
10/29/2008 10:45 AM | PN
Gravatar

# MSBuild vs IDE

Hi. Anyone notice differences in the publish directory, building a sln project from the IDE vs msbuild?
I’m getting some dll’s in different locations (with msbuild is in the root and with the IDE is in bin).
11/6/2008 11:32 AM | Pedro Nunes
Comments have been closed on this topic.

Powered by: