I have a solution with multiple projects. I am trying to use MSBUILD to automate the deployment. I have following configuration values for building
1. Debug
2. Release
3. Dev
For Some projects, I am using Release mode for DEV configuration. But while using DEV as configuration in MSBUILD command, it is throwing exception saying DEV configuration was not found.
Is there any way we can tell MSBUILD to use Release mode if DEV is not available for a project when DEV is used as configuration in MSBUILD?
Thanks
Ashwani
In your (presumably C#) project file, there is typically a line that looks like this:
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
For the projects that don't have a "Dev" configuration, you can get the behavior you want by adding another line, right before that one...
<Configuration Condition=" '$(Configuration)' == 'Dev' ">Release</Configuration>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
This way, when you build with "Dev" specified, these projects will build their Release configuration instead, which mimics the behavior of the solution's configuration manager (which I tend to think of as an abomination of a feature) directly in the project file itself, which is the right place to do it.
Another approach is to use the AdditionalProperties metadata on the item array you would be passing to the MSBuild task to get your projects built. You can specify--for the projects of interest--the following...
<SolutionItem Include="./PathTo/SomeProject.csproj">
<AdditionalProperties Condition="'$(Configuration)' == 'Dev'"
>Configuration=Release</AdditionalProperties>
</SolutionItem>
(Excerpted from the book "MSBuild Trickery" trick #80)
I don't think it can be done with a command argument to MSBuild.
What you could do is use the Configuration Manager for Visual Studio and for the solution configuration 'Dev' point the projects which don't have the 'Dev' configuration to Release.
Then you do a solution build for Dev configuration and some projects will build in release.
Related
This may be a noobish question but here I go anyway.
So in VS I have a project whose build configuration I changed from Debug|AnyCpu to Release|AnyCpu.
Now this all works good and fine and when I build the project via VS this configuration is also used in the build process.
however I am also using the msbuild.exe in order to build the project via command sometimes and the problem is no matter what I do I can not change the
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
element of the project via VS. So setting the build configuration does only seem to work for VS and I bascially have to manually add this in the project file so that the msbuild.exe uses the correct build configuration.
Any Idea how I can change it in VS so the change also alters the project file ?
You don't need to change it explicitly. This string is "default configuration" for msbuild and VS - if no $(Configuration) value specified - set it to Debug.
If you want to build release configuration using msbuild you may want to specify configuration property or platform architecture in command line explicitly:
msbuild.exe myProject.csproj /p:Configuration="Release" /p:Platform="Any CPU"
I have a post build task that I run on my MVC 3 project, 'jake build', that combines a bunch of coffee script files and runs some tests using Phantom.js.
I don't expect appharbor to run this when I deploy, but it is trying to. It is of course failing because node, jake, and any number of other node modules are not installed. Is there a way to have this post build process run on my local machine when I build but have appharbor ignore it?
I figured this out using this questions: How to run Visual Studio post-build events for debug build only
You can do this in the ide:
if $(ConfigurationName) == Debug jake build
or this in the source of your project file:
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<PostBuildEvent>start gpedit</PostBuildEvent>
</PropertyGroup>
I know this is somehow possible, as we have a project that contains MSTest unit tests that are runnable via the VS2010 test runner. We can even add new test methods or classes to the existing projects, and the runner will pick them up and include them in the test run.
The problem comes when I try to add a new unit test project to the solution. If I add a project of the type "test project" to the solution, VS2010 will generate the test metadata and settings files that were not needed for running any of the other tests in the other projects. This is undesirable, for example, for an OSS project. If I simply add a normal "class library" project, and put unit tests in it, the test runner ignores them, and I cannot get it to recognize them at all.
Am I crazy? Is this a fluke? Should it even be possible for VS2010 to run the tests we have, without having a .vsmdi file or a .testsettings file? Or am I missing a setting or configuration that's required in order to make this work for new projects?
You can indeed run tests within VS without having the .vsmdi and .testsettings files (infact, you can just delete them after adding the test project)
So why doesnt it work with a normal class library? the awnser lies inside the .csproj file.
This is a regular class library:
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>8.0.30703</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{F191EC72-AFDF-49CE-A918-01905E7C32EF}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>test</RootNamespace>
<AssemblyName>test</AssemblyName>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
</PropertyGroup>
And this is a test project:
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>8.0.30703</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{F191EC72-AFDF-49CE-A918-01905E7C32EF}</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>test</RootNamespace>
<AssemblyName>test</AssemblyName>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
</PropertyGroup>
That last element, ProjectTypeGuids is what tells VS that its a project that you can run MSTest tests on. these guids are always the same as far as i know, [at least given the same version of VS] so you should be able to paste that line into any .csproj file and have VS recognize the tests inside.
The test settings file can be useful to specify options for deployment (and alot of other things) but most of the options can also be specified at the command line to mstest.exe
The .vsmdi can also be replaced by adding attributes to your test methods. most if not all options available in the Properties for a test can be set as attributes as well as in the vsmdi file. i generally prefer the attributes as they are 'closer' to the code.
I migrated a Web Site project (with Web Deployment project) from VS2008 to VS2010. Now I can make "Build Deployment Package" for Web Deployment Project in VS2010 and it works great! But I can't find a way how to do the same via MSBuild.
I answer on my one question. So after a lot of googling and 2 days of investigation it finally works.
Brief how to:
I created Configuration = QA (based on Debug configuration) for Solution via Configuration Manager.
Important: I removed 'Platform' parameter for QA Configuration. I couldn't build package until I did it. (My dev computer is Win7-x64, and I'm not not sure would be this step necessary for x86. But my build server Win2008-x86 forks fine with this modification.) This is QA Configuration section from my .wdproj
<PropertyGroup Condition=" '$(Configuration)' == 'QA' ">
<DebugSymbols>True</DebugSymbols>
<OutputPath>QA\</OutputPath>
<EnableUpdateable>true</EnableUpdateable>
<UseMerge>true</UseMerge>
<SingleAssemblyName>
</SingleAssemblyName>
<UseWebConfigReplacement>false</UseWebConfigReplacement>
<DeleteAppDataFolder>true</DeleteAppDataFolder>
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
<ExcludeApp_Data>true</ExcludeApp_Data>
</PropertyGroup>
I build and package .wbproj file with the following command:
msbuild WebSite.Deploy.wdproj /t:Build;Package /p:Configuration=QA
For information: If you need you can use standard Web Publishing parameters (e.g. ExcludeApp_Data, DeployIisAppPath etc.) in the QA configuration section.
Try
MSBuild YourProject.csproj /T:Package
That should generate a deployment package. This page, How to: Use MSBuild to Create a Web Package might give a bit more information, but not much.
I'm using the config file replacement feature of Visual Studio 2010's "Publish" functionality, as described in this article. I want to automate this using MSBuild/Hudson. Does anybody know how to do this?
I like how it works but if I cannot automate it I'll have to switch to XmlMassUpdate or similar.
Explanation
To transform your config file you'll have to execute the TransformWebConfig target.
This target takes two files Web.config and Web.$(Configuration).config and generates a Web.config. The generated file is the transformed version of the original one for the current configuration.
This file is generated in folder : obj\$(Configuration)\TransformWebConfig
Usage
You don't really explain what you want to achieve, so here a basic usage, a job that generates a transformed config file in a given folder.
Add the following piece in the end of your project file *.csproj after the import of Microsoft.WebApplication.targets
<PropertyGroup>
<!-- Directory where your web.config will be copied -->
<TransformedWebConfigDestination>$(MSBuildProjectDirectory)</TransformedWebConfigDestination>
</PropertyGroup>
<!--
This target transforms the web.config based on current configuration and
put the transformed files in $(TransformedWebConfigDestination) folder
-->
<Target Name="ConfigSubstitution">
<CallTarget Targets="TransformWebConfig"/>
<ItemGroup>
<TransformedWebConfig Include="obj\$(Configuration)\TransformWebConfig\Web.config"/>
</ItemGroup>
<!-- Copy the transformed web.config to the configured destination -->
<Copy SourceFiles="#(TransformedWebConfig)"
DestinationFolder="$(TransformedWebConfigDestination)"/>
</Target>
In Hudson you could add a Build step in your build, or create a dedicated job configured as follow:
MsBuild Build File : Your csproj file.
Command Line Arguments : /t:ConfigSubstitution /p:Platform=AnyCpu;Configuration=Test;TransformedWebConfigDestination=DestinationFolder
Edit your web project.csproj
under
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
Add -
<UseMsDeployExe>True</UseMsDeployExe>
Look at the Build output (make sure VS Tools - Options - Project & Solutions -Build & Run - MSBuild Output Verbosity - Detailed)
You should be able to see the msdeploy commands VS uses to produce the package. It's my understanding that VS actually uses Web Platform Pipeline API's and .target files to actually produce the deploy packages when building using MSBuild, and this command changes to use MsDeploy instead.
This stuff is so in need of documentation, its very frustrating.
I am using this in Hudson to target Release:
/Property:Configuration=Release
The exact settings are:
Build
MSBuild Version: msbuild-4 (configured to point to v4 msbuild)
MsBuild Build File: project_name.sln
Command Line Arguments: /Property:Configuration=Release
You can test this in your project directory by running something similar (as your .NET framework version may differ) to this:
%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\msbuild project.sln /Property:Configuration=Release