none
ClickOnce Deployment Issue - File Has Different Computed Hash Than Specified In Manifest - Urgent!

    Question

  • Hello, originally posted this in the VB General forum - didn't get much response, so I thought I would post it here. I'm trying to deploy a ClickOnce Windows app. I have successfully installed it in the past. I made some changes to the .mdf file I have referenced in my application (I made the changes in SQL Server). When I published the app on another machine, I started receiving the error message "File ....mdf, has a different computed hash than specified in manifest". I tried a number of different suggestions that people have made on these forums, but no luck - I tried building the app twice, then deploying; I tried manually updating the revision number; I tried creating a new Test Certificate; I tried signing the assembly; I tried making a change to the .mdf file from within the app, and re-publishing; etc. Can someone please assist? We have a client install coming up very soon, so I need to get this resolved as soon as possible. Thanks in advance.

    PLATFORM VERSION INFO
     Windows    : 5.1.2600.131072 (Win32NT)
     Common Language Runtime  : 2.0.50727.42
     System.Deployment.dll   : 2.0.50727.42 (RTM.050727-4200)
     mscorwks.dll    : 2.0.50727.42 (RTM.050727-4200)
     dfdll.dll    : 2.0.50727.42 (RTM.050727-4200)
     dfshim.dll    : 2.0.50727.42 (RTM.050727-4200)

    SOURCES
     Deployment url   : file:///E:/Install/NewDueDiligence.application
     Application url   : file:///E:/Install/NewDueDiligence_1_0_1_78/NewDueDiligence.exe.manifest

    IDENTITIES
     Deployment Identity  : NewDueDiligence.application, Version=1.0.1.78, Culture=neutral, PublicKeyToken=c153f4632af735c0, processorArchitecture=msil
     Application Identity  : NewDueDiligence.exe, Version=1.0.1.78, Culture=neutral, PublicKeyToken=c153f4632af735c0, processorArchitecture=msil, type=win32

    APPLICATION SUMMARY
     * Installable application.

    ERROR SUMMARY
     Below is a summary of the errors, details of these errors are listed later in the log.
     * Activation of E:\Install\NewDueDiligence.application resulted in exception. Following failure messages were detected:
      + File, DueDiligence.mdf, has a different computed hash than specified in manifest.

    COMPONENT STORE TRANSACTION FAILURE SUMMARY
     No transaction error was detected.

    WARNINGS
     There were no warnings during this operation.

    OPERATION PROGRESS STATUS
     * [10/23/2006 10:08:58 PM] : Activation of E:\Install\NewDueDiligence.application has started.
     * [10/23/2006 10:08:59 PM] : Processing of deployment manifest has successfully completed.
     * [10/23/2006 10:08:59 PM] : Installation of the application has started.
     * [10/23/2006 10:08:59 PM] : Processing of application manifest has successfully completed.
     * [10/23/2006 10:09:01 PM] : Request of trust and detection of platform is complete.

    ERROR DETAILS
     Following errors were detected during this operation.
     * [10/23/2006 10:09:07 PM] System.Deployment.Application.InvalidDeploymentException (HashValidation)
      - File, DueDiligence.mdf, has a different computed hash than specified in manifest.
      - Source: System.Deployment
      - Stack trace:
       at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String filePath, Hash hash)
       at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String filePath, HashCollection hashCollection)
       at System.Deployment.Application.ComponentVerifier.FileComponent.Verify()
       at System.Deployment.Application.ComponentVerifier.VerifyComponents()
       at System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState subState, AssemblyManifest deployManifest, AssemblyManifest appManifest, Uri sourceUriBase, String targetDirectory, String group, IDownloadNotification notification, DownloadOptions options)
       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)
       at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)

    COMPONENT STORE TRANSACTION DETAILS
     No transaction information is available.

     

    Tuesday, October 24, 2006 2:22 AM

Answers

  • Actually, the problem was with the manifest itself rather than a file it.

    I solved the problem in a different way - Rather than attempting to change the manifest to include additional files, I regenerate the entire clickonce deployment folder each time.

    Apparently modifying the manifest through the mageui tool does not always recompute the hash for the manifest.

    Saturday, January 13, 2007 1:21 AM

