How do I force ""MSBuild"" to not copy referenced assemblies to the output directory?

By default, ""MSBuild"" determines whether or not to copy a reference and its dependencies to the project's output directory on its own. It makes this determination based on whether the assembly is part of the .NET Framework redist or in the GAC. You can override the default behavior through the Visual Studio user interface or by editing the project file by hand.

Through the Visual Studio UI, right-click on the reference and select Properties. In the Properties grid, change the value of ""CopyLocal"" to "true" if you want the reference copied and set it to "false" if you do not want the reference copied.

To do this in the project file itself, you need to add an item metadata called "Private" and set its value to "true" or "false" accordingly.

""Pre-Beta 1 Syntax""

		 <Item Type="Reference" Include="MyReferencedAssembly" Private="false"/>
	

Beta 1 syntax

		 [<ItemGroup>]
	

<Reference Include="MyReferencedAssembly">
<Private>false</Private>
</Reference>

		 [</ItemGroup>]
	

Followup: Why the name "Private"? That seems non-intuitive.
Answer: The name "Private" is what the metadata was called in the VS .NET 2002 and VS .NET 2003 timeframe, and thus was carried forward into the ""MSBuild"" file format. We may look into renaming the metadata to something more intuitive, but this requires an additional action in the project file conversion process.
Followup: How do I accomplish without changing every single project file? I want to change the default behavior for all of my projects.
Answer: Currently the only way to avoid modifying the individual project files is to modify Framework.targets (aka, Microsoft.Common.targets in Beta 1 and beyond). Find the call to the "Copy" task which is responsible for copying references to the output directory, and either comment it out or delete it. Alternatively, you could condition that task based on some new property that you define, and then pass in that property for command-line builds. However, the problem with this approach is that the property wouldn't be configurable through the IDE.