using dirPath Provider with WebDeploy - msbuild

I have a wcf application hosted in iis that i am trying to package using webdeploy. Everything works great with the visual studio tools, but i need to also create a logs folder and set permissions on it. For this i created a ProjectName.wpp.target file in my web project.
The file looks like this
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="CreateLogsDirectory" AfterTargets="AddIisSettingAndFileContentsToSourceManifest">
<!-- This must be declared inside of a target because the property
$(_MSDeployDirPath_FullPath) will not be defined at that time. -->
<ItemGroup>
<MsDeploySourceManifest Include="dirPath">
<Path>$(_MSDeployDirPath_FullPath)\logs</Path>
<enableRule>DoNotDeleteRule</enableRule>
</MsDeploySourceManifest>
</ItemGroup>
</Target>
<Target Name="DeclareCustomParameters" AfterTargets="AddIisAndContentDeclareParametersItems">
<!-- This must be declared inside of a target because the property
$(_EscapeRegEx_MSDeployDirPath) will not be defined at that time. -->
<ItemGroup>
<MsDeployDeclareParameters Include="LogsDirectoryPath">
<Kind>ProviderPath</Kind>
<Scope>dirPath</Scope>
<Match>^$(_EscapeRegEx_MSDeployDirPath)\\logs$</Match>
<Value>$(_DestinationContentPath)/log</Value>
<ExcludeFromSetParameter>True</ExcludeFromSetParameter>
</MsDeployDeclareParameters>
</ItemGroup>
</Target>
</Project>
i can see that dirPath provider is added to the sourcemanifest file, but when i deploy the package it tries to create the source file path. Essentially the LogsDirectoryPAth item is not replacing the path. can someone point out what i need to do ? thanks !

