Visual studio installer project code signing issue

jesdev7 6

I've been trying to get my .NET core program signed (the executable and dlls) with Visual Studio.
In the build directory everything works fine: the properties of the files show my digital signature.

However when I use the Visual Studio Installer Projects extension to make a .msi installer it doesn't seem to sign anything.
The extracted files of my program after running the installer on a clean machine don't have a digital signature.
I've tried using the "Sign the assembly" option in the project settings as well as using signtool.exe in the post build event.
Both options seem to give the same end result.

I'm using Visual Studio 2019 Professional. Maybe there's an option I'm missing but I can't seem to figure it out.
This is the first time I'm using code signing in a project.

David Lowndes 4,711 Reputation points

2022-08-03T15:02:43.483+00:00

The extracted files of my program after running the installer on a clean machine don't have a digital signature.

Are you sure your installer project is picking up the signed EXE/DLLs?
jesdev7 6 Reputation points

2022-08-04T14:13:17.687+00:00

I double checked the source path of the published items in the installer.
Turns out it actually used the files from the obj folder and not the bin folder.
So I explicitly defined the files in the obj folder to sign with signtool.exe in the post build event and those now get signed.
After rebuilding and running the installer though the files remain unsigned in the installation folder.
David Lowndes 4,711 Reputation points

2022-08-04T15:00:35.97+00:00

I don't know what else to suggest. I really can't imagine that the installer would be stripping the signature off. I'm not seeing that with my projects - though they're not .NET ones.
sho 1 Reputation point

2022-08-24T13:20:05.79+00:00

I'm having the same issues using Visual Studio 2022 (17.3.2).

Having the signtool sign the project dll's (and some nuget package dll's as the customer wants everything signed) in the bin\Release folder

Looking at the build process, using Sysiternals Process Monitor, it seems that the setup project gets the files from the obj\Release and packages directories instead.

Resolved it by Excluding the signed assemblies from the dependencies and removing Primary output and instead manually adding the required files from the bin\Release folder.
pekatete 1 Reputation point

2022-11-10T13:20:54.55+00:00

I have this issue too.
Seeing that the Microsoft Store now requires submissions of .msi apps to have the included app signed as well as the msi, this should really be addresses without deploying hacks.

With a .NET 6 (and now 7) winforms app, the contents of the **obj*\Release\net6.0-windows** are the *.dll and apphost.exe (to mention but a few). Adding a post-build event to sign those files does not work. Also signing the final output via post build even in app or a pre-build event to sign the input to the setup project (in the setup project) does not work.

2 answers

Tianyu Sun-MSFT 27,271 Reputation points Microsoft Vendor

2022-08-18T09:37:45.3+00:00
Hi @jesdev7 ,

Welcome to Microsoft Q&A forum.

Please try to select Release, and rebuild the Setup project under Release mode, then check if it works.

Best Regards,
Tianyu

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Please sign in to rate this answer.
Michael Pasternak 0 Reputation points

2024-03-26T16:33:39.1933333+00:00

Dear Microsoft team!

Please fix this BUG. Problem in Visual Studio 2022 even worse. The single solution that I found is to sign files in OBJ\RELESE folder.

It is very inconvenient
Sign in to comment
Michael Pasternak 0 Reputation points

2024-03-28T22:15:08.08+00:00

It does not work. Microsoft team, please fix this bug
Please sign in to rate this answer.

0 comments No comments
Sign in to comment