MSBuild - Publish multiple build configurations - visual-studio-2013

I have a solution that contains a website project, I've got a PublishProfile (.pubxml) setup for the Release build and this is configured within TFS build using /p:PublishProfile=BuildServerPublish. The profile looks like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>False</LaunchSiteAfterPublish>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>True</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>DonotMerge</WDPMergeOption>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>R:\MyApp\Live</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
</Project>
TFS is configured to do a CI build of the Release branch whenever a check-in occurs, and this works great.
The issue I now have is that we want to add in some staging servers to the process (QA, UAT, etc), and whilst I have created Build Configurations and Config Transforms for these in Visual Studio, the publish profile can only define a single build configuration (in this case Release), and moreover the build definition in TFS can only specify a single publish profile.
The end goal is to have TFS build the site and publish it multiple times (once for each build config) in separate subfolders, whilst doing the appropriate config transform for each. For example:
R:\MyApp\Qa
- containing the "QA" tranformed version of the config
R:\MyApp\Uat
- containing the "UAT" tranformed version of the config
R:\MyApp\Live
- containing the "Release" tranformed version of the config
My first idea was to create separate publish profiles for each build configuration, and then reference these in the build profile, using something like:
/p:PublishProfile=BuildServerQaPublish|BuildServerUatPublish|BuildServerLivePublish
..but TFS was having none of that.
My next idea was to have multiple publish settings within a single profile, like:
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Qa</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>False</LaunchSiteAfterPublish>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>True</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>DonotMerge</WDPMergeOption>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>R:\MyApp\Qa</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Uat</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>False</LaunchSiteAfterPublish>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>True</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>DonotMerge</WDPMergeOption>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>R:\MyApp\Uat</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>False</LaunchSiteAfterPublish>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>True</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>DonotMerge</WDPMergeOption>
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>R:\MyApp\Live</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
</Project>
..but that didn't work either.
The only other thing I can think of doing is to have multiple build definitions set up, each on referencing a separate publish profile, but I'm trying to avoid this for two reasons; firstly because it'll mean having lots of build definitions (there's more than just this solution, across multiple project teams), and secondly because it'll effectively mean building the same code repeatedly, just to do different config transforms.
It would be good if this could be done without editing the csproj files, although if that's the only solution then so be it.
Can anyone help me?

I would recommend you to use a release tool to manage your releases.
TFS has a release tool named as Release Management, it can continuously deploys your app to a specific environment for each separate stage: development, test, staging, and production. Refer to this link for details: https://msdn.microsoft.com/en-us/library/dn593700(v=vs.120).aspx

Related

Visual Studio project with a custom build step only (no default build)

I want to create a Visual Studio project that would allow me to see a bunch of JavaScript and other files and edit them as normal, but would also have a build step that can run any custom commands I want (currently some npm commands, possibly more later). Basically I want 3 features combined:
Be able to browse and edit files just like for any VS project (C#, C++, etc.)
Be able to run a custom build step by selecting "Build" in Visual Studio (including building the whole solution).
Be able to run that same custom build step from the command line (MSBuild).
Using a "shared project" (.shproj) allows me to easily see and edit the files, but there is no Build item in the context menu, even if I manually add a Build target:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="Globals">
<ProjectGuid>...</ProjectGuid>
</PropertyGroup>
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.Common.Default.props" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.Common.props" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.CSharp.targets" />
<Import Project="MyItems.projitems" Label="Shared" />
<PropertyGroup>
<Configuration>Debug</Configuration>
<Platform>Any CPU</Platform>
</PropertyGroup>
<Target Name="Build">
<Exec Command="ECHO My custom build!" />
</Target>
</Project>
I've also tried using a stripped-down VC++ project (since I don't actually want to run the C++ compiler) and this allows a build to be run from VS, but opening the project logs warnings like error MSB4057: The target "GetProjectDirectories" does not exist in the project. and trying to add files to fails with that error or similar ones.
There must be an easier way to do this!
From your current description, I think you want to create a js project in VS IDE.
However, VS IDE has the node js project template by default. And you should install the workload Node.js development under VS_Installer so that you can use it.
After that, you can create such project.
1) Adding js files or other files by right-click on the project-->Add-->Existing Item so that you can modify the files on VS IDE.
2) If you want to execute a custom build step that does not break the whole build, you should make the custom target depends on the default build.
You can use this:
<Target Name="CustomStep" AfterTargets="Build">
<Exec Command="ECHO My custom build!" />
</Target>
or
<Target Name="CustomStep" BeforeTargets="Build">
<Exec Command="ECHO My custom build!" />
</Target>
Note: If you use
<Target Name="Build">
<Exec Command="ECHO My custom build!" />
</Target>
It will overwrite the system build process and instead, run the command, which breaks the whole default build.
3) If you want to execute the custom build on msbuild command, you should specify the name of the custom target:
msbuild xxx\xxx.proj -t: CustomStep(the name of the custom target)
===============================================
Besides, if you still want to use C++ project template, you could create a empty c++ project which does not contain any clcompile files and then do the same steps.
If you do not want to use C++ compiler, you should only remove any xml node on the vcxproj file like these:
<ClCompile Include="xxx.cpp" />
<ClInclude Include="xxx.h" />
When you use the empty C++ project, you do not have to worry about that.
=========================================
Update 1
If you want to build this project on a build sever without VS IDE, I suggest you could install Build Tool for VS2019 which is an independent, lightweight build command line(It is equivalent to dotnet cli).
Build Tool for VS2019
Under All Downloads-->Tools for Visual Studio 2019--> Build Tools for Visual Studio 2019
Then, you have to install the related build workload such as Node.js Build tools and then we can use the command line to build node.js project on build sever.
The entire installation process is fast.
Inspired by Perry Qian-MSFT's answer, I managed to strip down a Node.js project to the bare minimum that I needed to get Visual Studio to load and build it, but without referencing any external files.
The main trick was VS needs a target named "CoreCompile" to be defined to show the Build menu item! (It also needs a "Build" target, but that one is more obvious.)
My project now looks like this:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>(some guid)</ProjectGuid>
<ProjectHome>.</ProjectHome>
<ProjectTypeGuids>{3AF33F2E-1136-4D97-BBB7-1795711AC8B8};{9092AA53-FB77-4645-B42D-1CCCA6BD08BD}</ProjectTypeGuids>
</PropertyGroup>
<!-- These property groups can be empty, but need to be defined for VS -->
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
</PropertyGroup>
<Import Project="My.Build.targets" />
<!-- Define empty standard MSBuild targets, since this project doesn't have them. Doing it this way allows My.Build.targets to also be used in a project that does define them. -->
<Target Name="Build" />
<Target Name="ReBuild" />
<Target Name="Clean" />
<!-- NOTE: a target named "CoreCompile" is needed for VS to display the Build menu item. -->
<Target Name="CoreCompile" />
<!-- Files shown in Visual Studio - adding and removing these in the UI works as expected -->
<ItemGroup>
<Content Include="myfile..." />
</ItemGroup>
</Project>
And My.Build.targets looks like this:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="MyBuild" AfterTargets="Build">(build steps)</Target>
<Target Name="MyReBuild" AfterTargets="ReBuild">(re-build steps)</Target>
<Target Name="MyClean" AfterTargets="Clean">(clean steps)</Target>
<!-- This target is needed just to suppress "warning NU1503: Skipping restore for project '...'. The project file may be invalid or missing targets
required for restore." -->
<Target Name="_IsProjectRestoreSupported" Returns="#(_ValidProjectsForRestore)">
<ItemGroup>
<_ValidProjectsForRestore Include="$(MSBuildProjectFullPath)" />
</ItemGroup>
</Target>
</Project>