Considering your additional directory is inside your web application, it's not really necessary to include another dirPath provider and doing so would only lead to more headaches (additional parameter declarations, etc).
Here are some helpers I use to help with this kind of thing. Your application specific values can be declared in your wpp.targets file:
<!-- Items specific to your application (these should be in your wpp.targets) -->
<ItemGroup>
<SkipDeleteFiles Include="logs" />
<EmptyDirectoriesToDeploy Include="logs" />
<AdditionalAcls Include="logs">
<AclAccess>Write</AclAccess>
</AdditionalAcls>
</ItemGroup>
And the following convention-based definitions can be either put in you wpp.targets or in a common targets file that can be imported into your wpp.targets:
<!--
Empty directories
-->
<PropertyGroup>
<BeforeAddContentPathToSourceManifest>
$(BeforeAddContentPathToSourceManifest);
CreateEmptyDirectories;
</BeforeAddContentPathToSourceManifest>
</PropertyGroup>
<Target Name="CreateEmptyDirectories">
<MakeDir Directories="$(_MSDeployDirPath_FullPath)\%(EmptyDirectoriesToDeploy.Identity)"
Condition="'#(EmptyDirectoriesToDeploy)' != ''" />
</Target>
<!--
Additional ACLs
-->
<ItemDefinitionGroup>
<AdditionalAcls>
<AclAccess>Write</AclAccess>
<ResourceType>Directory</ResourceType>
</AdditionalAcls>
</ItemDefinitionGroup>
<PropertyGroup>
<AfterAddIisSettingAndFileContentsToSourceManifest>
$(AfterAddIisSettingAndFileContentsToSourceManifest);
AddAdditionalAclsToSourceManifest;
</AfterAddIisSettingAndFileContentsToSourceManifest>
<AfterAddIisAndContentDeclareParametersItems>
$(AfterAddIisAndContentDeclareParametersItems);
AddAdditionalAclsDeclareParameterItems
</AfterAddIisAndContentDeclareParametersItems>
</PropertyGroup>
<Target Name="AddAdditionalAclsToSourceManifest">
<ItemGroup Condition="'#(AdditionalAcls)' != ''">
<MsDeploySourceManifest Include="setAcl">
<Path>$(_MSDeployDirPath_FullPath)\%(AdditionalAcls.Identity)</Path>
<setAclResourceType Condition="'%(AdditionalAcls.ResourceType)' != ''">%(AdditionalAcls.ResourceType)</setAclResourceType>
<setAclAccess>%(AdditionalAcls.AclAccess)</setAclAccess>
<AdditionalProviderSettings>setAclResourceType;setAclAccess</AdditionalProviderSettings>
</MsDeploySourceManifest>
</ItemGroup>
</Target>
<Target Name="AddAdditionalAclsDeclareParameterItems">
<ItemGroup Condition="'#(AdditionalAcls)' != ''">
<MsDeployDeclareParameters Include="Add %(AdditionalAcls.AclAccess) permission to %(AdditionalAcls.Identity) Folder">
<Kind>ProviderPath</Kind>
<Scope>setAcl</Scope>
<Match>^$(_EscapeRegEx_MSDeployDirPath)\\#(AdditionalAcls)$</Match>
<Description>Add %(AdditionalAcls.AclAccess) permission to %(AdditionalAcls.Identity) Folder</Description>
<DefaultValue>{$(_MsDeployParameterNameForContentPath)}/#(AdditionalAcls)</DefaultValue>
<DestinationContentPath>$(_DestinationContentPath)/#(AdditionalAcls)</DestinationContentPath>
<Tags>Hidden</Tags>
<ExcludeFromSetParameter>True</ExcludeFromSetParameter>
<Priority>$(VsSetAclPriority)</Priority>
</MsDeployDeclareParameters>
</ItemGroup>
</Target>
<!--
Skip delete files and directories
-->
<PropertyGroup>
<ImportPublishingParameterValuesDependsOn>
$(ImportPublishingParameterValuesDependsOn);
AddSkipDirectives;
</ImportPublishingParameterValuesDependsOn>
</PropertyGroup>
<ItemGroup>
<SkipDeleteItems Include="#(SkipDeleteFiles)"
Condition="'#(SkipDeleteFiles)' != ''">
<Provider>filePath</Provider>
</SkipDeleteItems>
<SkipDeleteItems Include="#(SkipDeleteDirectories)"
Condition="'#(SkipDeleteDirectories)' != ''">
<Provider>dirPath</Provider>
</SkipDeleteItems>
</ItemGroup>
<!-- Uses MSBuild trickery to add an escaped version of the skip path to as
"EscapedPath" metadata -->
<Target Name="AddRegexEscapedPathMetadata" Outputs="%(SkipDeleteItems.EscapedPath)">
<EscapeTextForRegularExpressions Text="%(SkipDeleteItems.Identity)">
<Output TaskParameter="Result"
PropertyName="_Temp_EscapeRegEx_SkipDeleteItemPath" />
</EscapeTextForRegularExpressions>
<ItemGroup>
<SkipDeleteItems Condition="'%(SkipDeleteItems.Identity)' == '%(Identity)'" >
<EscapedPath>$(_Temp_EscapeRegEx_SkipDeleteItemPath)</EscapedPath>
</SkipDeleteItems>
</ItemGroup>
<PropertyGroup>
<!-- Clear value -->
<_Temp_EscapeRegEx_SkipDeleteItemPath></_Temp_EscapeRegEx_SkipDeleteItemPath>
</PropertyGroup>
</Target>
<Target Name="AddSkipDirectives" DependsOnTargets="AddRegexEscapedPathMetadata">
<ItemGroup>
<MsDeploySkipRules Include="%(SkipDeleteItems.Identity)">
<SkipAction>Delete</SkipAction>
<ObjectName>%(SkipDeleteItems.Provider)</ObjectName>
<AbsolutePath>%(SkipDeleteItems.EscapedPath)</AbsolutePath>
</MsDeploySkipRules>
</ItemGroup>
</Target>
NB If you go to the extra effort to separate your packaging process from your deployment process, then technically your SkipDeleteFiles should be in your pubxml rather than your wpp.targets.

Related

How to create custom project file that works with fast-up-to-date (and avoids other problems)?

