We are building an Outlook plugin in C#. It is built without problems in VS and signed with a temporary pfx certificate. We want to put the build process in Jenkins and have it run automatically.
We tried to run the VS solution with MSBuild. It works great on the development machine but in Jenkins there is an error:
Cannot import the following key file: OutlookPlugin_TemporaryKey.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_A688DC31A30F3EF1
We don't know how to specify the pfx password for the automated build. Or otherwise automate the sign process.
One solution we found was to open the project in VS on the same machine and as the same user as for the automated process and type the password. This doesn't work, probably because Jenkins wipes out the workspace every time.
If we try to compile without signing and then sign it afterwards, it complains that a ClickOnce assembly must be signed. It seems that Office plugins must use ClickOnce.
So, how to specify the pfx password somewhere in the build file ?
We use VS 2010 with Office Tools.
Create a file (either local or on a well known network share) containing the password as a property and reference that from the MSBuild script. Set permissions on the file such that only the build account can read that file. Note that anyone with admin access to the build machine or that knows the build account password will be able to read the password. Ultimately, there is no silver bullet here. If MSBuild can find/decrypt/whatever the password, a human will be able to, too.
If you are concerned about the security of the private key, consider separating the signing to a separate step and store the private key on a smartcard. It may be overkill but it is one of the best, commonly available protections available.
Otherwise, just add the password as a property. As you know the project files are just MSBuild scripts. For example:
<PropertyGroup>
<PfxPassword>password</PfxPassword>
</PropertyGroup>
<!-- Sample sign task -->
<SignTask>
<File>MyOutlookPlugin.dll</File>
<KeyFile>OutlookPlugin_TemporaryKey.pfx</KeyFile>
<Password>$(PfxPassword)</Password>
</SignTask>
See http://msdn.microsoft.com/en-us/library/ms171458(v=vs.80).aspx for more information about MSBuild properties.
We were having issues building the project with MSBuild and Bamboo. The fix for us was to remove the following line from the .csproj file.
<AssemblyOriginatorKeyFile>applicationcert.pfx</AssemblyOriginatorKeyFile>
Related
Certmgr shows I have my company's Symantec Class 3 SHA256 Code Signing CA installed, along with ones with Private in the name. Can I add this line to my Assembly Info:
[assembly: AssemblyKeyName("what name do I use here?")]
to strongly-name an assembly at build time? Would that find the public/private key pair in the certificate store and insert them into my assembly? Or do I have to extract the public/private key pair from the certificates and use the well-documented process for strong-naming that I see all over the Internet?
I've tried the above with variations of the company name but build fails with:
Keyset does not exist
Here is a blog post that explains what needs to be done: https://matthewdippel.blogspot.com/2017/09/howto-strong-name-sign-net-assembly.html
However, there’s an ugly catch-22. Running sn.exe -c, if it ends up changing the CSP, can only be done as an elevated user. However, that same elevated user cannot access the key in the personal store of your non-elevated account. So simply adding this to the pre-build or post-build and running Visual Studio under elevation results in the exact same Keyset not found error on build.
...
To get this working, you’ll need the script located at this gist. The only requirement is that you have the .Net Framework SDK 4.6, 4.6.1 or 4.6.2 installed. It uses it to get the path to the sn.exe file so that it’ll work regardless of how your system is configured.
I have create Outlook add-in for the client. I have created the setup project for that. When I run my setup file it prompts for the trust and show Publisher : Unknown. And after installation when I open Outlook it again prompts for VSTO trust and again shows Publisher: Unknown.
My questions are:
My client has SSL certificate from GoDaddy. Can I use this certificate to sign my code?
If I sign my code using the SSL Certificate, Will both the publisher became known?
I have found something to add certificate in project using project property > Signing > Add Certificate from file. Will this help me to sign my setup file and my VSTO file?
I have searched on google for this but it confused me more.
Can anyone help me to solve this?
Thanks in advance...!
You can't use an SSL certificate for code signing. Check this SO question for details: What SSL certificate do I need?
In regard to 3), you are probably refering to giving an assembly a strong name. This is different from code signing and serves a different purpose.
Closely related to Sign the ClickOnce manifests checkbox keeps defaulting to checked on publish. None of the answers listed in this question have assisted me.
I have two projects in my solution, as well as other reference projects. One project is a C# Windows Presentation Foundation (WPF) (output type Windows Application), and when I uncheck "Sign the ClickOnce manifests" it remains unchecked after being built.
The second project, which is also the startup project, is a Visual Studio Tools for Office (VSTO) project (output type defaults to Class Library and cannot be changed). When I uncheck "Sign the ClickOnce manifests" in it and then build the solution (or just the project), the option is checked again after the entire build process completes.
I am not familiar with the XML data in the .csproj file, but I have found a few things that might be related:
1.
In the .csproj file for the VSTO project, there is a comment section which states:
This section enables pre- and post-build steps. However, in VSTO use
MSBuild tasks instead of these properties.
The section defines <SignManifests>, <SignAssembly>, and <ManifestCertificateThumbprint>. The first two are false. The second has some unique key.
2.
After finding the comment about MSBuild tasks, I later found:
<!-- Include additional build rules for an Office application add-in. -->
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" />
And this is a very large file with multiple references to signing and such. The project in which the Signing option remains unchecked does not have this <Import Project> line in its .csproj file.
Issue
Now, I'm not fully aware of what the .targets file is all about and am unwilling to go butchering it in search of a solution until I know what I'm after. Could this file be the cause of my problem? If so, how can I modify it to stop it from getting in my way?
If not, has anyone encountered this before that can provide a solution?
Edit:
I just read How to not sign a ClickOnce manifest, which talks again about publishing. I am still curious if I can turn it off of my builds. I have no qualms about signing the application when I publish it, but I would prefer to build it without the default occurring.
Here's an article by a VSTO team member. https://blogs.msdn.microsoft.com/vsto/2009/04/29/signing-and-re-signing-manifests-in-clickonce-saurabh-bhatia/
The explanation is that VSTO requires signing for ClickOnce deployments, because the add-in must run under a heightened security model. The article goes into much more detail.
I am desperately trying to deploy an ActiveX for IE developed in C# as a CAB archive. I have read many resources (some of them from StackOverflow) and it appears a lot of people are having the same problems. I have tried 3 solutions: a) creating a CAB VS project, b) manually creating a CAB using CABARC with a COM registration in INF and c) manually creating a CAB with launching msiexec. None of them worked. I even tried d) creating a bootstrapper which launches msiexec to no avail (because some people suggested simply launching msiexec on Vista can't work).
I am running Windows Vista but my project fails to run even on IE6 on XP.
When I install ActiveX using MSI, all is fine on ALL Windows. Apparently CAB thing is not working and I could not find a proper way to debug this whole process yet.
Any help is appreciated.
Update: Note that this old but excellent answer is still a very good outline for how to approach solving this problem, at least as along the evolutionary scale as Win7 and IE11. I just succeeded making it all work using the Answerer's Firebreath.org toolset as a jumping off point. It's not simple but it can be done. I've added a reference to that project to the reference list below since it may make a more logical jumping off point for current developers than this overview is.
Hooray - I have just finished an identical project, so you'll be pleased to know that it's actually possible. I have only tested this on XP - I understand there may be issues where Vista/7 don't allow msiexec to be called.
Given that you have an assembly correctly exposing a COM interface, I did the following:
Strong-named the assembly.
Created an INF file
Created an MSI using the Visual Studio 2008 "Setup Project" template.
Created a CAB file using "iexpress.exe" bundled with Windows XP.
Create INF file
The *.inf file I used looks like:
[version]
signature="$CHICAGO$"
AdvancedINF=2.0
[Setup Hooks]
install=install
[install]
run=msiexec.exe /package """%EXTRACT_DIR%\SampInst.msi""" /qn
The only bit you should need to change is the SampInst.msi. Note I would use an 8.3 filename, as long filenames can cause issues. While testing, I would not use the qn switch either, as that is a silent install.
Create the Installer
The installer has to do only one thing, and that is register the assembly by calling RegAsm on it. Most installers will provide some method to easily do this. For example, an installer created through VS 2008 will simply need to have the “Register” property of the assembly set to “vsdrpCOM”. Note that vsdrpCOM should be chosen as it generates the appropriate registry entries at build-time. The vsdrpCOMSelfRegistration setting is likely to fail as it calls RegAsm at run-time, and will thus not work for non-administrators.
Package the installer into a CAB file
This can be done by any cab archiver. Windows XP contains iexpress.exe, a wizard driven archiver, while Microsoft’s CAB SDK contains cabarc.exe. Other 3rd-party tools are also available.
Note that you will need to reserve space in the CAB file for code-signing if you are going to sign the CAB.
You will need to CAB the INF file, and the MSI file. You will not need to CAB the Setup.Exe file.
Handy hint: The VS2008 Setup Project project type allows you to set a post-build step in the properties, so you can build and CAB in a single step. My post-build step looks like:
cd "$(ProjectDir)"
"%WINDIR%\System32\Makecab.exe" /f "VboCslib.ddf"
The DDF file format is documented.
Sample HTML page
The object tag is used to point to the cab file containing the installer. A very simple HTML page which would deploy an ActiveXControl would be:
<html>
<head></head>
<body>
<!--
ID : The id of the ActiveX control to be used in JavaScript.
CLASSID : The GUID associated with the ActiveX control.
CODEBASE: The location containing the CAB installer for the ActiveX
control. This could be a URL, or a relative path.
-->
<OBJECT ID="MyActiveXControl"
CLASSID="CLSID:FC36FAE1-48E0-4f6b-B469-E1B5A8C6D1AC"
CODEBASE="cabfiles\SampleCabFile.CAB#version=1,0,0,0">
</OBJECT>
<script>
MyActiveXControl.SomeMethod();
</script>
</body>
</html>
Handy hints
Ensure your installer installs on a "per-user" basis, not a "per-machine" basis. This will make it more likely to install if the user does not have admin privileges.
Trouble-shooting
Internet Explorer 6 actually provides a really useful diagnostic aid. Clear your Temporary Internet Files, then navigate to the web-page. If the installation does not work, go to your temporary internet files and you will see a couple of files in there. One of these will be an error log starting ?CodeDownloadErrorLog. Drag it to your desktop and open it in notepad, and it will give details on what it was trying to do when it failed.
References
Microsoft KB247257 – Steps for signing a .cab file
MSDN – About INF File Architecture
SN.EXE - Code Strong Programs with Strong Names
Nikolkos Craft – How To: Deploy .NET ActiveX Control
CodeProject – Create ActiveX .NET Step by Step
CodeProject – Downloading C# ActiveX Components through CAB file
MSDN - ALLUSERS Property (Windows)
MSDN – Non-Admin ActiveX Controls
MSDN – Microsoft Cabinet Format
Update: Firebreath.org has a toolset for generating browser plugins for many platforms. The IE/ActiveX code to solve the problem posed here is just a subset. But as of 6 Nov 2014, I found it easier to start with Firebreath and its instructions than to try to build up my dev environment and roll all my own solutions from scratch.
I have a collection of ClickOnce packages in a publish folder on a network drive and need to move them all to another server (our DR machine).
After copy/pasting the whole directory and running the setups on the new machine I get an error message stating that it cannot find the old path:
Activation of
...MyClickOnceApp.application resulted
in exception. Following failure
messages were detected:
+ Downloading file://oldMachine/c$/MyClickOnceApp.application did not succeed.
+ Could not find a part of the path '\\oldMachine\c$\MyClickOnceApp.application'.
Once I change the installation URL to point at my new machine, I get another error:
Manifest XML signature is not valid.
+ The digital signature of the object did not verify.
I've tried using MageUI.exe, to modify the deployment URL, but it asks for a certificate, which I don't have.
What am I doing wrong and how do I successfully move published ClickOnce packages?
I found a solution:
Firstly, using MageUI, I changed the "Start Location" under "Deployment Options". On saving, it prompted me to sign with a key, which I created there and then. I then ran the setup.exe file, and it worked without fail.
After checking which files had changed, I realised it was only the one file: the application manifest file (myAppName.application). The only things that changed in the file were the deployment provider and the signature (which is what I changed in MageUI).
Once I realised this was how to do it, I used the command line version of MageUI called Mage.exe, which comes with the SDK.
Below is the batch file I created to do all of this on the command line:
REM Set the enviroment
call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"
REM Update the deployment provider URL
mage -Update %1.application -pu %2
REM Sign the manifest with our key
mage -Sign %1.application -CertFile C:\AppKey.pfx -Password myPw
I can now use this to run against all of my published applications in a quick and easy way. I hope this helps.
Without getting into too much detail, this should get you going.
ClickOnce manifests must be signed with a certificate for security reasons. You can purchase a code signing certificate or generate a test one. The main drawback of a test certificate is that your application publisher will appear as "Unknown" rather than your company's name.
In Visual Studio, open your project's properties and go to the "Signing" tab, select "Sign the ClickOnce manifests", and "Create Test Certificate". Next, click "More Details" to bring up a dialog and click "Install Certificate". This will run you through a wizard to get your test cert in your store. Make sure you put it in the "Personal" store.
Now you can use MageUI to edit your manifests. Any time you save it will prompt you to sign the manifests but you should now be able to select the test cert you just stored. Always edit/sign the application manifest before editing/signing the deployment manifest. This is confusing because the application manifest isn't the file with the .application extension.
Good luck!
I would expect to have to do the following:
Copy current folder contents to new location
For each app:-
Change 'Installation folder' to the new location
Publish as a new version
Change 'Publishing folder' to the new location
Publish as a new version
New setups run from the new folder should work and existing ones should update to look in the correct place.
All this is untested, but I'm pretty sure that's what I did previously...
Edit:
Obviously, you'll have to run these in parallel for a certain amount of time, but as it's an internal app the worst that will happen when you finally switch over to the new location is that you'll have to inform the user of the new location to obtain a 'fixed' app
I believe that you do have a certificate. You need one to create a ClickOnce deployment. Visual Studio may have autocreated a self-signed one for you. I'm not too familiar with the process, hopefully someone with a more definitive answer will chip in. Also, have you tried the MageUI tool, maybe it will be more obvious what you need to do using a GUI.