| My book on MSBuild and Team Build
|
| My book on MSBuild and Team Build
|
Today I saw a question on StackOverflow asking about the difference between DependsOnTargets and BeforeTargets/AfterTargets. Below is my response.
In my MSBuild Book I have a section based on how to create reusable elements in MSBuild, if you are interested. I'll give some comments here as well though. This content is different from what the book has.
When creating MSBuild files you should be careful to isolate what versus how. To explain that a bit, lets examine how the managed VS projects work out of the box (which is a great model for reusable elements).
When you create a C#/VB project you get a .csproj file, this .csproj file primarily contains Properties and Items. You will not find a single target in that file. These files contains what will get built (along with some settings relating to the build). At the bottom of the project file you will find an import statement. This import bring in How the project is built.
The files which are imported include:
In this case Microsoft.common.targets defines the overall build process for all the managed languages. Then Microsoft.CSharp.targets (or one of the other lang specific .targets file) fills in the blanks of how to invoke the specific language specific tools.
In your answer above you state "I recommend to avoid DependsOnTargets unless it is really really necessary, for instance if two". I disagree with this. Here is my take on DependsOnTargets versus Before/AfterTargets.
Use DependsOnTargets when
Use Before/AfterTargets when
To tease out the difference a bit consider web projects. For web projects there are two workflows that the .csproj/.vbproj take care of: 1. Build 1. Publish
If I want to add a target to the list of targets to be executed before the Build target I can dynamically update the BuildDependsOn property for publish scenarios only. You cannot do this with Before/AfterTargets.
In an ideal world each target would have the following wrt DependsOnTargets.
For example
<MyTargetDependsOn>
$(MyTargetDependsOn);
Target1;
Target2
</MyTargetDependsOn>
Unfortunately many targets do not follow this pattern, so DependsOnTargets is dead in the water for many cases.
When I am authoring MSBuild scripts I always use DependsOnTargets unless there is a solid reason why I should chose to use Before/AfterTargets. I feel that (I have no insight on the real reasons to the design as I wasn't with Microsoft at the time) Before/AfterTargets was really created to allow users to inject targets to be executed before/after a target which they did not own, and the creators did not use the pattern above.
dddd
Comments [0]
|
With the release of VS2012 we have improved the command line publish experience. We’ve also made all the web publish related features available for VS2010 users in the Azure SDK.
The easies way to publish a project from the command line is to create a publish profile in VS and then use that. To create a publish profile in Visual Studio right click on the web project and select Publish. After that it will walk you though creating a publish profile. VS Web publish profile support the following publish methods.
Command line publishing is only supported for Web Deploy, Web Deploy Package, and File System. If you think we should support command line scenarios for other publish methods the best thing to do would be to create a suggestion at aspnet.uservoice.com. If there is enough interest we may work on that support.
Let’s first take a look at how you can publish a simple Web project from the command line. I have created a simple Web Forms project and want to publish that. I’ve created a profile named SayedProfile. In order to publish this project I will execute the following command.
msbuild MyProject.csproj /p:DeployOnBuild=true /p:PublishProfile=<profile-name> /p:Password=<insert-password> /p:VisualStudioVersion=11.0
In this command you can see that I have passed in these properties;
You may not have expected the VisualStudioVersion property here. This is a new property which was introduced with VS 2012. It is related to how VS 2010 and VS 2012 are able to share the same projects. Take a look at my previous blog post at sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx. If you are building the project file, instead of the solution file then you should always set this property.
If you are publishing using the .sln file you can omit the VisualStudioVersion property. That property will be derived from the version of the solution file itself. Note that there is one big difference when publishing using the project or solution file. When you build an individual project the properties you pass in are given to that project alone. When you build from the command line using the solution file, the properties you have specified are passed to all the projects. So if you have multiple web projects in the same solution it would attempt to publish each of the web projects.
FYI in case you haven’t already heard I’m working on an update to my book. More info at msbuildbook.com
Sayed Ibrahim Hashimi | @SayedIHashimi
Comments [0]
|
If you have used the Visual Studio web publish in either VS 2010 or VS 11 to create Web Deploy packages then you probably know that we parameterize connection strings in web.config automatically. In case you are not familiar with Web Deploy parameters, they are a way to declare that you want to easily be able to update a value of something when publishing the package later on. Connection strings are good examples of something which typically needs to be updated during publish.
As I previously stated if you create a Web Deploy package in Visual Studio we will automatically create Web Deploy parameters for all your connection strings in web.config. Earlier today I saw a question on StackOverflow asking how to parameterize connection strings in non-web.config files (question actually asked something else, but I think this is what he’s really wanting). I created a sample showing how to do this. Below is what the connectionStrings element looks like in web.config.
<connectionStrings configSource="connectionStrings.config" />
And here is connectionStrings.config
<?xml version="1.0" encoding="utf-8" ?>
<connectionStrings>
<clear/>
<add name="ApplicationServices"
connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true"
providerName="System.Data.SqlClient" />
<add name="OtherConnectionString"
connectionString="data source=.\SQLExpress;Integrated Security=SSPI;Initial Catalog=foo"
providerName="System.Data.SqlClient"/>
</connectionStrings>
In order to parameterize these connection strings you will have to extend the Web Publish Pipeline. To do that create a file named {project-name}.wpp.targets in the root of the project in which you are working (for VS 11 projects you can place all this directly inside of the .pubxml files). This will be an MSBuild file which will get imported into the build/publish process. Below is the file which needs to be created.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<!-- Here we need to declare MSDeploy parameters for connection strings in connectionStrings.config -->
<MsDeployDeclareParameters Include="ApplicationServices-ConnectionString" >
<Kind>XmlFile</Kind>
<Scope>connectionStrings.config$</Scope>
<Match>/connectionStrings/add[@name='ApplicationServices']/@connectionString</Match>
<Description>Connection string for ApplicationServices</Description>
<DefaultValue>data source=(localhost);Initial Catalog=AppServices</DefaultValue>
<Tags>SqlConnectionString</Tags>
</MsDeployDeclareParameters>
<MsDeployDeclareParameters Include="OtherConnectionString-ConnectionString" >
<Kind>XmlFile</Kind>
<Scope>connectionStrings.config$</Scope>
<Match>/connectionStrings/add[@name='OtherConnectionString']/@connectionString</Match>
<Description>Connection string for OtherConnectionString</Description>
<DefaultValue>data source=(localhost);Initial Catalog=OtherDb</DefaultValue>
<Tags>SqlConnectionString</Tags>
</MsDeployDeclareParameters>
</ItemGroup>
</Project>
Here you can see that I am creating values for MSDeployDeclareParameters. When you package/publish this item list is used to create the MSDeploy parameters. Below is an explanation of the metadata values each contain.
After you create this file you will need to close/re-open VS (it caches imported .targets files). Then you can create a web deploy package. When you do so these new parameters will be declared. In my case I then imported this in the IIS manager and here is the dialog which shows up for the parameters.
As you can see the Application Path parameter is shown there as well as my custom connection string values. When I update the values in the text box and opened connectionStrings.config on my web server they were the values I entered in the dialog box.
FYI I have uploaded this sample to my github account at ParameterizeConStringConfig.
Sayed Ibrahim Hashimi @SayedIHashimi
Comments [0]
|
Today someone sent me an email asking how to call the System.Environment.GetFolderPath method passing in the value of MyDocuments for the value of the folder parameter. I was expecting the below to do the trick.
<Project ToolsVersion="4.0"
DefaultTargets="Demo"
xmlns="schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Tempfile02>$([System.Environment]::GetFolderPath(System.Environment.SpecialFolder.MyDocuments))</Tempfile02>
</PropertyGroup>
<Target Name="Demo">
<Message Text="TempFile01: $(TempFile02)"/>
</Target>
</Project>
To my surprise I was faced with the following error.
Build started 3/20/2011 6:20:36 PM.
Project "C:\temp\_NET\msbuild\PropFunction01.proj" on node 1 (default targets).
C:\temp\_NET\msbuild\PropFunction01.proj(20,5): error MSB4186: Invalid static method invocation syntax: "[System.Environment]::GetFolderPath(System.Environment.Spec ialFolder.MyDocuments)". Requested value 'System.Environment.MyDocuments' was not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(`a`, `b`)).
Done Building Project "C:\temp\_NET\msbuild\PropFunction01.proj" (default targets) -- FAILED.
Build FAILED.
So I sent an email to the MSBuild team asking “WTF why doesn’t this work?!”, and Dan Moseley (a lead dev there) sent me a snippet that worked, its below.
<Project ToolsVersion="4.0" DefaultTargets="Demo" xmlns="schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Tempfile02>$([System.Environment]::GetFolderPath(SpecialFolder.MyDocuments))</Tempfile02>
</PropertyGroup>
<Target Name="Demo">
<Message Text="TempFile01: $(TempFile02)"/>
</Target>
</Project>
In that snippet instead of using the fully qualified class name of System.Environment.SpecialFolder.MyDocuments, for some reason you have to use the shortened name of just SpecialFolder.MyDocuments. It seems like a bug to me, but at least there is a work around!
Sayed Ibrahim Hashimi – @sayedihashimi
Comments [3]
|
One of the really cool features that we shipped for Visual Studio 2010 was web.config (XDT) transformations. Because the transformations are so simple and straightforward one of the first questions that someone asks after using it is “how can I use this in my other projects?” Unfortunately this feature is only built into the Web Application Projects (WAP). But it is very easy to reuse this because we just rely on an MSBuild task to do the heavy lifting for us. I received an email from that basically went like this
“Hi, I would like to use XDT transformations on my WPF project for both the app.config file as well as my unity.xml file. How can I do this?”
So one answer is to modify your project file to use the TransformXml task as I have blogged previously about (link below). But I thought that since this was such a common problem that I should go ahead and create a .targets file which would solve the above problem and could be re-used by anyone.
Let me clarify the scenario a bit before we dive into the details of the solution. I have create a sample Wpf project, named Wpf01. Inside of that project I have created these files:
Take a look at the image below (note: I manually edited the project file to make the file nest under each other, I will explain that shortly)
The files with .debug/.release are transform files. When I build I expect the following to happen:
Before I get into the solution let me explain how to use the solution first because if you are not interested in the MSBuild details you can skip over that
For #5 lets examine the sample that I created. In this sample I had an app.config file. When I first created the project the entry in the project file for app.config looked like the following.
<None Include="app.config" />
So what you need to do is to add a new metadata value as described above for that. So it will turn into the following.
<None Include="app.config"> <TransformOnBuild>true</TransformOnBuild> </None>
The transform targets will look for items that have this value declared on them and then during build it will transform them, if the transform file exists in the same folder as the file itself. You will need to add TransfromOnBuild to all the files that you want to transform. So in my case I added it to app.config, Sample01.xml and Sub01.xml. Note you should not add this to the transform files themselves because you will just waste your own time. After you do this you should perform a build then take a look at the output directory for your transformed files. The app.config should write out the the correct file and the others as expected.
You might have noticed that in the image above that the transform files are nested under the files themselves. To do this you need to add the DependentUpon metadata value to the child items. For instance for app.config the child items look like the following.
<None Include="app.debug.config"> <DependentUpon>app.config</DependentUpon> </None> <None Include="app.release.config"> <DependentUpon>app.config</DependentUpon> </None>
If you are wondering how this works then this is the section for you. TransformFile.targets has 2 targets; DiscoverFilesToTransform and TransformAllFiles. DiscoverFilesToTransform looks through a set of items (None, Content, and Resource). Inside of DiscoverFilesToTransform I look for values with the %(TransformOnBuild)==true. After all of those are collected I identify if there is an app.config file being transformed and if so it is placed into a specific item list and all others go into another item list.
Inside of TransformAllFiles the TransformXml task is used to transform all of the files. This target injects itself into the build process by having the attribute AfterTargets="Build;_CopyAppConfigFile". So whenever the Build or _CopyAppConfigFile targets are called the TransformAllFiles target will execute.
Here if the full code for this file.
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="TransformXml"
AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll"/>
<ItemDefinitionGroup>
<!-- Set the default value to false here -->
<None>
<TransformOnBuild>false</TransformOnBuild>
</None>
<Content>
<TransformOnBuild>false</TransformOnBuild>
</Content>
<Resource>
<TransformOnBuild>false</TransformOnBuild>
</Resource>
<EmbeddedResource>
<TransformOnBuild>false</TransformOnBuild>
</EmbeddedResource>
<_FilesToTransform>
<IsAppConfig>false</IsAppConfig>
</_FilesToTransform>
</ItemDefinitionGroup>
<PropertyGroup>
<TransformAllFilesDependsOn>
DiscoverFilesToTransform;
</TransformAllFilesDependsOn>
</PropertyGroup>
<Target Name="TransformAllFiles" DependsOnTargets="$(TransformAllFilesDependsOn)" AfterTargets="Build;_CopyAppConfigFile">
<!-- Now we have the item list _FilesToTransformNotAppConfig and _AppConfigToTransform item lists -->
<!-- Transform the app.config file -->
<ItemGroup>
<_AppConfigTarget Include="@(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')" />
</ItemGroup>
<PropertyGroup>
<_AppConfigDest>@(_AppConfigTarget->'%(FullPath)')</_AppConfigDest>
</PropertyGroup>
<MakeDir Directories="@(_FilesToTransformNotAppConfig->'$(OutDir)%(RelativeDir)')"
Condition="Exists('%(RelativeDir)%(Filename).$(Configuration)%(Extension)')"/>
<TransformXml Source="@(_AppConfigToTransform->'%(FullPath)')"
Transform="%(RelativeDir)%(Filename).$(Configuration)%(Extension)"
Destination="$(_AppConfigDest)"
Condition=" Exists('%(RelativeDir)%(Filename).$(Configuration)%(Extension)') " />
<TransformXml Source="@(_FilesToTransformNotAppConfig->'%(FullPath)')"
Transform="%(RelativeDir)%(Filename).$(Configuration)%(Extension)"
Destination="@(_FilesToTransformNotAppConfig->'$(OutDir)%(RelativeDir)%(Filename)%(Extension)')"
Condition=" Exists('%(RelativeDir)%(Filename).$(Configuration)%(Extension)') " />
</Target>
<Target Name="DiscoverFilesToTransform">
<!--
This will look through items list: None & Content for those
with Metadata <TransformOnBuild>True</TransformOnBuild>
-->
<ItemGroup>
<_FilesToTransform Include="@(None);@(Content);@(Resource);@(EmbeddedResource)"
Condition=" '%(TransformOnBuild)' == 'true' "/>
</ItemGroup>
<PropertyGroup>
<_AppConfigFullPath>@(AppConfigWithTargetPath->'%(RootDir)%(Directory)%(Filename)%(Extension)')</_AppConfigFullPath>
</PropertyGroup>
<!-- Now look to see if any of these are the app.config file -->
<ItemGroup>
<_FilesToTransform Condition=" '%(FullPath)'=='$(_AppConfigFullPath)' ">
<IsAppConfig>true</IsAppConfig>
</_FilesToTransform>
</ItemGroup>
<ItemGroup>
<_FilesToTransformNotAppConfig Include="@(_FilesToTransform)"
Condition=" '%(IsAppConfig)'!='true'"/>
<_AppConfigToTransform Include="@(_FilesToTransform)"
Condition=" '%(IsAppConfig)'=='true'"/>
</ItemGroup>
</Target>
</Project>
With most things found on blogs there are some gaps Those are described here.
Clean build => It’s a best practice to delete files upon clean, but in this case I am not. This would be pretty easy to add, if you are interested let us know and I will update the sample.
Incremental build => The transforms will run every time you build even if the outputs are up to date, if this is an issue for you let us know and I will update the sample.
If you want to share with team members instead of placing this into %ProgramFiles (x86)% just place it into a folder in version control then change the <Import statement to point to that file instead of using MSBuildExtensionPath.
If you end up using this please let us know what is your experience with it.
Sayed Ibrahim Hashimi @sayedihashimi
Comments [3]
|
Today I just saw a question posted on stackoverflow.com asking Why are some Web.config transforms tokenised into SetParameters.xml and others are not? Let me give some background on this topic for those who are not aware of what the question is.
With Visual Studio 2010 when you package your application using the Build Deployment Package context menu option, see image below.
When build the package by default the package will be created in obj\{Configuration}\Package\{ProjectName}.zip where {Configuration} is the current build configuration, and {ProjectName} is the name of the project. So in this case I since I’m building with Debug and the project name is MvcApplication1 the package will be placed at obj\Debug\Package\MvcApplication1.zip. If you take this package and then import into IIS 7 with the “Import Application” option shown below. Note: The machine must have the Web Deployment Tool (aka MSDeploy) installed.
Once you click on Import Application then browse out to the package you will be shown a screen which prompts your for parameters. Its shown below.
On this screen you can see that we are prompting for a couple parameter values here. One is an IIS setting, Application Path, and the other is a connection string which will be placed inside the web.config file. If your Web Application Project (WAP) had 5 different connection strings then they would automatically show up here on this page. Since connection strings are replaced so often we create parameters for all connection strings by default. You can define new parameters on your own, quite easily actually, but that is the topic for another blog post.
Now back to the question. He is asking why do we “tokenize” the connection strings in web.config. To clarify take a look at my web.config file below.
<configuration>
<appSettings>
<add key="setting01" value="value01"/>
</appSettings>
<connectionStrings>
<add name="ApplicationServices"
connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
providerName="System.Data.SqlClient" />
</connectionStrings>
</configuration>
After I perform a package this will get changed. Take a look @ the web.config file which resides in the package (you can get to the file at obj\{CofigurationName}\Package\PackageTmp\web.config). You will see what is shown below.
<configuration>
<appSettings>
<add key="setting01" value="value01"/>
</appSettings>
<connectionStrings>
<add name="ApplicationServices"
connectionString="$(ReplacableToken_ApplicationServices-Web.config Connection String_0)"
providerName="System.Data.SqlClient" />
</connectionStrings>
</configuration>
So his question is why is the connection string replaced with $(ReplacableToken_ApplicationServices-Web.config Connection String_0) and nothing else is? We do this because we do not want you to accidently copy your web to a location and have it executing SQL statements against a SQL server which you did not intend. The idea is that you will create a package that you can deploy to many different environments. So the value that was in your web.config (or web.debug.config/web.release.config if you are using a web.config transformation) will not be placed inside the web.config in the package. Instead those values will be used as defaults in the package itself. We also create a SetParameters.xml file for you so that you can tweak the values. For my app see the MvcApplication1.SetParameters.xml file below.
<?xml version="1.0" encoding="utf-8"?>
<parameters>
<setParameter name="IIS Web Application Name"
value="Default Web Site/MvcApplication1_deploy" />
<setParameter name="ApplicationServices-Web.config Connection String"
value="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" />
</parameters>
The idea is that you can deploy your package in 2 ways. Through the IIS Manager which will prompt you for the parameters or you can deploy using msdeploy.exe with the –setParamFile switch to specify the path to the SetParameters.xml file. In this case I could create a QA01.SetParameters.xml file along with a QA02.SetParameters.xml file to deploy my web to my two QA servers. How do we do this?
You might be wondering how the connection strings are tokenized to begin with. With Visual Studio 2010 we released web.config transformations, which all you to write terse web.config transformations inside of files like web.debug.config/web.release.config. When you package/publish your web these transform files are used to transform your web.config based on what you expressed in the appropriate transform file. We have an MSBuild task TransformXml which performs the transformation. We use that same task to tokenize the connection strings. If you are interested in the details take a look at %ProgramFiles32%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets in the AutoParameterizationWebConfigConnectionStringsCore target.
Now what if you do not want the connection string tokenized?
If you want to prevent your web.config connection strings from being tokenized it’s pretty easy. All we need to do is the add a property to the build/package/publish process. We can do that in 2 ways. Edit the project file itself or create a file with the name {ProjectName}.wpp.targets where {ProjectName} is the name of your project. The second approach is easier so I use that. In my case it would be MvcApplication1.wpp.targets. The contents of the file are shown below.
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>
</PropertyGroup>
</Project>
Note: You may need to reload the project in Visual Studio for this to take effect.
Inside of this file I have declared the property, AutoParameterizationWebConfigConnectionStrings, to be false. This is telling the Web Publishing Pipeline (WPP) that it should not replace replace the connection strings with tokens, instead leave them as they are.
Questions/Comments???