I am trying to create a project file that performs few custom steps (specifically, it "wraps" existing Angular CLI project).
Here is my best attempt (myproject.csproj):
<Project ToolsVersion="Current" DefaultTargets="Build">
<PropertyGroup>
<ProjectGuid>{...some-guid...}</ProjectGuid>
<!-- do not include files by default -->
<EnableDefaultItems>false</EnableDefaultItems>
<!-- this removes 'Publish...' menu in VS -->
<OutputType>Library</OutputType>
<!-- output directory name -->
<AngularProject>MyWebFiles</AngularProject>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x64'">
<PlatformTarget>x64</PlatformTarget>
<OutputPath>bin\Debug\</OutputPath>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
<PlatformTarget>x64</PlatformTarget>
<OutputPath>bin\Release\</OutputPath>
</PropertyGroup>
<ItemGroup>
<AngularFile Include="**" Exclude="node_modules\**" />
</ItemGroup>
<Target Name="Build" Inputs="#(AngularFile)" Outputs="$(OutputPath)$(AngularProject)\index.html">
<Exec Command="ng build --no-progress --output-path $(OutputPath)$(AngularProject)\" Condition="'$(Configuration)'=='Debug'" />
<Exec Command="ng build --no-progress --output-path $(OutputPath)$(AngularProject)\ --prod" Condition="'$(Configuration)'=='Release'" />
</Target>
<Target Name="Clean">
<RemoveDir Directories="$(OutputPath)$(AngularProject)\" />
</Target>
<Target Name="Rebuild" DependsOnTargets="Clean;Build" />
</Project>
Everything works fine, I can add this project to VS2019 solution, compile, etc. But it has problems:
Fast up-to-date check doesn't work. Related logging produces this:
Build started...
1>Project 'myproject' is not up to date. Error (0x8000FFFF).
I've tried specifying fast up-to-date files manually (via UpToDateCheckInput, etc), but it didn't work (presumably because it relies on additional definitions pulled in when you specify Sdk attribute of Project tag).
VS configuration manager has empty 'Platform' combo box. I'd like to be able to have x64 in it:
it is rather obvious that PlatformTarget is getting ignored by VS.
Opening project in VS results in creation of obj\x64\Debug\TempPE\ directory (if current Configuration is Debug). Nothing ever gets generated in it -- would be nice to avoid it being created.
Is it possible to fix these 3 problems? I suspect relates subsystems expect certain values/properties to be generated, I've tried digging in .props/.targets that come with VS in attempt to locate them, but quickly got lost.
Here is how to do it:
<Project Sdk="Microsoft.Build.NoTargets/3.2.14">
<ItemGroup>
<PackageReference Include="Microsoft.Build.NoTargets" Version="3.2.14" />
</ItemGroup>
<PropertyGroup>
<!-- Any target framework you want as long as its compatible with your referenced NuGet packages -->
<TargetFramework>net462</TargetFramework>
<Platforms>x64</Platforms>
<!-- Do not add TargetFramework to OutputPath -->
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<!-- Do not expect pdb files to be generated (this is for fast up-to-date check) -->
<DebugType>None</DebugType>
<!-- Do not include files by default -->
<EnableDefaultItems>false</EnableDefaultItems>
<!-- Output subdir name -->
<AngularProject>MyWebFiles</AngularProject>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<OutputPath>..\..\Bin\Debug\</OutputPath>
<BuildCommand>ng build --no-progress --output-path $(OutputPath)$(AngularProject)\</BuildCommand>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<OutputPath>..\..\Bin\Release\</OutputPath>
<BuildCommand>ng build --no-progress --output-path $(OutputPath)$(AngularProject)\ --prod</BuildCommand>
</PropertyGroup>
<ItemGroup>
<None Include="**" Exclude="node_modules\**;$(BaseIntermediateOutputPath)\**;$(MSBuildProjectFile)" />
<!-- This deals with fast up-to-date checks -->
<UpToDateCheckBuilt Original="package-lock.json" Include="node_modules/.build" />
<UpToDateCheckInput Include="#(None);$(MSBuildProjectFile)" Set="AngularFiles" />
<UpToDateCheckOutput Include="$(OutputPath)$(AngularProject)\index.html" Set="AngularFiles" />
</ItemGroup>
<Target Name="InitModules" Inputs="package-lock.json" Outputs="node_modules/.build">
<Exec Command="npm ci --no-progress --no-color" YieldDuringToolExecution="true" />
<Exec Command="cd . > node_modules/.build" />
</Target>
<Target Name="BuildAngular" BeforeTargets="AfterBuild" Inputs="#(None);$(MSBuildProjectFile)" Outputs="$(OutputPath)$(AngularProject)\index.html" DependsOnTargets="InitModules">
<Exec Command="$(BuildCommand)" YieldDuringToolExecution="true" />
</Target>
<Target Name="CleanAngular" BeforeTargets="AfterClean">
<RemoveDir Directories="$(OutputPath)$(AngularProject)\" />
</Target>
</Project>
Notes:
it will still generate additional local directory (obj), but it can be moved away by overriding IntermediateOutputPath

How can I include different packages in different Configuration/Platform combinations?

