Azure SDK 1.8 introduced a change in how CSPack locates virtual applications given the physicalDirectory attribute in the ServiceDefinition.csdef file while packaging an Azure project. This blog shows how to support build and packaging of virtual applications within both Visual Studio and TFS Build using Azure SDK 1.8.
Prior to SDK 1.8 my team used the build and packaging technique given on the kellyhpdx blog. After the SDK upgrade our build started throwing:
Cannot find the physical directory 'C:\...WebApplication1' for virtual path ... (in) ServiceDefinition.csdef
Tweaking the "..\" portion of the physicalDirectory attribute as suggested in other blog articles only worked for local Visual Studio builds but failed on our build server. I'll first cut to the case and show you what is needed then explain what is going on. Refer to the kellyhpdx blog article for background and details of what worked prior to SDK 1.8.
To add a virtual application to an Azure project:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
<!-- Performs publishing prior to the Azure project packaging -->
<Target Name="PublishToFileSystem" DependsOnTargets="PipelinePreDeployCopyAllFilesToOneFolder">
<Error Condition="'$(PublishDestination)'==''" Text="The PublishDestination property is not set." />
<MakeDir Condition="!Exists($(PublishDestination))" Directories="$(PublishDestination)" />
<PublishFiles Include="$(_PackageTempDir)\**\*.*" />
<Copy SourceFiles="@(PublishFiles)" DestinationFiles="@(PublishFiles->'$(PublishDestination)\%(RecursiveDir)%(Filename)%(Extension)')" SkipUnchangedFiles="True" />
<!-- Virtual applications to publish -->
<!-- Manually add PublishToFileSystem target to each virtual application .csproj file -->
<!-- For each virtual application add a VirtualApp item to this ItemGroup:
<VirtualApp Include="Relative path to csproj file">
<PhysicalDirectory>Must match value in ServiceDefinition.csdef</PhysicalDirectory>
<!-- Executes before CSPack so that virtual applications are found -->
Condition="'$(PackageForComputeEmulator)' == 'true' Or '$(IsExecutingPublishTarget)' == 'true' ">
<Message Text="Start - PublishVirtualApplicationsBeforeCSPack" />
<PropertyGroup Condition=" '$(PublishDestinationPath)'=='' and '$(BuildingInsideVisualStudio)'=='true' ">
<!-- When Visual Studio build -->
<PropertyGroup Condition=" '$(PublishDestinationPath)'=='' ">
<!-- When TFS build -->
<Message Text="Publishing '%(VirtualApp.Identity)' to '$(PublishDestinationPath)%(VirtualApp.PhysicalDirectory)'" />
<!-- Delete files excluded from packaging; take care not to delete xml files unless there is a matching dll -->
<Output ItemName="DllFiles" TaskParameter="Include" />
<FilesToDelete Include="@(DllFiles -> '%(RootDir)%(Directory)%(Filename).pdb')" />
<FilesToDelete Include="@(DllFiles -> '%(RootDir)%(Directory)%(Filename).xml')" />
<Message Text="Files excluded from packaging '@(FilesToDelete)'" />
<Delete Files="@(FilesToDelete)" />
<Message Text="End - PublishVirtualApplicationsBeforeCSPack" />
Your Azure solution should now build and package successfully in Visual Studio and on your TFS build server. I verified that this technique works in Visual Studio 2012 with the online Team Foundation Service. It was easy to create a TFS instance at http://tfs.visualstudio.com and perform continuous integration deployments to Azure.
The zip file attached below contains a sample project demonstrating this technique. Download and try it for yourself.
Within your Azure ccproj file you define an ItemGroup of VirtualApp's that you want published and packaged inside the resulting .cspkg file. Define as many VirtualApp items as you need. The sample defines two.
The remainder of the MSBuild code in the ccproj file executes before targets that call CSPack. For each of the VirtualApp's the code launches another instance of MSBuild that executes the PublishToFileSystem target in each respective web project. The code then creates a list of dll filenames which were published and looks for .pdb and .xml files for each of those dll filenames. It then deletes the .pdb and .xml files found.
The code is written so that you can include other .xml files in your web project and just the .xml files corresponding to the dll's get deleted. Other .xml files are published and end up in the .cspkg file as expected.
The PublishToFileSystem target added to the virtual application's csproj file performs a simple recursive copy of the project's build output to the destination specified. Using the _PublishedSites directory isn't a strict requirement but follows the convention used by TFS Build so that the files get copied to the drop folder.
During packaging the physicalDirectory attribute in csdef is with respect to the location of the csdef file being used by CSPack, specifically the file identified by the ResolveServiceDefinition target as the Target Service Definition in the build output. See the definition of the ResolveServiceDefinition target, typically in "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Windows Azure Tools\1.8\ Microsoft.WindowsAzure.targets".
Prior to SDK 1.8 the csdef being used was located in a subfolder within the csx folder under the Azure project and was named ServiceDefinition.build.csdef. The folder name matched the configuration being built, normally either Debug or Release. It is important to note that this caused the physicalDirectory attribute in csdef to be with respect to a folder in the source tree while building locally in Visual Studio and also on the TFS build server. Additionally, the csdef file was not copied to the build output folder.
Azure SDK 1.8 on the other hand copies the csdef file to the build output folder and changed the ResolveServiceDefinition target so that it looks for the file there. While doing a local Visual Studio build the output folder is a subfolder within the bin folder under the Azure project matching the configuration being built, typically Debug or Release. The important point for a local Visual Studio build is that this folder is an equal number of folders down in the source tree when compared to the previous csx subfolder so the SDK 1.8 change should be transparent to most developers.
Unfortunately the build output folder on a TFS build server is very different. A step in the TFS build process needs to copy the build output to a drop folder for archival purposes. To facilitate this the TFS build templates uses two folder, one for the source and another for the build output. The obj and csx folders continue to get created within the source folders but instead of the build output going to the bin folder as is done by Visual Studio, TFS uses a build output folder named Binaries that is at the same, sibling folder level as the Source. The build output folder contents is also slightly different in that there is a _PublishedWebsites folder.
If you want to verify what is packaged, inside the .cspkg file there is a sitesroot folder which contains a folder for each application; 0 is the root site and 1 is the virtual application. You can view the contents by renaming the .cspkg file to .zip then exporting it and renaming the .cssx file to .zip. The sitesroot folder is within the renamed .cssx file. The MSBuild code above results in the virtual application containing the files for the published site except that the pdb and xml files associated with dll's are deleted.
This is very helpful. Thank you for sharing the explanation and the code sample.
How are you today i hope you are fine?
My name is kama sambo,i saw your profile today and i love it,i think we can build a good relationship/friend from there. Dear please write me back through my email address so that i can send you my photos and for more discussion (firstname.lastname@example.org)
I am waiting for your reply soon
My dear please contact me with this email (email@example.com)
Excellent explanation, encountered the same issue when building on TFS or using local outdir and having multiple roles in the solution.
Actually I think my error is caused by the change in SDK but slightly different:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Windows Azure Tools\2.0\Microsoft.WindowsAzure.targets (632): The role 'MyRole' was not found in the service definition. Parameter name: roleName
I have several roles (web project and worker roles) defined in solution and I get the error above when building solution either in TFS or locally using outDir property. I think ServiceDefinition file is overridden somehow. Do you have any clues on how to resolve this?
Thanks, this article helped out a lot and I have TFS build working for both sites in a single role.
It seems as though my web.config transforms are not compiling. Do you know how to get web transforms working in this process?
Thank you, this is exactly what I was looking for, the example and explanation are very clear.
This works like a charm!
But there is a mismatch in terms on this page. Somewhere it has _PublishedSites and another instance it has _PublishedWebsites. Whatever term you use, it should be the same.
I did not try the zip package.
CORRECTION to my comment above.
Just change item 5:
Thank you so much. This article helped me a lot..
Do you know if this process is any different for the VNext Build system?