Integrating XBAP into ASP.NET web application, continuous integration server and release process

Question

Greetings, I'm after advice from those who have implemented an WPF Web Based Application or XAML Browser Application (XBAP) which requires full trust, into a continuous integration server such as CruiseControl.NET, as well as their normal build/release process.

Specifically, I'm interested in:

1. Best practice for signing an XBAP project which requires full trust.
   Are PFX files the way to go, or is this a better approach when using a CI server?
   (We hit this problem yesterday).

2. Best practice for publishing an XBAP project into an ASP.NET web application.
   2.1 Should this be automated on "Release" configuration builds?
   2.2 Should the published output go into the Bin directory?
   2.3 Should we avoid .deploy file extensions and reuse existing assemblies if possible?
   (there are many class libraries already used in the ASP.NET web app project)

3. Best practice deploying XBAP requiring full trust for use from an ASP.NET web application.

4. Best practice for versioning XBAP project.
   Should we use the same version as the rest of our assemblies in the ASP.NET web app project?

Background info:

• The XBAP project is for designing reports for use in our ASP.NET web app. It's an integrated part of the product.
• After compiling XBAP and web application projects, we use a web deployment project and the output of that is then used by our Wix projects to build MSI installers.
• We use CruiseControl.NET for CI, Subversion for RCS, MSBuild to glue everything together, and the whole build/release process is automated, and needs to stay that way.

Any advice appreciated!

Answer 1

Here's what we've found so far. Of course it's not 'best practice' but it's a start:

Best practice for signing an XBAP project which requires full trust.

PFX is working fine once I figured out how to solve the issue with the CI server running as a service.

Best practice for publishing an XBAP project into an ASP.NET web application.
2.1 Should this be automated on "Release" configuration builds?
2.2 Should the published output go into the Bin directory?
2.3 Should we avoid .deploy file extensions and reuse existing assemblies if possible?

Copying to Bin caused problems with the RequestFilteringModule in IIS7 so we didn't use it.

Instead of publishing, in the AfterBuild target we copy the output into a directory in our ASP.NET web app, which is ignored by Subversion, but not by the web deploy or wix project. So we copy what we need (dll,exe,manifest,xbap) and then use some MSBuild magic to rename to .deploy extensions, because some clients might block .exe or .dll downloads:

<Target Name="AfterBuild">
  <CallTarget Targets="CopyOutputToDeployWebDir" />
</Target>

<Target Name="CopyOutputToDeployWebDir">
  <CreateProperty Value="..\Path\To\Application\Dir">
    <Output TaskParameter="Value" PropertyName="DeployWebDir" />
  </CreateProperty>
  <RemoveDir Directories="$(DeployWebDir)" />
  <MakeDir Directories="$(DeployWebDir)" />
  <ItemGroup>
    <DeployWebFiles  Include="$(OutputPath)*.dll;$(OutputPath)*.exe;$(OutputPath)*.manifest;$(OutputPath)*.xbap" />
   </ItemGroup>
   <Copy SourceFiles="@(DeployWebFiles)" DestinationFolder="$(DeployWebDir)" />
   <ItemGroup>
     <RenameFiles Include="$(DeployWebDir)*.dll;$(DeployWebDir)*.exe" />
   </ItemGroup>
   <Move SourceFiles="@(RenameFiles)" DestinationFiles="%(RenameFiles.FullPath).deploy" />
</Target>

Best practice deploying XBAP requiring full trust for use from an ASP.NET web application.

At the moment it looks like we need to install signed key in both the Trusted Root Certificate Store and Trusted Publishers Certificate Store.

Best practice for versioning XBAP project.

We want the same XBAP application version as our ASP.NET web application version (in our case, AssemblyFileVersion attribute), so we ended by-passing the normal ApplicationVersion property approach, overwriting it from our shared AssemblyInfo file which is used by all assemblies in the product:

<!-- Note that this value is overridden in BeforeBuild target -->
<ApplicationVersion>0.0.0.0</ApplicationVersion>
<!-- ... -->
<Target Name="BeforeBuild">
  <CallTarget Targets="SetApplicationVersion" />
</Target>
<!-- Always set application version to product version -->
<Target Name="SetApplicationVersion">
  <UpdateVersion Attribute="AssemblyFileVersion" AssemblyInfo="..\ProductAssemblyInfo.cs">
    <Output PropertyName="ApplicationVersion" TaskParameter="Version" />
  </UpdateVersion>
</Target>

UpdateVersion is a custom MSBuild task that can read or write version attribute values in an AssemblyInfo file. It's not hard to write or find something on the web to do a similar thing.