I have a library that is designed to work with Sap Business One's SDK. The SDK for V10 is different to the one for V9.3, I also have x86/x64 and SQL/HANA builds, this gives me 8 permutations and therefore 8 packages.
The projects that consume these packages will also have 8 builds. I would like to set up the project file and targets so that a specific package is selected for a specific Configuration & Platform. I am trying to work this out, but it makes absolutely no sense.
Currently I have the following in my project file:
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93SQL|x64' ">
<PackageReference Include="OchALCommon.v93SQLx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93SQL|x86' ">
<PackageReference Include="OchALCommon.v93SQLx86" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93HANA|x64' ">
<PackageReference Include="OchALCommon.v93HANAx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93HANA|x86' ">
<PackageReference Include="OchALCommon.v93HANAx86" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10SQL|x64' ">
<PackageReference Include="OchALCommon.v10SQLx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10SQL|x86' ">
<PackageReference Include="OchALCommon.v10SQLx86" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10HANA|x64' ">
<PackageReference Include="OchALCommon.v10HANAx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10HANA|x86' ">
<PackageReference Include="OchALCommon.v10HANAx86" Version="1.0.*" />
</ItemGroup>
Visual studio indicates all 8 packages and a build process the dependencies of each one - this seems wrong. I also tried this code within a "Directory.Build.targets" file, which initially seemed to work, but then Visual Studio stopped reponding to changes in the targets file (even after a reboot).
We have always used this kind of referencing in the past with Assembly references,and it seems to work, I have no idea how to make PackageReference function. Does anybody know how best to package this library in my scenario?
In an ideal world, I'd want to somehow store my 64 bit and 32 bit build plus some appropriate targets in a single nuget package so that the consuming project gets the right bitness and the right sub project references. Currently I can't work out how to do this, nor get any other workable scenario going.
Again, does anybody know how to do anything like this?
Thanks.
Thus far I have been able to solve the issue by using separate files (.targets) for each ProjectReference, and then ensuring that only those files containing the reference information are included in the project by referencing specific .targets files.
I have then put .targets files into an umbrella nupkg to select which of the actual payloads I want to use. The entire arrangement looks as follows:
I published 8 payload files as follows:
MyLibrary.v93HANAx64
MyLibrary.v93HANAx86
MyLibrary.v93SQLx64
MyLibrary.v93SQLx86
MyLibrary.v10HANAx64
MyLibrary.v10HANAx86
MyLibrary.v10SQLx64
MyLibrary.v10SQLx86
Each payload file simply contains a standard lib/net40 folder with libraries as specified in the https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package page.
My consuming project has 4 Configurations:
B1v93HANA
B1v93SQL
B1v10HANA
B1v10SQL
I then have an umbrella project "MyLibrary.Targets" containing content as follows:
##build/net40/MyLibrary.Targets.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<Import Project="MyLibrary/$(Configuration).targets" />
</Project>
##build/net40/MyLibrary/B1v10HANA.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v10HANA$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
##build/net40/MyLibrary/B1v10SQL.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v10SQL$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
##build/net40/MyLibrary/B1v93HANA.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v93HANA$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
##build/net40/MyLibrary/B1v93SQL.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v93SQL$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
I also have targets files in this folder, "Debug.targets" and "Release.targets" which use my preferred default library in those cases.
.nupec files for all of the packages are pretty standard as per the above linked Microsoft guide. A default nuspec file can be created with the 'nuget spec' command and can then be edited.
My functional package nuspec files have content in 'package/metadata/dependencies' which identify required packages:
<dependencies>
<group targetFramework=".NETFramework4.0">
<dependency id="CryptLib" version="*" />
<dependency id="SAPBusinessOneSDK.HANA" version="10.0.*" />
</group>
</dependencies>
My Selector package "MyLibrary.targets" does not have dependencies, but does have a files section 'package/files':
<files>
<file src="readme.txt" target="" />
<file src="build\**" target="build" />
</files>
Hopefully this saves somebody some time.

MSBuild well-known item metadata and NuGet pack