Publish to Azure doesn't update files in App_Data

My ASP.Net Core app has an App_Data folder located under the project root:
(As I recall -- I may be mistaken -- I had to manually create that folder in the project. The template didn't give it to me automatically.)
My problem is that changes to the files in the App_Data folder are not pushed to Azure when I publish my project. I'm using VS Pro 2019.
When I first published the project, the App_Data folder and its contents were pushed to Azure. But, as I said, changes are ignored.
Here's the larger issue that I don't understand: Apparently, the App_Data folder is special. At least, it's got an entry in the publish profile. And I've seen lots of questions and uninformed answers about difficulties publishing (or not publishing) files that live in this magic folder. But I've never seen anything close to official documentation that talks about this bit of magic.
Here is my publish profile:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>MSDeploy</WebPublishMethod>
<ResourceId>/subscriptions/xxx/resourceGroups/Production/providers/Microsoft.Web/sites/xxx</ResourceId>
<ResourceGroup>Production</ResourceGroup>
<PublishProvider>AzureWebSite</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish>http://xxx.azurewebsites.net</SiteUrlToLaunchAfterPublish>
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<ProjectGuid>xxx</ProjectGuid>
<MSDeployServiceURL>xxx.scm.azurewebsites.net:443</MSDeployServiceURL>
<DeployIisAppPath>xxx</DeployIisAppPath>
<RemoteSitePhysicalPath />
<SkipExtraFilesOnServer>True</SkipExtraFilesOnServer>
<MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
<EnableMSDeployBackup>True</EnableMSDeployBackup>
<UserName>$xxx</UserName>
<_SavePWD>True</_SavePWD>
<_DestinationType>AzureWebSite</_DestinationType>
<InstallAspNetCoreSiteExtension>False</InstallAspNetCoreSiteExtension>
<TargetFramework>netcoreapp2.2</TargetFramework>
<SelfContained>false</SelfContained>
<_IsPortable>true</_IsPortable>
</PropertyGroup>
</Project>
and here is my project file (edited for brevity):
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<UserSecretsId>aspnet-xxx</UserSecretsId>
<ApplicationInsightsResourceId>/subscriptions/xxx/resourcegroups/xxx/providers/microsoft.insights/components/xxx</ApplicationInsightsResourceId>
<ApplicationInsightsAnnotationResourceId>/subscriptions/xxx/resourcegroups/MyIndigoHealth/providers/microsoft.insights/components/xxx</ApplicationInsightsAnnotationResourceId>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
<TypeScriptToolsVersion>3.1</TypeScriptToolsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.1" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.3" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.3">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.2.3" PrivateAssets="All" />
<PackageReference Include="Neleus.DependencyInjection.Extensions" Version="1.0.0" />
</ItemGroup>
<ItemGroup>
<Folder Include="Areas\Identity\Services\" />
</ItemGroup>
<ItemGroup>
<WCFMetadata Include="Connected Services" />
</ItemGroup>
</Project>
According to the official documentation:
The Content item list contains files that are published in addition to
the build outputs. By default, files matching the pattern wwwroot/**
are included in the Content item.
The implication (not clearly stated) is that ONLY build outputs and wwwroot/** are published.
Later in the same documentation, they give examples (without explanation) of markup that adds additional files to the set of files being published. Based on those examples, I cooked up this markup. Adding this to the project (csproj) file causes changed files in the App_Data folder to be published:
<ItemGroup>
<DotnetPublishFiles Include="App_Data/**/*">
<DestinationRelativePath>App_Data/%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</DotnetPublishFiles>
</ItemGroup>
This still leaves a couple of related mysteries:
What does the <ExcludeApp_Data> element really do?
Apparently, the initial Publish (from Visual Studio) pushes the App_Data folder to the server. Why does this happen, when experimentation and the above-referenced documentation says that subsequent attempts to publish ignore the App_Data folder (and, indeed, any folder outside of wwwroot)?
If you right click your web project and select Publish > Settings > File Publish Options, then uncheck "Exclude files from the App_Data folder" what happens?

Publish Azure appservice with auto-hotswap gives ERROR_SITE_SWAP_OPERATION_IN_PROGRESS error

I'm trying to publish an AppService using hot-swap with auto-swap enabled. I can do it without any issues via Visual Studio but not with CI which uses publishing progile and unable to finish publish with the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4276,5):
msdeploy error ERROR_SITE_SWAP_OPERATION_IN_PROGRESS: Web deployment
task failed. (A site swap operation is currently in progress. Learn
more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_SITE_SWAP_OPERATION_IN_PROGRESS.)
Even though I'm getting the error, publishing and auto-swap operations are performed without issues. The Error, however, prevents my CI job from finishing.
My publishing profile:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>MSDeploy</WebPublishMethod>
<ADUsesOwinOrOpenIdConnect>False</ADUsesOwinOrOpenIdConnect>
<PublishProvider>AzureWebSite</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish>https://my-cool-site-swap.azurewebsites.net</SiteUrlToLaunchAfterPublish>
<LaunchSiteAfterPublish>False</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<MSDeployServiceURL>my-cool-site-swap.scm.azurewebsites.net:443</MSDeployServiceURL>
<DeployIisAppPath>my-cool-site-swap</DeployIisAppPath>
<RemoteSitePhysicalPath />
<SkipExtraFilesOnServer>True</SkipExtraFilesOnServer>
<MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
<EnableMSDeployBackup>True</EnableMSDeployBackup>
<UserName>$my-cool-site__swap</UserName>
<Password>...password...</Password>
<AllowUntrustedCertificate>True</AllowUntrustedCertificate>
<_SavePWD>True</_SavePWD>
<_DestinationType>AzureWebSite</_DestinationType>
</PropertyGroup>
</Project>
And the CI command to start it:
C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe"
/p:Configuration=Release "/p:Platform=Any CPU" /p:DeployOnBuild=true
/p:PublishProfile=my-cool-profile
UPDATE:
I've discovered that website binaries are pushed correctly while webjobs libraries are outdated and not pushed with this any deployments. It seems that auto-swap is initiated earlier than msdeploy pushes webjobs part of binaries, that is why I have outdates webjobs and publication error.
What could be wrong with the publishing profile or the way I execute it?

Shared Publish Profiles with User Specific variables

We have a complex visual studio publish profile for developers to deploy files. I want developers to all to use the same publish profile whilst have some variables configurable for each individual user that don't get checked in to source control. Is this possible? If so then how?
<?xml version="1.0" encoding="utf-8"?>
<!--
This file is used by the publish/package process of your Web project. You can customize the behavior of this process
by editing this MSBuild file. In order to learn more about this please visit https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<PublishProvider>FileSystem</PublishProvider>
<LastUsedBuildConfiguration>Debug</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<DeleteExistingFiles>False</DeleteExistingFiles>
<PipelineDependsOn>
CopyAssets;
$(PipelineDependsOn);
</PipelineDependsOn>
<publishUrl>C:\inetpub\wwwroot\local.MyApp\Website</publishUrl>
</PropertyGroup>
<Target Name="CopyAssets">
<Message Text="Inside of CopyAssets" Importance="high"/>
<Exec Command="%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe -File "$(SolutionDir)Foundation\Scripts\Powershell\CopyAssets.ps1" $(SolutionDir) $(publishUrl)"/>
</Target>
</Project>
This is it in its simplest form. In this example I'd want developers to configure for example publish URL on a per user basis ideally in the .user file if possible or get a variable or parameter from somewhere we can pass into this publish profile.
I resolved this by creating a .wpp.targets file. I created one within the project I am publishing. This allowed me to define the Powershell I am running to run for all publish profiles.
This enabled me to allow developers to define their own publish profiles and still run the script allowing the publish URL value to be individual for each developer.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<PipelineDependsOn>
CopyAssets;
$(PipelineDependsOn);
</PipelineDependsOn>
</PropertyGroup>
<Target Name="CopyAssets">
<Message Text="Inside of CopyAssets" Importance="high"/>
<Exec Command="%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe -File "$(SolutionDir)Foundation\Scripts\Powershell\CopyAssets.ps1" $(SolutionDir) $(publishUrl)"/>
</Target>
</Project>
I removed the PipelineDepndsOn part from my publish profile and did it in the target file as I defined above.

MSBuild projects with different build-configs, without using sln

Related
I have two projects in my VS solution, BookApp.Web and BookApp.Domain.
BookApp.Web references BookApp.Domain.
BookApp.Web has the following build configurations: debug, staging, prod-eu, prod-us and prod-as. We have three datacenters for production and a staging environment.
BookApp.Domain so far only has two build configurations, debug.
When building the solution from within Visual Studio, I can use the build configurator to make sure that no matter what build config is selected for the Web project, the debug config is always used for the Domain project.
However, when building with MSBuild on my continuous integration server, things go wrong. I use this in my rollout.msbuild file:
<MSBuild Projects="BookApp.Web\BookApp.Web.csproj" Properties="Configuration=Prod-us" />
When I run this, MSBuild expects all dependent projects to have the same build configuration. Since that's not the case (and shouldn't be IMO), it fails with this error message:
The OutputPath property is not set for project 'BookApp.Domain.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Prod-us' Platform='AnyCPU'.
An answer to a related question suggests creating separate .sln solutions for each build configuration and running that with MSBuild. To me that doesn't sound like a good idea.
Copying all the build configurations to the Domain project is also not ideal.
Is there a better way of telling MSBuild to use different build configs?
Have a look at this answer it explains how the configurations are passed from project to Project through the MSBuild Task and Using the MetaData of the configuration to pass the desired configuration for the target project
here
UPDATE
I created a Solution with a class library(Sample.Domain) and ConsoleApplication(SampleApp.Console). I added two more configurations to the SamplApp.Console: prod-us;prod-eu, Sample.Domain remained with debug;release.
I then Changed the csproj file of the ConsoleApplication, like so:
ProjectReferences
<!--<ItemGroup>
<ProjectReference Include="..\Sample.Domain\Sample.Domain.csproj">
<Project>{73e8a7fd-0a24-47c5-a527-7601550d4b92}</Project>
<Name>Sample.Domain</Name>
</ProjectReference>
</ItemGroup>-->
<ItemGroup>
<ProjectReference Include="..\Sample.Domain\Sample.Domain.csproj" >
<Targets>Build</Targets>
</ProjectReference>
</ItemGroup>
Added a switch case on the configuration passed to MSBuild, to configure some properties for Outputfiles and reference files:
<Choose>
<When Condition="'$(Configuration)' != 'Debug'">
<PropertyGroup>
<OutputProperty>$(OutputPath)\$(Configuration)</OutputProperty>
<FileCopy>$(OutputProperty)</FileCopy>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup>
<OutputProperty>$(OutputPath)</OutputProperty>
<FileCopy>$(OutputProperty)</FileCopy>
</PropertyGroup>
</Otherwise>
</Choose>
Created a Target to switch the Configuration passed to MSBuild, so that Debug will pass Debug to Sample.Domain, everything else it will pass Release
<Target Name="MultiConfiguration" >
<CreateProperty Value="Debug">
<Output TaskParameter="Value" PropertyName="LibConfiguration" Condition="'$(Configuration)' == 'Debug'"/>
</CreateProperty>
<CreateProperty Value="Release">
<Output TaskParameter="Value" PropertyName="LibConfiguration" Condition="'$(Configuration)' != 'Debug' "/>
</CreateProperty>
</Target>
The Build Target uses the Properties we have added so the Output and Copy of references files will have the right values according to Configuration value
<!--Build Process-->
<Target Name="Build" DependsOnTargets="Clean;MultiConfiguration;ComputeProjectReference" >
<Csc Sources="#(Compile)" References="#(NewAssemblies)" TargetType="exe" OutputAssembly="$(OutputProperty)\$(AssemblyName).exe"/>
</Target>
<Target Name="ComputeProjectReference" Inputs="#(ProjectReference)" Outputs="%(ProjectReference.Identity)__Forced">
<MSBuild Projects="#(ProjectReference)" Targets="%(ProjectReference.Targets)" Properties="Configuration=$(LibConfiguration);Platform=AnyCPU;OutputPath=bin\$(LibConfiguration)">
<Output TaskParameter="TargetOutputs" ItemName="ResolvedProjectReferences"/>
</MSBuild>
</Target>
<Target Name="AfterProjectReference" AfterTargets="ComputeProjectReference">
<CreateItem Include="#(ResolvedProjectReferences)">
<Output TaskParameter="Include" ItemName="CopyFiles" />
</CreateItem>
<Copy SourceFiles="#(CopyFiles)" DestinationFolder="$(FileCopy)" SkipUnchangedFiles="false" />
<ItemGroup>
<NewAssemblies Include="$(OutputProperty)\%(CopyFiles.FileName)%(CopyFiles.Extension)" />
</ItemGroup>
</Target>
To call the Debug configuration is done like this
msbuild SampleApp.Console.csproj
To call (Release;prod-us;prod-eu;...) is done like this
msbuild SampleApp.Console.csproj /p:Configuration="prod-us" /p:OutputPath="bin"
I'm sure it can be optimized, and might be some way easier, but it works.

Resources