I would start by verifying that you have your WPF application signed as such:
As you can see my application is signed with my custom certificate that will expire in 100 years.
You would then, as you have stated, need to install the certificate into each user's certificate store under the Trusted Publishers and Trusted Root Certification Authorities. This allows the users system to authenticate that they have permission to access the application.
Here's what we've found so far. Of course it's not 'best practice' but it's a start:
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.
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>
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.
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.
Best Answer
I have worked in a similar situation of using ClickOnce as the engine to deploy the binaries as XBAP as well as standard WPF. To install the XBAP website at a customer site, we would have an installer create the virtual directory in IIS and then run a custom step to sign the ClickOnce manifests. This step was necessary as the application needed to access a generated configuration file that contained information about the customer environment.
Here are some notes on issues that I've seen with using XBAP.