1

Closed

Other-machine install from msi - signing issues?

description

Hello there,

I'm having a tough time building a usable PTVS installer from sources - I think it's the signing process that's preventing install. The msi install - running on a different PC - ultimately fails with:
An error occurred during the installation of assembly 'Microsoft.VisualStudio.ReplWindow, version="2.0.2.2013",culture="neutral",publicKeyToken="B03F5F7F11D50A3A", processorArchitecture="MSIL". The signature or catalog could not be verified or is not valid.
Some notes below - any tips greatly appreciately....

Cheers,
Tony

On my "dev host" (with VS2013 Pro),
...then ran (a slightly hacked - see (1) below) BuildRelease.ps1 from the Developer Command Prompt for VS2013, using:
C:\Temp\pytools_d78491fa6f86\Python\Setup>powershell -ExecutionPolicy RemoteSigned .\BuildRelease.ps1 c:\temp\ptvs_inst -skiptests
I then copied the debug and release .msis across the LAN to another host, but when I ran either I got as far as the "Publishing product Information" stage then a popup error (screenshot attached) saying:
An error occurred during the installation of assembly 'Microsoft.VisualStudio.ReplWindow, version="2.0.2.2013",culture="neutral",publicKeyToken="B03F5F7F11D50A3A", processorArchitecture="MSIL". The signature or catalog could not be verified or is not valid.
I am in a corporate environment - there might be some Windows security policies in affect that other people wouldn't have, but I'm (over-optimistically?) assuming if the signing is right is should pass verification and there'd be a specific message about security policies....

I tried a few things based on 'net searches, none of which have helped. For the record:
  • I tried signing the existing delay-signed msi, my best guess at which was:
makecert -r -sv key.pvk cert.spc
pvk2pfx -pvk key.pvk -spc cert.spc -pfx studio.pfx
signtool sign /f studio.pfx "PTVS VS 2013.msi"
  • I tried running sn -Vr Microsoft.VisualStudio.ReplWindow,B03F5F7F11D50A3A and rebuilding (idea from http://stackoverflow.com/questions/12100006/sgen-error-could-not-load-file-or-assembly-exception-from-hresult-0x801314/13009177#13009177)
  • I tried rebuilding the msi with strongly signed projects: in the VS IDE: I created a certificate, clicked each project's Properties / "Signing", add Strong Signing for the same certificate, but then found the build broke with errors about "does not contain a definition for" and "inaccessible due to its protection level" where some code used members from other projects, despite the namespace being identical, and the same certificate file being specified for all projects.
  • I found running sysinternals streams.exe -s -d . on the PTVS source root directory removed :Zone.Identifier:$DATA that were causing some early problems.
  • I tried changing app.config files to include <configuration> <runtime> <loadFromRemoteSources enabled="true"/>.
  • I abandoned the Developer Command Prompt for VS2013, attempted building from the VS2013 x64 Native Tools Command Prompt (build breaks), and from the VS2013 x86 Native Tools Command Prompt (builds but same problem running installer).
Needless to say I'm groping around pretty randomly, and not overly familiar with .NET, the signing or tools involved.

Weirdly, I sometimes had other issues, but re-unzipping the PTVS sources they haven't cropped up again. They included a need to:
  • "Open Pythontools.sln in VS Pro 2013, in Solution Explorer open Tests/TestUtilities. In References, delete Microsoft.System.Automation (which links to C:\Assemblies...) and Add Reference..., Browse... to the version under C:\Program Files (x86) (you can easily search). This resolves missing property: PowerShell.HadErrors."
  • Hack BuildRelease.ps1, because the candle.exe XML compiler failed when run by the BuildRelease.ps1-invoked msbuild: it did print out the candle invocation command line though, which worked when run directly from a console or from the powershell script, so I modified the script to invoke candle directly after any failed msbuild step.

file attachments

Closed Aug 4 at 11:21 PM by Zooba

comments

Zooba wrote Apr 18 at 9:34 PM

If you have admin rights on the target machine, you'll need to run the EnableSkipVerification.reg file. Because of the delay signing, you need to do this on every machine you want to use/install PTVS on.

If you want or need to avoid this, you'll have to sign the binaries. The easiest way to do this is by editing our ReleaseHelpers.psm1 file (somewhere under Common - not at my desk so I can't check) to invoke your signing process. Then use BuildRelease.ps1 -release. This part of the process is heavily optimised for us, so there's no better option than hacking at it.

Zooba wrote Apr 18 at 9:35 PM

Actually, one other option may be to edit Common.Build.settings (or maybe the C# specific file) to disable signing completely.

AJD wrote May 8 at 12:44 AM

Hi Zooba,

Sorry for the slow acknowledgement of your help here. I'm just back from a couple weeks on holiday. Will try out your suggestions and report outcomes soon....

Thank you very much,
Tony

AJD wrote May 9 at 5:59 AM

Hi Zooba,

I think for my purposes EnableSkipVerification.reg should be good enough - works manually, and I'll see if I can use it in a packaged installer later.... So much simpler ;-).

Thanks for your help!
Tony