Click Once Deployment with WPF Composite AB

Sep 14, 2009 at 12:31 PM
Edited Sep 14, 2009 at 2:20 PM

Hello, I’m just wondering whether there is any easy way to use Click Once Deployment for WPF Applications built using the lastly published WPF Composite Application block. The issue I’m facing is that the main exe assembly is by reference NOT dependent on the modules (rather by configuration), so Click Once will not add the modules to the deployment package. The Manifest Manager Utility looked like a good problem resolution however editing the applicatio manifest (providing additional assemblies) I got this error (which seems to be a common problem lot of people complining about)

ERROR SUMMARY
 Below is a summary of the errors, details of these errors are listed later in the log.
 * Activation of http://mydomain/ClickOnceComposite/ConfigurationModularity.application resulted in exception. Following failure messages were detected:
  + Exception reading manifest from http://mydomain/ClickOnceComposite/Application Files/ConfigurationModularity_1_0_0_0/ConfigurationModularity.exe.manifest: the manifest may not be valid or the file could not be opened.
  + Parsing and DOM creation of the manifest resulted in error. Following parsing errors were noticed:

+ Parsing and DOM creation of the manifest resulted in error. Following parsing errors were noticed:
   -HRESULT:  0x80070c81
    Start line:  0
    Start column:  0
    Host file:  
  + Exception from HRESULT: 0x80070C81

COMPONENT STORE TRANSACTION FAILURE SUMMARY
 No transaction error was detected.

Sep 14, 2009 at 2:17 PM

We encountered the same issue with the Smart Client Software Factory, there were many reference (I believe even a utility) to update the manifest but by far the easiest work-around was to simply add the module reference to the shell application.

Sep 14, 2009 at 3:50 PM

Hi, lastly I figured! This error was caused by duplicate assemblies in the Modules directory. While buiding the application within Visual Studio, at least two dlls are added into the Modules subfolder, e.g. the Microsoft.Practices.Composite.dll and Microsoft.Practices.ServiceLocation.dll. These assemblies however exists in the root directory, so there is no need for them at all (my mistake was to add them using the Manifest Manager Utility). Removing these assemblies resolved the problem. To summarize: the issue was caused by duplicate assemblies. Removing those assemblies will resolve the problem.