I wanted to wring my hair on this one… but it was actually rather simple to get solved.  I’m helping a customer this week upgrading their server to TFS 2010 from TFS 2008.  They had TFS 2008 builds compiling & publishing Visual Studio 2008 solutions & builds.  When you upgrade to TFS 2010, those existing build definitions will end up using the UpgradeTemplate.xaml build process template in TFS 2010.  Not a problem there.  This customer was not able to upgrade their solutions & projects immediately to Visual Studio 2010 in tandem with the TFS 2010 upgrade.  That should normally not be a problem but having done a few of these upgrades, I know that I usually need to set out some time just to get the existing builds working again.  There’s always something wrong.   Never huge but enough to irritate you after an upgrade.

We went through a few hurdles to get those solutions & projects compiling and then we moved on to the deployment builds.  They seemed to just work which was great!  In their legacy TFSBuild.proj files, they had an entry in the AfterCompile MSBuild target essentially like this:

            <
            MSBuild Projects="$(SolutionRoot)\Branch\ClickOnceProject.csproj" 
Properties="PublishDir=\\FILESERVER\ClickOncePublishPath\;ApplicationVersion=$(VersionNumber);"
Targets="Publish" />

It was great until we went to go actually fire up the app… CRASH!  It is complaining in the ClickOnce deployment log that the deployment manifest wasn’t semantically valid and that the deployment manifest was missing the <compatibleFrameworks> node.  Here’s the full (redcated) log: (emphasis mine)

PLATFORM VERSION INFO
    Windows             : 6.1.7601.65536 (Win32NT)
    Common Language Runtime     : 4.0.30319.239
    System.Deployment.dll         : 4.0.30319.1 (RTMRel.030319-0100)
    clr.dll             : 4.0.30319.239 (RTMGDR.030319-2300)
    dfdll.dll             : 4.0.30319.1 (RTMRel.030319-0100)
    dfshim.dll             : 4.0.31106.0 (Main.031106-0000)

SOURCES
    Deployment url            : http://webserver/ClickOnceProject.application
                        Server        : Microsoft-IIS/6.0
                        X-Powered-By    : ASP.NET
    Application url            : http://webserver/Application%20Files/ClickOnceProject_1_1_1_1/ClickOnceProject.exe.manifest
                        Server        : Microsoft-IIS/6.0
                        X-Powered-By    : ASP.NET

IDENTITIES
    Deployment Identity        : PolicyManagement.application, Version=1.11.1026.3, Culture=neutral, PublicKeyToken=3801d6f74f2e8cd7, processorArchitecture=x86
    Application Identity        : PolicyManagement.exe, Version=1.11.1026.3, Culture=neutral, PublicKeyToken=3801d6f74f2e8cd7, processorArchitecture=x86, type=win32

APPLICATION SUMMARY
    * Online only application.
    * Trust url parameter is set.
ERROR SUMMARY
    Below is a summary of the errors, details of these errors are listed later in the log.
    * Activation of http://webserver/ClickOnceProject.application  resulted in exception. Following failure messages were detected:
        + Deployment manifest is not semantically valid.
        + Deployment manifest is missing <compatibleFrameworks>.

COMPONENT STORE TRANSACTION FAILURE SUMMARY
    No transaction error was detected.

WARNINGS
    There were no warnings during this operation.

OPERATION PROGRESS STATUS
    * [10/26/2011 1:49:41 PM] : Activation of http://webserver/ClickOnceProject.application has started.
    * [10/26/2011 1:49:42 PM] : Processing of deployment manifest has successfully completed.
    * [10/26/2011 1:49:42 PM] : Installation of the application has started.
    * [10/26/2011 1:49:42 PM] : Processing of application manifest has successfully completed.

ERROR DETAILS
    Following errors were detected during this operation.
    * [10/26/2011 1:49:43 PM] System.Deployment.Application.InvalidDeploymentException (ManifestSemanticValidation)
        - Deployment manifest is not semantically valid.
        - Source: System.Deployment
        - Stack trace:
            at System.Deployment.Application.PlatformDetector.VerifyPlatformDependencies(AssemblyManifest appManifest, AssemblyManifest deployManifest, String tempDir)
            at System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState subState, ActivationDescription actDesc, Int64 transactionId, TempDirectory& downloadTemp)
            at System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState& subState, ActivationDescription actDesc)
            at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl)
            at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
        --- Inner Exception ---
        System.Deployment.Application.InvalidDeploymentException (InvalidManifest)
        - Deployment manifest is missing <compatibleFrameworks>.
        - Source:
        - Stack trace:

COMPONENT STORE TRANSACTION DETAILS
    No transaction information is available.

Now what I remember is that the <compatibleFrameworks> node was actually introduced in the deployment manifests for .NET / ClickOnce 4.0 in Visual Studio 2010 and we shouldn’t be expecting them for Visual Studio 2008 ClickOnce projects.  Sounds like the build process is not picking up the right version.  In the TFS 2010 version of the TeamFoundationBuild.targets file, it handles compilation correctly by setting the appropriate MSBuild tools version number.  Why wasn’t it picking that up for our publish?

Oh yeah… since TFS 2010 build had to specify it for the legacy UpgradeTemplate.xaml and TeamFoundationBuild.targets files, we have to do the same thing.  Duh.  It ended up being an easy fix and we just updated that portion of the legacy TFSBuild.proj build script to explicitly set the MSBuild tools version and pass in the framework version as well for the ClickOnce project.

            <
            MSBuild ToolsVersion="3.5" Projects="$(SolutionRoot)\Branch\ClickOnceProject.csproj"
 Properties="ClrVersion=2.0.50727.0;PublishDir=\\FILESERVER\ClickOncePublishPath\;ApplicationVersion=$(VersionNumber);"
 Targets="Publish" =""/>

BTW – you can do this in the new Windows Workflow-based build process templates as well but instead you would use the MSBuild workflow activity.

However, I would highly suggest upgrading to Visual Studio 2010 when you get a chance since it will handle ClickOnce projects that target .NET 2.0, .NET 3.0, .NET 3.5, and .NET 4.0 seamlessly.

Now that all of the legacy TFS 2008 builds are working in TFS 2010, it’s time to start helping my current customer get their Visual Studio 2008 solutions & projects upgraded to Visual Studio 2010 and leverage the new Windows Workflow-based build process template!

Ed Blankenship

Many thanks to Josh Winfree for helping out with the discover of this one!