问题
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?
回答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.
回答2:
My fix, came after 3 days of browsing and trying a few forum suggestions. Nothing worked for me.
Then I began to carefully sift through the details of the error message and noticed that somewhere in the middle there was reference to "Invoices.exe" and not "Invoices.dll" as I was expecting. Then I remembered I had recently added a new project to my solution called "Invoices" and although I had successfully published since, I had not attempted to use the published solution since
A look at the main project's properties references page showed the problem.
Main Project | Properties | References
All the other projects were shown as dll except "Invoices". I removed the "Invoices" entry. Hopped over to the properties of the "Invoices" project and on the Application page noted that the application output type was "Windows Form Application"
Invoices | properties | Application
In the drop-down box, I selected "Class Library" instead
Saved the Properties | rebuild Invoices |
Returned to the main project Properties references page and added "Invoices", this time it showed up as a dll and I was able to Publish without errors. Thereafter my application loaded without the ["Application Validation did not succeed. Unable to continue"] error.
回答3:
I encountered this issue in a VS 2017 solution with a few Microsoft Office Libraries (Microsoft.Office.Uc, Microsoft.Lync.Models) after adding a custom library I had written to the project.
The problem (as alluded to by @Bones2) was that I had added a reference to an Exe file from that custom library. While normally this did not create any issues when adding the custom library into my test project (effectively a glorified "Hello World"), I started getting Application validation did not succeed. Unable to continue. in my production environment. This is probably due to security settings around the COM & interop libraries of MS Office ("Assembly does not allow partially trusted callers").
In my case, the solution was to remove the reference to the Exe (which is needed as a utility by the application, but is called from cmd) and add the exe as an Existing item in Visual Studio. Note that once you complete this step, you'll also need to go to the properties for each of the newly added items and set the Build Action to Content and Copy to Output Directory to Copy always.
来源：https://stackoverflow.com/questions/21697109/vs-2010-one-click-deployment-issue-application-validation-did-not-succeed-unab