Hi,
Someone contacted me regarding some issues he was having with respect to using the Web Deployment Project s and that was the inspiration for this post.
There is an inherent problem with the way that Properties and Items are declared, created, overridden and used. There are a few problems those are:
· PropertyGroup & ItemGroup elements are evaluated before any target executes.
· Items are append only, meaning that you can’t delete items or any reference contained within them.
We will now start by examining this issue. To simplify the issue I won’t use the Web Deployment Project files, or C# project files. But simpler files that let us focus on what is going on. Below is the file that represents the Microsoft.WebDeployment.targets file. This file is called Shared.proj.
<Project
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!--
This represents the Microsoft.WebDeployments.targets file
-->
<PropertyGroup>
<_AspNetCompilerVirtualPath>$(SourceWebVirtualPath)</_AspNetCompilerVirtualPath>
</PropertyGroup>
<ItemGroup>
<_SourceWebPathItem Include="$(SourceWebPhysicalPath)"/>
</ItemGroup>
<Target Name="Build">
<Message Text="Inside build shared.proj"/>
</Target>
<Target Name="PrintValues">
<Message Text="SourceWebVirtualPath: $(SourceWebVirtualPath)"/>
<Message Text="SourceWebPhysicalPath: $(SourceWebPhysicalPath)"/>
<Message Text="_AspNetCompilerVirtualPath: $(_AspNetCompilerVirtualPath)"/>
<Message Text="_SourceWebPathItem: @(_SourceWebPathItem)"/>
</Target>
</Project>
Now let’s see the project file that represents the project that Visual Studio would create for you when you use the Web Deployments Template. My representative file is called Your.proj, it is shown below.
<Project
InitialTargets="PreBuild"
DefaultTargets="PrintValues"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- This represents the .wdproj file -->
<PropertyGroup>
<SourceWebVirtualPath>WebPathItems</SourceWebVirtualPath>
<SourceWebPhysicalPath>WebPathItems</SourceWebPhysicalPath>
</PropertyGroup>
<Target Name="PreBuild">
<Message Text="Changing path to be 'OtherPath' instead of 'WebPathItems'"/>
<CreateProperty Value="OtherPath">
<Output PropertyName="SourceWebVirtualPath" TaskParameter="Value"/>
</CreateProperty>
<CreateProperty Value="OtherPath">
<Output PropertyName="SourceWebPhysicalPath" TaskParameter="Value"/>
</CreateProperty>
</Target>
<Import Project="Shared.proj"/>
</Project>
There are a couple of things to notice here, the first is that we are importing the Shared.proj file with the statement:
<Import Project="Shared.proj"/>
The other is that we are overriding the SourceWebVirtualPath and the SourceWebPhysicalPath values, in the PreBuild event which is on the InitialTargets list. Because of this we know that the PreBuild target will be executed before any target that is not on the InitialTargets list.
Now going back to the Shared.proj file, we can see
<PropertyGroup>
<_AspNetCompilerVirtualPath>$(SourceWebVirtualPath)</_AspNetCompilerVirtualPath>
</PropertyGroup>
<ItemGroup>
<_SourceWebPathItem Include="$(SourceWebPhysicalPath)"/>
</ItemGroup>
So from this we are creating a new property _AspNetCompilerVirtualPath based on the original SourceWebVirtualPath, and and item _SourceWebPathItem based on SourceWebPhysicalPath. These new properties and items are used throughout the Microsoft.WebDeployment.targets file, and is a common practice amongst other .targets files. You’ll find something similar in the Microsoft.Commons.targets files. Now is where the problem arises, these new properties and items that have been declared in the PropertyGroup & ItemGroup, so they will be evaluated and assigned before the PreBuild target executes. Because of this you don’t really have a chance to actually override these values using any logic. The only (until you read further) way you can override them is to use static elements like PropertyGroup and ItemGroup.
You can see this is the case from the output of the PrintValues target below.
Target PreBuild:
Changing path to be 'OtherPath' instead of 'WebPathItems'
Target PrintValues:
SourceWebVirtualPath: OtherPath
SourceWebPhysicalPath: OtherPath
_AspNetCompilerVirtualPath: WebPathItems
_SourceWebPathItem: WebPathItems
Build succeeded.
So how can we fix this? We need to be able to dynamically create properties & items and have them override static items? We can create a wrapper MSBuild file that does the logic to determine the correct values and the use the MSBuild Task. Have a look below at the file Fix.proj.
<Project
InitialTargets="PreBuild"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- This represents the .wdproj file -->
<PropertyGroup>
<SourceWebVirtualPath>WebPathItems</SourceWebVirtualPath>
<SourceWebPhysicalPath>WebPathItems</SourceWebPhysicalPath>
</PropertyGroup>
<Target Name="PreBuild">
<Message Text="Changing path to be 'OtherPath' instead of 'WebPathItems'"/>
<CreateProperty Value="OtherPath">
<Output PropertyName="SourceWebVirtualPath" TaskParameter="Value"/>
</CreateProperty>
<CreateProperty Value="OtherPath">
<Output PropertyName="SourceWebPhysicalPath" TaskParameter="Value"/>
</CreateProperty>
<Message Text="SourceWebVirtualPath: $(SourceWebVirtualPath)"/>
<Message Text="SourceWebPhysicalPath: $(SourceWebPhysicalPath)"/>
</Target>
<Target Name="Build">
<MSBuild Projects="Your.proj"
Properties="SourceWebVirtualPath=$(SourceWebVirtualPath);
SourceWebPhysicalPath=$(SourceWebPhysicalPath)"
Targets="PrintValues"
/>
</Target>
</Project>
Take a look at the highlighted portion, it simply calls MSBuild on the Your.proj fle. Here is the output when executing this file.
Target PreBuild:
Changing path to be 'OtherPath' instead of 'WebPathItems'
SourceWebVirtualPath: OtherPath
SourceWebPhysicalPath: OtherPath
Target Build:
__________________________________________________
Project "C:\Data\Community\msbuild\WebDeploymentIssues\ASPNETix.proj" is building "C:\Data\Community\msbuild\WebDeploymentIssu\Sample\Your.proj" (PrintValues target(s)):
Target PreBuild:
Changing path to be 'OtherPath' instead of 'WebPathItems'
Target PrintValues:
SourceWebVirtualPath: OtherPath
SourceWebPhysicalPath: OtherPath
_AspNetCompilerVirtualPath: OtherPath
_SourceWebPathItem: OtherPath
Build succeeded.
So you can see that all the desired values have been overridden. But having 2 files is really annoying, and in some cases you don’t really have this option. So because of this we need to find a solution that will modify the original file only. And here is that file, it is shown below its called YourFix.proj.
<Project
InitialTargets="PreBuild"
DefaultTargets="PrintValues"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- This represents the .wdproj file -->
<PropertyGroup>
<SourceWebVirtualPath>WebPathItems</SourceWebVirtualPath>
<SourceWebPhysicalPath>WebPathItems</SourceWebPhysicalPath>
</PropertyGroup>
<Target Name="PreBuild">
<Message Text="Changing path to be 'OtherPath' instead of 'WebPathItems'"/>
<CreateProperty Value="OtherPath">
<Output PropertyName="SourceWebVirtualPath" TaskParameter="Value"/>
</CreateProperty>
<CreateProperty Value="OtherPath">
<Output PropertyName="SourceWebPhysicalPath" TaskParameter="Value"/>
</CreateProperty>
</Target>
<PropertyGroup>
<DoingFix>true</DoingFix>
</PropertyGroup>
<Import Project="Shared.proj"/>
<!-- Here we conditionally override the PrintValues -->
<Target Name="PrintValues" Condition="$(DoingFix)=='true'">
<!-- Make a call to this file -->
<MSBuild Projects="$(MSBuildProjectFullPath)"
Properties="DoingFix=false;
SourceWebVirtualPath=$(SourceWebVirtualPath);
SourceWebPhysicalPath=$(SourceWebPhysicalPath)"
Targets="PrintValues"
/>
</Target>
</Project>
In this approach we need to modify the behavior of the PrintValues target so we override it and have it call itself with the correct values. The MSBuild ProjectFullPath is an MSBuild Reserved Property, and it will return the full path of the current project file. The trick here is the conditional override of this target based on the DoingFix value. So we can see that the DoingFix property will default to true, so the PrintValues target will be overridden. But when the file is called back into with DoingFix=false it will not be overridden, and the PrintValues in Shared.proj will be used. In your use this target will most likely be Build. The drawback of the approach is that you’d have to overwrite each target that you are interested in. The other drawback is that it is confusing if you are not paying close attention to what this does. I posted something previously that used a similar technique read it if this interests you http://www.sedodream.com/PermaLink,guid,9c235811-3078-45e7-b122-6a239fb33fc0.aspx.
Here is an outline of the files I have attached:
Shared.proj => Represents a shared file (ie Miscrosoft.WebDeployments.targets)
Your.proj => Represents your extension of the shared.proj file (ie SiteDeployment.wdproj)
Fix.proj => The wrapper that corrects the problems
YourFix.proj => The real solution to this problem.
Sayed Ibrahim Hashimi