I am trying to add custom files to a specific NuGet package (basically I need all output files included in the NuGet package since it serves as a tool for Chocolatey).
After some searching, I found this potential fix:
<PropertyGroup>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);GetToolsPackageFiles</TargetsForTfmSpecificBuildOutput>
</PropertyGroup>
<Target Name="GetToolsPackageFiles">
<ItemGroup>
<BuildOutputInPackage Include="$(OutputPath)\**\*.dll" />
<BuildOutputInPackage Include="$(OutputPath)\**\*.exe" />
</ItemGroup>
</Target>
Unfortunately, this won't work correctly for subdirectories, so I tried this:
<PropertyGroup>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);GetToolsPackageFiles</TargetsForTfmSpecificBuildOutput>
</PropertyGroup>
<Target Name="GetToolsPackageFiles">
<ItemGroup>
<BuildOutputInPackage Include="$(OutputPath)\**\*.dll">
<TargetPath>$([MSBuild]::MakeRelative('$(OutputPath)', %(FullPath)))</TargetPath>
</BuildOutputInPackage>
<BuildOutputInPackage Include="$(OutputPath)\**\*.exe">
<TargetPath>$([MSBuild]::MakeRelative('$(OutputPath)', %(FullPath)))</TargetPath>
</BuildOutputInPackage>
</ItemGroup>
</Target>
According to the docs, I should be able to use %(FullPath), but I am getting this error:
error MSB4184: The expression "[MSBuild]::MakeRelative(C:\Sour
ce\RepositoryCleaner\output\Release\RepositoryCleaner\netcoreapp3.1\, '')" cannot be evaluated. Parameter "path" cannot have zero length.
[C:\Source\RepositoryCleaner\src\RepositoryCleaner\RepositoryCleaner.csproj]
Any idea why the well-known items don't seem to work in this scenario?
Got a fix by specifying the item group outside the target and then using that instead.
<PropertyGroup>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);GetToolsPackageFiles</TargetsForTfmSpecificBuildOutput>
</PropertyGroup>
<ItemGroup>
<ToolDllFiles Include="$(OutputPath)\**\*.dll" />
<ToolExeFiles Include="$(OutputPath)\**\*.exe" />
</ItemGroup>
<Target Name="GetToolsPackageFiles">
<ItemGroup>
<BuildOutputInPackage Include="#(ToolDllFiles)">
<TargetPath>$([MSBuild]::MakeRelative('$(OutputPath)', %(ToolDllFiles.FullPath)))</TargetPath>
</BuildOutputInPackage>
<BuildOutputInPackage Include="#(ToolExeFiles)">
<TargetPath>$([MSBuild]::MakeRelative('$(OutputPath)', %(ToolExeFiles.FullPath)))</TargetPath>
</BuildOutputInPackage>
</ItemGroup>
</Target>

EmbeddedResource not working inside Target

I have some TypescriptCompile files which I then want to embed in my .dll. I had to migrate to the new csproj format and now I can't embed while inside a Target.
This works:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
</PropertyGroup>
<ItemGroup>
<EmbeddedResource Include="testFile.ts" />
</ItemGroup>
</Project>
While this does not:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
</PropertyGroup>
<Target Name="AddGeneratedToBuildOutput" BeforeTargets="CoreCompile">
<ItemGroup>
<PackageFiles Include="$(MSBuildProjectDirectory)\**\*.*;"/>
</ItemGroup>
<Message Text="The target is called: %(PackageFiles.FullPath)" Importance="high"/>
<ItemGroup>
<EmbeddedResource Include="testFile.ts" />
</ItemGroup>
</Target>
</Project>
Note that the message gets written and the referred file is in the project, hence we can be sure that the target gets called.
I already tried other targets instead of CoreCompile but since I'm using TypeScriptCompile, if I use BeforeBuild, Build or ResolveReferences I get compilation errors since the .js files are not generated yet.
I'm using JetBrains' DotPeek to inspect the resources and using msbuild 15.0.
Solution to this problem is here: https://github.com/microsoft/msbuild/issues/4778

Additional paths in msbuild script

