I was under the impression that when I sign both the ClickOnce manifests and the assembly in VisualStudio that I would see the publisher name when starting the exe and it requests permissions, but after building the project the Publisher is still missing
What am I missing here? Visual Studio does not complain about my cert and it looks like it imported it correctly showing the correct info
Issued To
Issued By COMODO
Intended Purpose .. etc
Edit: Managed to find this, this may already help Unknown Publisher still appears on correctly code-signed VSTO addin built with VS2010
I believe the answer to my problem is mageUI.exe or mage.exe
mageUI.exe allows to add a default signing cert to manually sign the manifest
http://msdn.microsoft.com/en-us/library/xhctdw55(v=vs.110).aspx
I was under the impression that VisualStudio would automatically do this, but its either not working for me or it was not intended to work this way
Related
I know this question has been asked a lot. I already tried many of the solutions in other questions, but is not working.
The application target framework is 4.5.2.
I'm working on Windows 7 with Visual Studio Community 2017.
The certificate is a code signing certificate from Sectigo. Standard version (not EV).
I'm using the Signing tab on Project properties to sign the application.
I'm publishing to a folder in my machine after that I upload the published files to a web server.
When I check the properties of the setup.exe and myApp.exe both are signed and timestamped correctly or at least it seems so.
Also, the myApp.application file in \path\publish_folder\, the \path\publish_folder\Application Files\myApp_1_0_0_0\myApp.application file and the \path\publish_folder\Application Files\myApp_1_0_0_0\myApp.exe.manifest have the <publisherIdentity> tag that matches with the certificate.
Everything seems good, even when I download the application and run the setup.exe I get the following warning, which is ok:
When setup.exe is executed is published is presented right but after the setup.exe calls myApp.application then it shows this warning with "Unknown Publisher" and that is the problem:
I tried installing the certificate in the "Trusted Root Certification Authorities" store, as well as in the "Trusted Publishers" store and in the "Personal" store, and publish the application again but the same thing happens.
In other questions said that the visual studio signing tab only sign the manifest but no the executable, as you can see this is not my case (setup.exe and myApp.exe have the digital signatures correctly) but even though I decided to try signing using signtool sign command (C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe) and build/publish events as theses answers proposed without luck:
.NET ClickOnce Signing results in "Unknown Publisher"
https://robindotnet.wordpress.com/2013/02/24/windows-8-and-clickonce-the-definitive-answer-2/
I think the only thing I'm missing to try is the "sign assembly" option (checkbox in Signing tab in Visual Studio), but when I do it the first time I get the error:
Cannot import the following key file: myKey.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_5578EF228F7A794C myApp
Then the second time I try I get this error:
Error importing key: An attempt was made to reference a token that does not exist
I signed the application and made the publish using Visual Studio Professional 2019 and it worked. Now it still shows the warning but with the publisher correctly in both warnings.
I'm getting this error after our company changed its AD domain.
UWP app development with VS 2019 and Windows 10 (1903)
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppXPackage.Targets(4469,5): error APPX1204: Failed to sign 'D:\AzureDevOps-Workspace\UWP\Main\BoardPACWinApp\bin\x64\Release\BoardPACWinApp_3.51.11.0_x64.appx'. SignTool Error: No certificates were found that met all the given criteria.
5>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppXPackage.Targets(4469,5): error APPX1204:
========== Build: 4 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
As soon as we've migrated to the new domain no one can create an app package to publish to the Microsoft store or to sideload.
Project is running under debug and release modes. Only issue is that it does not allow to publish.
I have tried opening the project on VS 2015 and creating a test certificate but no luck. (Not sure the test certificate has to do anything about this error though)
In UWP, Signing tab is by default disabled.
Everything was ok until the domain change. Administer privileges also given to us on the new domain.
I tried repairing the VS 2019 and no change.
signtool.exe also available in the PC.
I looked at the verbose enabled output windows to see if anything is missing. but besides "No certificates were found that met all the given criteria." there were no other issue logged.
I can see all the valid certificates and they haven't got expired
Highly appreciated all your solutions and guidance. Thank you.
Good news! I found a solution which worked for me and I hope this will works for you all as well.
When your domain changed all the test certificates you used on your UWP app will gets invalid. SO you have to create a new certificate on new domain in order to get the app publishing to work. I'm not a big fan of command line so what I did was, using the VS 2015 I generates a test certificate as per the image below. When it's done creating it in VS 2019 you will see the new certificate you create under new domain and it works like a charm.
I heard MakeCert tool can be used to create the certificate without needing the VS 2015.
You also can create a certificate that can be used by your co-workers. Refer to the image below.
Use the IE to get to your code signing certificates and do the export as per the screenshot above. Simply add their domain accounts when exporting and ask them to import it under "Current user" on their PC.
I have a C# Visual Studio 2013 solution (FindAlike) consisting of a number of projects. One of these projects (SimilarFiles) is a class library, including an AddIn Express component, as it implements an MS Office Add-in. When I publish the project as a ClickOnce installer an MS Add-in, a folder is created in the projects Publish folder with the version number of the project containing many files with extension .deploy. Also in the folder above are a file called findalike.application and one called setup.exe. If I copy the contents of the Publish folder to a new machine I can install the MS Add-in by clicking on findalike.application, but I receive a warning about an unknown publisher. If I confirm installation it proceeds satisfactorily.
I have a valid code signing certificate purchased from Comodo, which I use successfully with SignTool to sign a Windows Forms self-extracting installer from another project in the solution.
The option to sign the ClickOnce Manifest in the SimilarFiles project is greyed out, presumably because SimilarFiles is a class library project.
I can specify a code signing certificate by right-clicking on the SimilarFiles project and hovering over the Add-in Express entry and then selecting Signing Options, but the warning message still appears when I attempt the installation on a new machine
How can I use the code signing certificate in order to indicate to the ClickOnce installer on the new machine that the manifest is signed?
Signtool does not work on the setup.exe file, stating that it is not a valid Windows executable. Neither does it work on findalike.application
There is a Signing area on the VS Publish form which I'd missed. If I browse for my Code Signing Certificate (.pfx extension) and select SHA-1 only it signs OK, and install proceeds without warning. Thanks to Add-In Express for this solution.
The error happens when Outlook 2007 VSTO addin is loading at startup. This Windows 7 PC is used by multiple domain users. The error happens only for some of those users. For other users the addin works fine. I assume the unfortunate users do not have some permissions but not sure to where to look at.
Please, help if you hit the same error in the past. Thank you.
The error details are as follows
System.Deployment.Application.InvalidDeploymentException: Exception reading manifest from file:///C:/Program%20Files%20(x86)/<Application folder>/My_OutlookAddin.vsto: the manifest may not be valid or the file could not be opened. ---> System.Deployment.Application.InvalidDeploymentException: Manifest XML signature is not valid. ---> System.Security.Cryptography.CryptographicException: SignatureDescription could not be created for the signature algorithm supplied.
at System.Security.Cryptography.Xml.SignedXml.CheckSignedInfo(AsymmetricAlgorithm key)
at System.Security.Cryptography.Xml.SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm& signingKey)
at System.Deployment.Internal.CodeSigning.SignedCmiManifest.Verify(CmiManifestVerifyFlags verifyFlags)
at System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream s)
--- End of inner exception stack trace ---
at System.Deployment.Application.Manifest.AssemblyManifest.ValidateSignature(Stream s)
at System.Deployment.Application.ManifestReader.FromDocument(String localPath, ManifestType manifestType, Uri sourceUri)
--- End of inner exception stack trace ---
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.GetManifests(TimeSpan timeout)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()
Thank you guys for your feedbacks. I have resolved the puzzle. Firstly, the answers for your questions are as follows. The add-in was installed using setup.exe created in VS 2010 setup project, i.e. it was not a ClickOnce installation. The Visual Studio Tools for Office app was installed on the target PC and also was one of the prerequisites of the setup project. I believe the problem was caused by add-in project's signing certificate and strong name key (snk) file. The certificate was a temporary one issued by a developer. The snk file was created using this temporary certificate. I assume the generated add-in manifest worked only for a certain domain group users. I did not figure this out. What I did was I replaced the temporary certificate with the new one that company recently bought and created a new snk file. However, after deployment, add-in stopped working for all users. The error message was the same. That was when I started to look into the add-in manifest file. What I found was the manifest file created with new certificate had a SHA2 encryption algorithm. But, the VS 2010 can handle only earlier SHA1 version because the highest Framework version that it can target is FW 4. The SHA2 can be used only with FW 4.5 and higher versions. The solution was to use a three years old SHA1 certificate and snk file that were used when the add-in was updated last time in 2013. I found them in the company source code repository. Even the certificate expired last year the add-in manifest still works. By the way, SHA1 encryption algorithm was deprecated from January 2016. Nowadays, all new certificates for signing application are issued with other algorithms like SHA2.
Do the users it's not working for have Visual Studio Tools for Office (VSTO) installed?
See this:
Outlook Add-ins installation
I have tried the following on a C#-based Outlook addin called myaddin following this article:
mage –update myaddin.manifest –certfile mycert.pfx
mage.exe –update myaddin.vsto –appmanifest myaddin.manifest –certfile mycert.pfx
I can install it by manually creating registry keys that specify the path to myaddin.vsto with the supplied |vstolocal suffix under Software\Microsoft\Office\Outlook\Addins\myaddin and it works to install and run myaddin that way, however, some customers complain that when they run Outlook it starts the ClickOnce installer for myaddin.vsto and gives an error, but this should not happen with |vstolocal.
I was able to reproduce this problem by double-clicking myaddin.vsto, so I checked the myaddin.dll.manifest file and saw that there was a ClickOnce developer certificate referenced there. Could it have been confusing Outlook? I was able to get rid of this ClickOnce developer certificate reference by using a newer .NET 4.5 version of mage.exe to update the manifest. Now, if I double-click myaddin.vsto, it says that the publisher is not verified and gives me an install button.
Is this the proper way to go about the signing process and the installation process of an Office addin? Why does it complain that the publisher is not valid?
What is the version of VSTO on your development machine ?
Ensure that it is at the least 10.0.50903