Are there good patterns for mapping solution configurations to environments and using MsDeploy for packaging per environment?
Shortest version: Grab this file, and try to change the .msbuild file so that a package is created.
Details
I have a solution with a large number of libraries and an ASP.NET MVC application. I drive the build with an msbuild file that calls the main solution and then does other things. I want to use the new msdeploy packaging to prepare a .zip file for later distribution, but I'm having various difficulties.
My solution has 4 configurations: Local
, Dev
, Test
, and Prod
, which match the environments I want to map to. In that solution, all of the libraries have Debug
and Release
modes like usual. For example, in Local
solution mode, all libraries compile in Debug
mode. Then, the main application has matching environments with the solution, so that I can have Web.Dev.config
and so on, which seems like the natural way to use things.
If I package like this:
<Target Name="BuildWebPackage">
<MSBuild Projects="..\Publisher\Site\Site.vbproj"
Targets="Package"/>
</Target>
I get a problem where the Configuration=Local
is incorrectly mapped down to the library projects that Site.vbproj
references, and it can't compile them.
I see two possible solutions: one I can't get to work right, and the other is extremely ugly.
Attempt 1
I attempt to call the Package
target via the solution (in this example, "Applications" is the solution folder that the Site project is in... I've simplified things down for this post because there are actually multiple applications in the solution.)
<Target Name="BuildWebPackage">
<MSBuild Projects="..\Publisher\Publisher.sln"
Targets="Applications\Site:Package"/>
</Target>
I think this SolutionFolder\ProjectName:Target
syntax is how to do this, because :Clean
runs... however, this throws
error MSB4057: The target "Applications\Site:Package" does not exist in the project.
Attempt 2
Now for the ugly solution: it works if I modify ALL my libraries to have 4 additional configurations for those 4 solution configurations. However, this is ugly and really a bad plan if I want to co-develop a shared library later with a project that has different environments. Also, those environments have nothing to do with the library and only make sense in the context of the top-level applications using the libraries. Tastes bad.
Huh?
I like having the multiple environments in the solution, and the fancy new Web.config replacement stuff, but I don't know how to call the msdeploy Package
task in this situation so I can build the package in TeamCity.
(Note that I probably do NOT want to call the msdeploy command line, because that's used to turn an IIS app into a package. Not what I'm doing here.)
Sample
Again, I've been completely stumped here, so if you want to help experiment, I've put together this sample solution.