Signing VSTO manifests not working

[andrewmolyneux]

I've got SignService up and running and I've successfully signed a few DLL and MSI files from an Azure DevOps pipeline, so it looks like everything is basically working. However, we need to sign an add-in built using VSTO and I'm not having much luck with that. I've followed the instructions under the "ClickOnce" heading in README.md to pack everything up in a zip file with a ".clickonce" extension but SignService is returning a 404 error when I try to sign it.

Learning from my previous experience (issue #216) I went straight to Application Insights and I'm seeing the following error:

Field	Value
problemId	System.ComponentModel.Win32Exception at SignService.SigningTools.MageSignService.RunSignTool
operationName	POST Sign/SignFile
outerMessage	One or more errors occurred. (The system cannot find the file specified.)

Digging through the stack trace, I found this:

Field	Value
assembly	SignService, Version=1.2.0.0, Culture=neutral, PublicKeyToken=null
fileName	D:\Git\SignService\src\SignService\SigningTools\MageSignService.cs
level	2
line	247
method	SignService.SigningTools.MageSignService.RunSignTool

That is, this line of code which seems to be attempting to start mage.exe.

I can provide a full stack trace if required, but it looks like it can't find mage.exe. I've used Kudu to browse the file system on the App Service and mage.exe is definitely there in the tools/SDK/x86 subdirectory, so I'm kind of stuck now.

[andrewmolyneux]

Note: I built SignService on my local machine and published it from VS2019. Once I've got it working I'll set it up properly using a cloned repo and a build pipeline, I promise 😀

[clairernovotny]

The code is looking for mage here: magetoolPath = Path.Combine(hostingEnvironment.ContentRootPath, "tools\\SDK\\mage.exe"). It's a directory underneath the content root, and the pre-build steps should be copying it there.

It should not be in an x86 subdirectory though.

[andrewmolyneux]

Hmm maybe I did something wrong when I published the service. I'll pull the latest changes from master, rebuild and republish and see what happens.

[andrewmolyneux]

OK I'm now on the latest commit on master (looks familiar 😀), I've rebuilt and republished the service from VS2019 and I'm still seeing the x86 and x64 subdirectories in tools/SDK (and no files in tools/SDK itself). I downloaded site/wwwroot and this is what I'm seeing, in case that helps:

Maybe publishing from VS2019 isn't doing the right things for some reason?
I've also tried manually copying mage.exe to the tools/SDK directory, which I expected to get me past the "file not found" error, and I'm now seeing a different error. This one has the problemId "System.InvalidOperationException at SignService.Utils.ManifestSigner.SignFile" and the description is "Late bound operations cannot be performed on types or methods for which ContainsGenericParameters is true". As far as I can tell the exception is being thrown when executing this line of code in Utils/CryptoConfigShims.cs. I'm afraid I'm completely stumped.

[andrewmolyneux]

I also tried copying all the files (not just mage.exe) from tools/SDK/x86 into tools/SDK to see if that made any difference. Sadly it didn't - I got the same error.

[mgiles]

I'm also hitting this error, and am also seeing that mage.exe is in the x86 folder and not directly in the SDK folder. As a workaround to get things running, I changed this line:

magetoolPath = Path.Combine(hostingEnvironment.ContentRootPath, "tools\\SDK\\mage.exe")

to this:

magetoolPath = Path.Combine(hostingEnvironment.ContentRootPath, "tools\\SDK\\x86\\mage.exe")

The above changed got me past the "The system cannot find the file specified" error.

Here's my understanding of the cause, so far. I'm an MSBuild noob, so bear with me:

1. SignService.csproj line 58 declares mage.exe as an SdkFile86 item
2. SignService.csproj line 90 copies all SdkFile86 items into tools\SDK\x86
3. That tools folder is, I assume, pushed to wwwroot during publish

It looks like this commit split SdkFile into SdkFile86 and SdkFile64. Looking at that change, I can see at least a couple of options:

1. Modify MageSignService.cs to look for mage.exe in tools\SDK\x86
2. Add the SdkFile item group back (see linked commit), include mage.exe in it, and copy SdkFile items to tools\SDK during the build

I'm not familiar enough with what's going on to know what the "right" place for that executable is, but I'm happy to put up a PR with either of those changes if one of them seems like an appropriate solution.

[mgiles]

As for the "Late bound operations" exception from CryptoConfigShims, I wrote a description of what I think is going wrong, and possible solutions, in #266. Apologies if splitting the conversation is annoying, it seemed worth having two separate issues for two separate (and I think unrelated) errors. Feel free to close #266 if you'd prefer to keep both conversations here.

@andrewmolyneux Not sure if you ended up getting past that error in your setup, but if not you may be interested in #266. That was the last step for me to get signing working for VSTO/ClickOnce builds.

[andrewmolyneux]

@mgiles Thanks for this - I never got to the bottom of this issue but we're going to need to ship a release of the product I'm working on soon so it's kind of urgent now 😆 I more or less forgot where I was up to so I've deleted the app and its resource group with a view to starting over, and now I can't even get it to deploy (using the ArmDeploy project) but I'll certainly update any relevant issues when I get to that point.

[andrewmolyneux]

@clairernovotny Any thoughts on Matt's comment above, regarding the paths where tools are deployed? I'm currently restarting the whole deployment process with a view to deploying via Azure Pipelines rather than publishing from Visual Studio (as I did the last time around) and I'm wondering if you can confirm that this is a bug? Or are Matt and I both doing something wrong?