VS 2010 One Click Deployment Issue "Application Validation did not succeed. Unable to continue"

Question

I have a win form application that i can create an installer for and install. However when it comes to one click deployment it does not work i get the following error.

"Application Validation did not succeed. Unable to continue"

When i click on more details i get the following.

Following failure messages were detected:

• Reference in the manifest does not match the identity of the downloaded assembly Designer.exe.

I have tried a number of different fixes without success.

• I have tried to create the application with a manifest.
• I have removed all the prerequisites.
• I have also changed all the application files to include.

Does anyone know how i could fix this problem?

Answer 1

Cant seem to find any information about it at all.

There is a lot of info about this, just google the error message. The proper query is "Reference in the manifest does not match the identity of the downloaded assembly" and you'll find lots of good hits that describe workarounds.

I'll try to do more than just add yet another google hit and explain the underlying problem. Nobody explains what is really going wrong. And hopefully help to cover the hard-to-diagnose cases as well. At issue is a very poorly documented property of an executable file, the application manifest. Beware that the word "manifest" means many things in Windows, the application manifest is distinct from the ClickOnce manifest.

The application manifest adds extra configuration to an executable file. They are very important since Vista, you need one to mark your program to be compatible with UAC. Several other uses, you need entries to use registry-free COM, alter the way Windows looks for dependent DLLs, disable Windows appcompat shims or to tell Windows 8.1 to stop lying about its version number.

One issue that's relevant to your problem is that there two ways to provide the manifest for an executable. The preferred way is to embed it inside the executable file itself. Embedded as an unmanaged resource. This is the way it is done when you build a Winforms application with the default settings. The C# or VB.NET compiler embeds a default one. Or a specific one you added to your project with the Application Manifest File item template. Embedding it is preferred because the limits the number of ways the manifest could get lost or tinkered with. And is what Windows will look for first.

Or it can be provided as a separate file, it must be named yourapp.exe.manifest and stored in the same directory as yourapp.exe. This is the way the Publish wizard will do it, you can find it back in the publish folder and it will be copied to the target machine along with the executable.

Perhaps you can smell the looming problem, two manifests and they don't match. System.Deployment follows the Windows rules and first looks for an embedded manifest. It will find the default one that the C# compiler embeds. It checks the assembly identity against the one declared in the ClickOnce manifest. And if it doesn't match then, kaboom with "Reference in the manifest does not match the identity of the downloaded assembly". It thinks the executable file was replaced while it traveled from your web server to the user's machine by a man-in-the-middle attack.

You start diagnosing this problem by first looking at the unmanaged resources embedded inside your executable file (Designer.exe), the ones that System.Deployment looks at first. In Visual Studio, use File + Open + File and select Designer.exe from the publish folder. It will probably resemble this:

The RT_MANIFEST entry with ID #1 is the embedded application manifest. You can double-click it to have a look but you'll get a hex dump of the content. Easier is to right-click, Export and specify a .txt file name so you can look at it with a text editor. It will resemble something like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

The <assemblyIdentity> element is the trouble-maker. Note how it has a generic name, "MyApplication.app" and a default version number of 1.0.0.0. If you look at the yourapp.exe.manifest file that the Publish wizard generated then you'll see something like this:

  <asmv1:assemblyIdentity name="WindowsFormsApplication86.exe" version="1.0.0.0" 
     publicKeyToken="e939ba736dc34835" language="neutral" 
     processorArchitecture="msil" type="win32" /> 

Not even close. Kaboom

---

Several ways to fix this:

• With the File + Open + File view of the executable still open, right-click the manifest ID #1 and select Delete. That removes it entirely, System.Deployment will now find the file instead
• Project + Properties, Application tab, change the Manifest option to "Create application without a manifest". This should be your preferred solution
• If you require a custom manifest and used the Application Manifest File then you must remove it again and instead edit the yourapp.exe.manifest file that the Publish wizard generated. This is quite painful and best avoided since you need to repeatedly do this
• Update your VS version, this problem has been fixed and it is now smart enough to rebuild your project, now without the default manifest, when you publish. I think starting at VS2012, definitely for VS2013.