All replies

  • Hello, Could someone please assist with this issue? I have tried everything - nothing is working. I am dead in the water. Please help.
    Thursday, October 26, 2006 12:14 AM
  • I have the same problem... Not figured it out yet though...

    Maybe this will help you:
    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=205025&SiteID=1
    Friday, October 27, 2006 12:32 PM
  • You need to regenerate the application manifest. This happens when you change file contents and do not update your manifests accordingly.
    Saturday, October 28, 2006 1:01 AM
  • Hello, thank you for the reply. Could you explain what I need to do to regenerate the application manifest? Thanks.
    Monday, October 30, 2006 2:27 PM
  • You can use Mage.exe to regenerate the application manifest. The following link will give you some details on how to use it.

    http://msdn2.microsoft.com/en-us/library/acz3y3te.aspx

     

    Monday, October 30, 2006 9:32 PM
  • So I'd be trying to figure out why the file is getting changed post publishing.  Once you publish your app, you shouldn't generally change the files on the server. If you have a good reason to change them, then you will need to update the manifests using mage.exe as has been suggested.

    Any ideas what's changing and why?

     

    Tuesday, October 31, 2006 6:29 AM
    Moderator
  • Actually, the file is not changing post-publish. I am simply publishing the app, and attempting to deploy immediately afterward. I have tried updating the application manifest and regenerating the certificate via mageui.exe, but I am still seeing the issue.
    Wednesday, November 1, 2006 1:20 PM
  • It's hard to troubleshoot this without looking at the actual .mdf file and .exe.manifest file. If the file is not being changed post publish there really should not be any reason for hash mismatch especially if installed from local machine. (If this was a web download over http there could be web server or proxy server causing file to be changed somehow but this won't happen in the local machine install case).

    Here are few things I'd suggest checking:

    (1) Run standalone tool to generate hash of file and compare that with hash in manifest. Attached sample code snippet below that you can compile into a GenerateFileHash.exe tool to spit out the hash of a file. Run it against the .mdf file in published location and compare result with the hash in the app manifest (.exe.manifest file). In the app manifest search for .mdf file and look for hash section under it (e.g. <dsig:DigestValue>ddK2+W5PklMmYt3ordxQjb4BQuA=</dsig:DigestValue>). If the two hashes don't match that would explain the ClickOnce failure.

    (2) Does this happen for this one app and one file only? If you remove this one file from the app does install then succeed?

    (3) Can you try installing this app on another machine? Do you get the same error?

    If you post back with findings from trying this out we can then look into next steps for troubleshooting.

    Regards,
    Sameer

    Sample code for GenerateFileHas.exe tool:

    using System;
    using System.Security.Cryptography;
    using System.IO;

    namespace FileHashSample
    {
        public class FileHash
        {
            public FileHash()
            {
                return;
            }

            public string ComputeHash(string filePath)
            {
                string filePathNormalized = System.IO.Path.GetFullPath(filePath);
                SHA1 sha = new SHA1Managed();
                FileStream fs = new FileStream(filePathNormalized, FileMode.Open, FileAccess.Read);
                byte[] byteHash = sha.ComputeHash(fs);
                fs.Close();
                return Convert.ToBase64String(byteHash, 0, byteHash.Length);
            }

            public static void Main(string[] args)
            {
                if (args.Length == 0)
                {
                    Console.WriteLine("Please Enter a File Path");
                    return;
                }
                string filePath = System.IO.Path.GetFullPath(args[0]);
                FileHash objFileHash = new FileHash();
                Console.WriteLine("File Path is {0}", filePath);
                Console.WriteLine("File Hash is {0}", objFileHash.ComputeHash(filePath));
                return;
            }
        }

    }

    Thursday, November 2, 2006 11:44 PM
  • Hi Sameer,

    I am facing a similar problem but not in the exact same fashion. The application has been published to a machine and i am able to launch the application on 3 machines and on 2 machines it fails giving a similar error. The error is pasted below. Also, the download of the application does complete on one of the machiens where it is failing, but i dont know where these files get downloaded temporarily. I am assuming that the files somehow get modified in between and want to generate a hash of the files on the machines where its not working, but since i dont know where the file gets downloaded temporarily, so i cant generate the hash. Please suggest a way out.

    PLATFORM VERSION INFO
     Windows    : 5.1.2600.131072 (Win32NT)
     Common Language Runtime  : 2.0.50727.42
     System.Deployment.dll   : 2.0.50727.42 (RTM.050727-4200)
     mscorwks.dll    : 2.0.50727.42 (RTM.050727-4200)
     dfdll.dll    : 2.0.50727.42 (RTM.050727-4200)
     dfshim.dll    : 2.0.50727.42 (RTM.050727-4200)

    SOURCES
     Deployment url   : 
          Server  : Microsoft-IIS/5.0
          X-Powered-By : ASP.NET
     Application url   : 
          Server  : Microsoft-IIS/5.0
          X-Powered-By : ASP.NET

    IDENTITIES
     Deployment Identity  : testapp.application, Version=1.0.0.0, Culture=neutral, PublicKeyToken=85225c624ac37fea, processorArchitecture=msil
     Application Identity  : testapp.exe, Version=1.0.0.0, Culture=neutral, PublicKeyToken=85225c624ac37fea, processorArchitecture=msil, 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 xxx resulted in exception. Following failure messages were detected:
      + File, testapp - xxx.exe, has a different computed hash than specified in manifest.

    COMPONENT STORE TRANSACTION FAILURE SUMMARY
     No transaction error was detected.

    WARNINGS
     There were no warnings during this operation.

    OPERATION PROGRESS STATUS
     * [20/12/2006 05:19:18] : Activation of  has started.
     * [20/12/2006 05:19:18] : Processing of deployment manifest has successfully completed.
     * [20/12/2006 05:19:18] : Installation of the application has started.
     * [20/12/2006 05:19:19] : Processing of application manifest has successfully completed.
     * [20/12/2006 05:19:22] : Request of trust and detection of platform is complete.

    ERROR DETAILS
     Following errors were detected during this operation.
     * [20/12/2006 05:19:33] System.Deployment.Application.InvalidDeploymentException (HashValidation)
      - File, testapp - xxx.exe, has a different computed hash than specified in manifest.
      - Source: System.Deployment
      - Stack trace:
       at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String filePath, Hash hash)
       at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String filePath, HashCollection hashCollection)
       at System.Deployment.Application.ComponentVerifier.FileComponent.Verify()
       at System.Deployment.Application.ComponentVerifier.VerifyComponents()
       at System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState subState, AssemblyManifest deployManifest, AssemblyManifest appManifest, Uri sourceUriBase, String targetDirectory, String group, IDownloadNotification notification, DownloadOptions options)
       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)
       at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)

    COMPONENT STORE TRANSACTION DETAILS
     No transaction information is available.

     

    Wednesday, December 20, 2006 5:35 AM
  • To add to the above issue, the file in question that fails the hash verification is a VC exe. This file has been added to the manifest, and i have compared the hash of the file with the value that is present in the manifest file. The above error still comes. Moreover, i removed the VC file and its dependencies from the deployment and then the click once happened successfully. What am i missing for my VC files? All its dependencies are present in the manifest and the hashes match perfectly. I am still unable to find where the exe's and dll's get stored temporarily. Urgent help is needed please.
    Friday, December 22, 2006 9:10 AM
  • I have been trying to use ClickOnce to deploy a simple WinForms application and have run into similar problems to those described here and some different ones.

    Running MageUI.exe to regenerate the hash codes and re-sign the manifest seems to work, although I still get failures on the simplest cases for no apparent reasons.

    My case is not even on a redeploy or update - just regenerating the application and creating a new version can be problemmatic.

    What I am trying to do that does not seem to work is to deploy a list of data files containing gif and wav files in the same directory as the executable.

    Often after manually adding the list of data files and regenerating the hash code and signing the manifest I get errors.

    I do not know why is this manual step is even necessary - they are in the project but are not getting deployed.

    Even when the deployment does not create errors, the data files are never deployed when the setup.exe is clicked (all local testing, no network).

    I have looked at the ApplicationDeployment class at runtime, and everything seems correct, but nothing is copied to the Data directory.

    I have tried both types of deployment - the Online only and the Online/Offline that registers the program.

    Can anyone provide help for this type of problem? It seems relatively common.

    Wednesday, December 27, 2006 7:11 PM
  • I have more information on the problems with ClickOnce, but no real solutions - hopefully someone else can explain what is happening and provide ideas for getting around the errors.

    I tried a local ClickOnce - I created a simple single executable, single DLL solution, published it, and the executable ran, although incorrectly since it requires a number of other files in the same directory.

    I tried adding a number of files to the application directory and to the manifest with mageui.exe, rehashed and resigned it, and it got the usual error about the computed hash.

    I repeated the same operation (republish, readd files, recalculate hash, re-sign, etc.) and this time the executable ran, although incorrectly because of the missing files. Using procmon to watch which files were being created, the temporary Data directory was created, but the files are never copied to it.

    I tried executing the same ClickOnce application project from another computer on the local network in the same domain, and it failed, even if I copied the setup.exe and application directory to the other computer. The interesting point is how it failed - Application manifest has either a different computed hash than the one specified or no hash specified at all.

    PLATFORM VERSION INFO
     Windows    : 5.1.2600.131072 (Win32NT)
     Common Language Runtime  : 2.0.50727.42
     System.Deployment.dll   : 2.0.50727.42 (RTM.050727-4200)
     mscorwks.dll    : 2.0.50727.42 (RTM.050727-4200)
     dfdll.dll    : 2.0.50727.42 (RTM.050727-4200)
     dfshim.dll    : 2.0.50727.42 (RTM.050727-4200)

    SOURCES
     Deployment url   : file:///Q:/temp/ControlPanel/ControlPanel.application
     Application url   : file:///Q:/temp/ControlPanel/ControlPanel_1_0_0_12/ControlPanel.exe.manifest

    IDENTITIES
     Deployment Identity  : ControlPanel.application, Version=1.0.0.12, Culture=neutral, PublicKeyToken=6826da00991f9aa5, processorArchitecture=msil

    APPLICATION SUMMARY
     * Online only application.

    ERROR SUMMARY
     Below is a summary of the errors, details of these errors are listed later in the log.
     * Activation of Q:\temp\ControlPanel\ControlPanel.application resulted in exception. Following failure messages were detected:
      + Application manifest has either a different computed hash than the one specified or no hash specified at all.
      + File, ControlPanel.exe.manifest, has a different computed hash than specified in manifest.

    COMPONENT STORE TRANSACTION FAILURE SUMMARY
     No transaction error was detected.

    WARNINGS
     There were no warnings during this operation.

    OPERATION PROGRESS STATUS
     * [12/27/2006 22:11:49] : Activation of Q:\temp\ControlPanel\ControlPanel.application has started.
     * [12/27/2006 22:11:53] : Processing of deployment manifest has successfully completed.
     * [12/27/2006 22:11:53] : Installation of the application has started.

    ERROR DETAILS
     Following errors were detected during this operation.
     * [12/27/2006 22:11:53] System.Deployment.Application.InvalidDeploymentException (HashValidation)
      - Application manifest has either a different computed hash than the one specified or no hash specified at all.
      - Source: System.Deployment
      - Stack trace:
       at System.Deployment.Application.DownloadManager.DownloadApplicationManifest(AssemblyManifest deploymentManifest, String targetDir, Uri deploymentUri, IDownloadNotification notification, DownloadOptions options, Uri& appSourceUri, String& appManifestPath)
       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)
       at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state)
      --- Inner Exception ---
      System.Deployment.Application.InvalidDeploymentException (HashValidation)
      - File, ControlPanel.exe.manifest, has a different computed hash than specified in manifest.
      - Source: System.Deployment
      - Stack trace:
       at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String filePath, Hash hash)
       at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String filePath, HashCollection hashCollection)
       at System.Deployment.Application.DownloadManager.DownloadApplicationManifest(AssemblyManifest deploymentManifest, String targetDir, Uri deploymentUri, IDownloadNotification notification, DownloadOptions options, Uri& appSourceUri, String& appManifestPath)

    COMPONENT STORE TRANSACTION DETAILS
     No transaction information is available.

     

     

    Thursday, December 28, 2006 3:26 AM
  •  

    I got the same error:

    "File, AssemblyCode.dll, has a different computed hash than specified in manifest."

    where "AssemblyCode.dll" was a library referenced in my EXE that was being deployed. I simply had to remove the reference and add the reference, then re-publish the project. It worked. There seems to be some value that gets changed in the project but perhaps an old value is used when publishing files...

    Anyway, remove and add the reference may help you with the mdb file hash problem...

    If this helps, please mark this post as the solution...

    Thanks

     

    Thursday, January 11, 2007 6:53 PM
  • Actually, the problem was with the manifest itself rather than a file it.

    I solved the problem in a different way - Rather than attempting to change the manifest to include additional files, I regenerate the entire clickonce deployment folder each time.

    Apparently modifying the manifest through the mageui tool does not always recompute the hash for the manifest.

    Saturday, January 13, 2007 1:21 AM
  • here is another issue,

     

    if you switch from debug to relase or vice varsa, you will get the Hash failure error no matter where you publish

     

     

    Wednesday, June 13, 2007 11:07 PM
  • I had the same problem and I solved it using Mage.exe / MageUI.exe

     

    What you need to do is:

    - Open the   xxx.exe.manifest file using MageUI, select on file on the left pane and populate the necessary files once again and save the manifest singing a key

    - Open the base application manifest file using MageUI again and click on application references > Select Manifest and select the manifest you edited in the previous step, save your work and that's it...now the file will have a new hash computed..

     

    • Proposed as answer by Patibandha Thursday, April 14, 2011 3:44 PM
    Thursday, July 5, 2007 3:14 PM
  • Hi all,

     

    I have had this issue for a very long time. I read all you contributed, however, I am a simple man and I would like to see a simple solution. After all, why should I be needing something like Mage to solve what VS2005 and ClickOnce should take care of.

     

    All I am doing is deploying my code over the internal network of our small company. The publishing always workes without issues, but when I want to update the software on client machines I often get this hash difference error message. What I usually then do is simply regenerate (AGAIN!) the whole project and publish again. Trying to update on the client machine then usually works.

     

    However, I simple get mad at having to do everything TWICE all the time!

     

    As stated by other people, this seems to be a fairly common problem. Has no one yet found a proper final solution for this issue. What does Microsoft say to this?

     

    Any feedback is greatly appreciated!

     

    Kind regards,

    Marc

    Thursday, October 4, 2007 4:16 PM
  • I have arrived at a simple (although probably not condoned by Microsoft) solution to this problem.  Before you publish a new version, open the target folder and delete (or rename) the folder(s) for the previous version(s) as well as any file with the extension .manifest.  This forces .NET to recreate the entire publish package.  It may not be pretty, but it works!

    Monday, October 22, 2007 8:39 PM
  • Hi there,

     

    Exactly the same experience here. However, it only started to happen when I added a new .resx file to the project for the second language that I need to support. After playing around with it a few hours, I figured that if I also add the .resx file to the Resources of the project, I don't get the above mentioned having-to-publish-twice behaviour any more.

     

    This might help others as well. I do realize, however, this is not the solution, it's just a workaround. At least one has to do this only once...

     

    my 0.02USD

    Friday, November 30, 2007 10:22 AM
  • Hi there,

     

    I've been fighting with this for a while myself.

    The biggest challenge we're facing now, is that the updating of the manifest needs to be scriptable (i.e. not using mageui)

     

    (Our specific scenario described in more detail at http://russellrockliff.spaces.live.com)

     

    So, I've found the following mage commands sorted us out...

     

    REM Set the working directory

    cd C:\XXX\APP_1_3_1_4

    REM Create a new Application Manifest (I did try using the -u switch to update the existing one, didn't work. Found creating a new one more reliable as a previous entry noted already.)
    c:\mage.exe -New Application -ToFile XXX.exe.manifest -Name XXX -Version 1.3.1.4 -FromDirectory C:\XXX\APP_1_3_1_4
     
    REM Sign this new Application Manifest
    c:\mage.exe -s XXX.exe.manifest -cf C:\XXX\APPKey.pfx -pwd YYYY
     
    REM Update the Base Deployment Manifest with the new Application Manifest and Sign Again
    c:\mage.exe -u c:\XXX\APP.application -appm XXX.exe.manifest -appc APP_1_3_1_4\XXX.exe.manifest
    c:\mage.exe -s c:\XXX\APP.application -cf c:\XXX\APPKey.pfx -pwd YYYY
    Tuesday, August 19, 2008 3:07 PM
  • I solved this problem with an .sdf file by:

     

    Manually setting app version greater then the last one.

    Uninstalling the one on the development machine.

    Removing the sdf from the project then re adding it (creates new dataset thing).

    Deleting the VS 2008 project folder/Properties/DataSources/System.Data.DataSet.datasource file.

     

    When I tried publishing it it ran first time.

     

    I only recommend this as a last resort though.

     

    Tuesday, September 30, 2008 9:00 AM
  • I solved it by removing the offending file (in this case Scripting.dll) and re-referencing it. The reason, I suspect, why it had caused the problem is that I had pinched it from another project.

     

    Wednesday, October 22, 2008 7:46 AM
  • Hi,

    I've checked the hash in the manifest file with the original hash of the corresponding file and notice that they are equal. Then I wonder if there is a anti-virus running on the web server where I publish the application. I've uninstall Symantec anti-virus on the web server and now everything is ok. It's not the first problem with symnatec, many years ago, symantec anti-virus was corrapting the VIEWSTATE's because it thinks that it is a virus. So it can be good to check anti-virus software both on clients and the server.
    ueo
    Wednesday, March 11, 2009 3:24 PM
  • I too am getting this message with no resolution.

    I have tried every solution on the net, and still no luck? I upgraded my laptop to a larger hard drive, and my application
    will not update/install on only "SOME" machines. This is hair pulling. Doesn't anyone at Microsoft have  a solution to this
    or a workaround? There are so many posts on this. I don't want to abandon click once.
    See below: Same 'has a different computed hash than specified in manifest.' message that others in this thread are seeing.

    MageUI didn't work, creating test certificate didn't work(rebuild all, republish) and many other solutions. I haven't been stumped like this since they change Coke Classic to the ____ flavor years ago....

    ====================

    PLATFORM VERSION INFO
     Windows    : 5.1.2600.131072 (Win32NT)
     Common Language Runtime  : 2.0.50727.3053
     System.Deployment.dll   : 2.0.50727.3053 (netfxsp.050727-3000)
     mscorwks.dll    : 2.0.50727.3053 (netfxsp.050727-3000)
     dfdll.dll    : 2.0.50727.3053 (netfxsp.050727-3000)
     dfshim.dll    : 2.0.50727.3053 (netfxsp.050727-3000)

    SOURCES
     Deployment url   : http://craigslistautoposter.southcoastsbs.com/admaker.application.php
          Server  : Apache/1.3.41 (Unix) PHP/4.4.8 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a
          X-Powered-By : PHP/4.4.8
     Deployment Provider url  : http://craigslistautoposter.southcoastsbs.com/admaker.application
          Server  : Apache/1.3.41 (Unix) PHP/4.4.8 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a
     Application url   : http://craigslistautoposter.southcoastsbs.com/Application%20Files/admaker_2_1_1_18/admaker.exe.manifest
          Server  : Apache/1.3.41 (Unix) PHP/4.4.8 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a

    IDENTITIES
     Deployment Identity  : admaker.application, Version=2.1.1.18, Culture=neutral, PublicKeyToken=5e5a14cb945e4d03, processorArchitecture=msil
     Application Identity  : admaker.exe, Version=2.1.1.18, Culture=neutral, PublicKeyToken=5e5a14cb945e4d03, processorArchitecture=msil, type=win32

    APPLICATION SUMMARY
     * Installable application.

    ERROR SUMMARY
     Below is a summary of the errors, details of these errors are listed later in the log.
     * Activation of http://craigslistautoposter.southcoastsbs.com/admaker.application.php resulted in exception. Following failure messages were detected:
      + File, localpicsII.xml, has a different computed hash than specified in manifest.

    COMPONENT STORE TRANSACTION FAILURE SUMMARY
     No transaction error was detected.

    WARNINGS
     There were no warnings during this operation.

    OPERATION PROGRESS STATUS
     * [5/1/2009 3:14:56 PM] : Activation of http://craigslistautoposter.southcoastsbs.com/admaker.application.php has started.
     * [5/1/2009 3:14:58 PM] : Processing of deployment manifest has successfully completed.
     * [5/1/2009 3:14:58 PM] : Installation of the application has started.
     * [5/1/2009 3:14:58 PM] : Processing of application manifest has successfully completed.
     * [5/1/2009 3:14:59 PM] : Request of trust and detection of platform is complete.

    ERROR DETAILS
     Following errors were detected during this operation.
     * [5/1/2009 3:15:15 PM] System.Deployment.Application.InvalidDeploymentException (HashValidation)
      - File, localpicsII.xml, has a different computed hash than specified in manifest.
      - Source: System.Deployment
      - Stack trace:
       at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String filePath, Hash hash)
       at System.Deployment.Application.ComponentVerifier.VerifyFileHash(String filePath, HashCollection hashCollection)
       at System.Deployment.Application.ComponentVerifier.FileComponent.Verify()
       at System.Deployment.Application.ComponentVerifier.VerifyComponents()
       at System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState subState, AssemblyManifest deployManifest, AssemblyManifest appManifest, Uri sourceUriBase, String targetDirectory, String group, IDownloadNotification notification, DownloadOptions options)
       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)

    COMPONENT STORE TRANSACTION DETAILS
     No transaction information is available.

     

    Friday, May 1, 2009 7:40 PM

  • Why does your application file have a file extension of ".php" appended to it? Are you changing this after moving it out to your server? This is probably your problem. You can not modify any of the files w/o re-signing the deployment. Additionally, the file association in Windows is set up for .application, and probably isn't opening it the right way if you change it to .php.

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Sunday, May 3, 2009 8:39 PM
    Moderator
  • The filename extension is necessary for some browsers for it to work (IE 6 for one), or you get instead of the application launch, the XML output. I found that solution in 2007 I believe on this site. Maybe not. It has worked this way for more than a year.

    This had nothing to do with it.  I tried renaming the whole project as well, and this STILL didn't work.
    I then created the whole project class by class manually, and this did the trick. I will probably never know why this worked, but my guess is one of the files was corrupted and I suspect it was the application manifest file. I have my suspicisons.

    I could go back and spend a day trying to figure out where the exact problem lied, but I'm up and running now with
    a new project and I can get back to getting paid.

    Thanks


    Monday, May 4, 2009 3:08 AM
  • The filename extension is not necessary for any browser to work. If IE is opening the application file and showing XML, it means you do not have the MIME types set up on your server and this is not serving up the files correctly. Change your MIME types and stop renaming the dang files, and try it again. Here are the MIME types:

    These are the MIME types you need in order to host a ClickOnce application:

    .application  --> application/x-ms-application
    .manifest  --> application/x-ms-application
    .deploy   --> application/octet stream

    If you are deploying .Net 3.5 as a prerequisite, you need these as well:

    .msp --> application/microsoftpatch
    .msu --> application/microsoftupdate

    If you have vsto apps, you need this one:

    .vsto --> application/x-ms-vsto

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Monday, May 4, 2009 4:31 AM
    Moderator
  • I Solved it by removing System.deployment reference and adding it again...Hope u vll get luck


    Regards
    Sai Satish
    Indian Servers

    Sai Satish Indian Servers http://www.indianservers.com
    Thursday, October 8, 2009 9:23 AM
  • I just ran into this issue and have been looking all over for a solution.  I seem to have found the cause of it  (in my case at least). 

    I was publishing a Winforms 2008 app and then zipping it to transfer it to a remote clients workstation for install.  I was able to finish the install in some cases but more times than not the install would fail. 

    Turns out that zipping the publish project up seems to be the cause of my head aches.  I did a transfer to the remote machine without zipping anything up and can now install the app.

    Just thought I would post this in case anyone is still having problems with this issue ...one more thing to try.

    Friday, January 22, 2010 1:42 AM
  • Yes! I rename only the setup.exe and... goal!!!!
    Thursday, July 15, 2010 11:50 PM
  • I had a load-balancer with two underlying servers.  I did a "ClickOnce publish" to both servers and tried ClickOnce from the load-balancer.  Seems like each deployment got it's own hash value and that the load balancer fetched files from both machines, therefore the mismatch.  Shutting down one server got it working.

     

    So the solution was to publish only to one server and then copy to the other (instead of publishing again).


    Wednesday, June 22, 2011 9:36 PM
  • Do the two deployments have the same installation URL? Or are they different? Once a user installs from somewhere with a specific URL, it will go back to that URL for updates (unless you override it). Installing from one URL and trying to install an update from a different URL will cause problems, because the installation URL is one of the fields that defines the identity of the deployment.

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev
    • Proposed as answer by Mandrak1 Wednesday, December 14, 2011 12:08 AM
    Thursday, July 7, 2011 7:08 AM
    Moderator
  • Delete all the files in the destination publishing folder, and also delete all the files from the bin/release and bin/debug folders. This will give you a totally new version for publishing. It helped me, but I am really not satisfied with the solution because I still don't know why is the problem showing.

    I see that there is a lot of people with the same problem, and a lot of people with a lot of random workarounds but no real solution. Where the h*** is Microsoft staff to solve this one? This is obviously an old bug, and there is no way that they didn't noticed it.

    Wednesday, December 14, 2011 12:22 AM
  • Hello all,

    can ofuscation by dotfuscator create this problem too.? 

    i get same error when (1) i have written a postbuild command which ofuscate my output assembly and (2) i sign my assembly with .pfx file using signing tab in project properties.

    but i dont get this error when i do (1) but not (2), but now my code is not safe.

    what should i do. please help.

    thanks

    shashank



    • Edited by shashank Tuesday, February 7, 2012 8:14 AM
    Tuesday, February 7, 2012 7:45 AM
  • This is not a solution actually. As you said, MageUI not always recompute the hash for the manifest, which is the main problem for me. I need to obfuscate the executable and then to create and sign the manifest files. This can be done using only the MageUI tool. If there is a bug in this tool, we have to mention it.

    Kranidiotis Nassos

    Wednesday, July 4, 2012 12:52 PM
  • Hi shashank,

    After you create and sign your deployment, you can not change the file. So if you create the deployment and then obfuscate it, you have to re-sign the files using mage.exe or mageui.exe. (You can automate this with mage).

    If you do it as a post-build command, then it does it before signing the published deployment, and I don't think it can create the deployment using obfuscated files.

    I did some research on the Dotfuscator version included with Visual Studio a couple of years ago. What I discovered is the version included in VS is more like "Dotfuscator Lite". It will work, but requires manual signing after obfuscating. If you upgrade (at a cost, of course), you can get a version of Dotfuscator that will obfuscate the assemblies and then re-sign the manifests so you don't have to.

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev

    Wednesday, July 4, 2012 8:43 PM
    Moderator
  • Hi Akran,

    I don't think you're understand what shashank is saying. He is trying to do the obfuscation after creating the deployment, but not re-signing the files, which you have to do.

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev

    Wednesday, July 4, 2012 8:44 PM
    Moderator
  • Hi RobinDotNet,

    I had the same problem as shashank. I have created the deployment and then obfuscated the exe. Finally, I have recreated the application and deployment manifest files, but I was always getting errors, such as 

    + Application manifest has either a different computed hash than the one specified or no hash specified at all. 
    + File, TestApp.exe.manifest, has a different computed hash than specified in manifest.

    It seems as MAGEUI.exe has the problem. Take a look at this thread, if you please and give me a clue on where I 'm doing it wrong. 

    Thanks


    Kranidiotis Nassos

    Thursday, July 5, 2012 2:54 PM
  • I'm having this issue after running signtool as a post-build step. Before VS2012 I did not have any problem with this. Somehow the manifest hash is being generated before the post-build step, which seems really odd to me.
    Thursday, March 7, 2013 1:42 AM
  • E. Timothy Uy,

    You need to make sure you're signing the right file. Are you signing it in the \obj folder or the \bin folder? You need to sign the one in the \obj folder if you are using a post-build command.

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev

    Sunday, March 24, 2013 8:51 PM
    Moderator
  • Hi Akran,

    I'm sorry you are still having a problem. Millions of people use mageUI with no problem at all. Since I don't know exactly what you're doing, I don't know if you're doing it correctly. If you want to post back your steps exactly, I'll take a look and see if I can see anything obvious.

    The order is this:

    1) Open the application manifest (yourapp.exe.manifest) and sign it.

    2) Open the deployment manifest, go to the tab for the app manifest and re-select it (even if it's showing) in the \application files\whateverversion\ folder.

    3) Sign and save the deployment manifest.

    RobinDotNet


    Click here to visit my ClickOnce blog!
    Microsoft MVP, Client App Dev

    Sunday, March 24, 2013 8:54 PM
    Moderator
  • Hello, Please suggest how we can update application manifest file. Thankyou

    Monday, February 8, 2016 10:41 AM
  • I was having hash mis-match problems updating a ClickOnce manifest using mage.exe (newest version) after updating an older .NET 2.0 project to .NET 4.7.  What I finally determined was the problem was the hash algorithm being used by Visual Studio when publishing was now sha256 (I'm assuming this changed when I moved from .NET 2.0 to .NET 4.7) but mage.exe by default was using sha1.

    Here is what I saw in my .application manifest generated by VS:

        <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" />

    Here is what I saw in my modified .application manifest after updating and re-signing using mage.exe:

        <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />

    To fix, I just modified my mage.exe command line by adding the -Algorithm setting to the end of my update command to force sha256:

        mage -Update xyz.application -Name "whatever" -ProviderURL "file://unc-path-name" -Algorithm sha256RSA

    Now it works as before.

    Wednesday, July 12, 2017 1:30 PM
  • how do you regenerate the entire clickonce deployment folder?
    Tuesday, October 3, 2017 10:52 AM