How to specify additional assembly reference paths for the MSBuild tasks?
I have following script so far, but can't figure out how to specify additional search paths.
<ItemGroup>
<ProjectsToBuild Include="..\Main\Main.sln" />
</ItemGroup>
<!-- The follwing paths should be added to reference search paths for the build tasks -->
<ItemGroup>
<MyAddRefPath Include="$(MSBuildProjectDirectory)\..\..\Build\Lib1" />
<MyAddRefPath Include="$(MSBuildProjectDirectory)\..\..\Build\Lib2" />
</ItemGroup>
<MSBuild
Projects="#(ProjectsToBuild)"
Properties="Configuration=Debug;OutputPath=$(BuildOutputPath)">
</MSBuild>
UPDATE:
Please show one complete working script which invokes original project, such as an SLN with multiple additional reference paths.
No suggestions on how to improve the project structure please.
I know how to build a good structure, but now it's the task of building an existing piece of crap.
I have finaly figured out how to do it:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<ProjectsToBuild Include="ConsoleApplication1\ConsoleApplication1.csproj" />
</ItemGroup>
<ItemGroup>
<AdditionalReferencePaths Include="..\Build\ClassLibrary1" />
<AdditionalReferencePaths Include="..\Build\ClassLibrary2" />
</ItemGroup>
<PropertyGroup>
<BuildOutputPath>..\Build\ConsoleApplication1</BuildOutputPath>
</PropertyGroup>
<Target Name="MainBuild">
<PropertyGroup>
<AdditionalReferencePathsProp>#(AdditionalReferencePaths)</AdditionalReferencePathsProp>
</PropertyGroup>
<MSBuild
Projects="ConsoleApplication1\ConsoleApplication1.csproj"
Properties="ReferencePath=$(AdditionalReferencePathsProp);OutputPath=$(BuildOutputPath)"
>
</MSBuild>
</Target>
The property you want to modify is AssemblySearchPaths. See the ResolveAssemblyReference task more information.
<Target Name="AddToSearchPaths">
<CreateProperty Value="x:\path\to\assemblies;$(AssemblySearchPaths)">
<Output PropertyName="AssemblySearchPaths" TaskParameter="Value" />
</CreateProperty>
</Target>
Making use of item groups, as in your example, it would look like:
<Target Name="AddToSearchPaths">
<CreateProperty Value="#(MyAddRefPath);$(AssemblySearchPaths)">
<Output PropertyName="AssemblySearchPaths" TaskParameter="Value" />
</CreateProperty>
</Target>
Looking in %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets, you can see that the ResolveAssemblyReference Task is executed as part of the ResolveAssemblyReferences target. Thus, you want the newly added target to modify the AssemblySearchPaths property before ResolveAssemblyReferences is executed.
You've stated that you want to be able to modify the assembly search paths without modifying the project files directly. In order to accomplish that requirement you need to set an environment variable that will override the AssemblySearchPaths. With this technique you will need to provide every assembly reference path used by all the projects in the solutions. (Modifying the projects or copies of the projects would be easier. See final comments.)
One technique is to create a batch file that runs your script at sets the environment variable:
set AssemblySearchPaths="C:\Tacos;C:\Burritos;C:\Chalupas"
msbuild whatever.msbuild
Another way is to define a PropertyGroup in your custom msbuild file (otherwise known as the "hook" needed to make this work):
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<ProjectsToBuild Include="..\Main\Main.sln" />
</ItemGroup>
<PropertyGroup>
<AssemblySearchPaths>$(MSBuildProjectDirectory)\..\..\Build\Lib1;$(MSBuildProjectDirectory)\..\..\Build\Lib2</AssemblySearchPaths>
</PropertyGroup>
<Target Name="Build">
<MSBuild Projects="#(ProjectsToBuild)" Properties="AssemblySearchPaths=$(AssemblySearchPaths);Configuration=Debug;OutputPath=$(OutputPath)" />
</Target>
</Project>
Now if it were me, and for whatever unexplained reason I couldn't modify the project files to include the updated references that I am going to build with, I would make copies of the project files, load them into the IDE, and correct the references in my copies. Synching the projects becomes a simple diff/merge operation which is automatic with modern tools like mercurial (heck I'm sure clearcase could manage it too).
...and remember that you don't need to use a target for this, you can use project-scoped properties or items, as...
<ItemGroup>
<MyAddRefPath Include="$(MSBuildProjectDirectory)\..\..\Build\Lib1" />
<MyAddRefPath Include="$(MSBuildProjectDirectory)\..\..\Build\Lib2" />
</ItemGroup>
<PropertyGroup>
<MyAddRefPath>$(MSBuildProjectDirectory)\..\..\Build\Lib3</MyAddRefPath>
<!-- add in the property path -->
<AssemblySearchPaths>$(MyAddRefPath);$(AssemblySearchPaths)</AssemblySearchPaths>
<!-- add in the item paths -->
<AssemblySearchPaths>#(MyAddRefPath);$(AssemblySearchPaths)</AssemblySearchPaths>
</PropertyGroup>
...and if you do need to do this in a target to pick up paths from a dynamically populated item group, use inline properties, not the CreateProperty task (if you are not stuck in v2.0)
<Target Name="AddToSearchPaths">
<PropertyGroup>
<!-- add in the item paths -->
<AssemblySearchPaths>#(MyDynamicAddRefPath);$(AssemblySearchPaths)</AssemblySearchPaths>
</PropertyGroup>
</Target>