|
Norman Neubert
Posts: 13
Joined: 2022-06-09
|
Hi, I have an Add-in Express that works fine in debug and release. I have an installer for this project which also works fine, installs the addin and runs as it should when Excel is opened.
Today I added my EV certificate via "Add-in Express" / Signing options. It signs the Dlls correctly and when the setup program is run it installs the Add-in in the correct folder. It all looks just like the unsigned version.
But when I starte Excel the addin is deactivated with the error:
C:\Program Files (x86)\MyAddin\MyAddinName\adxloader.dll
Nicht geladen. Währens des Ladens des COM-Addin-Ins ist ein Laufzeitfehler aufgetreten.
Not loaded. A runtime error occurred while loading the COM-Addin-In.
What is the problem here and how can I solve it?
Thanks in advance
Norman |
|
|
Norman Neubert
Posts: 13
Joined: 2022-06-09
|
Additional info:
I use SHA-1.
I tried the following:
- "Add-in Express" / Signing options --> Activated signing with SHA-1
- I build the msi/setup and install the Add-in.
- It fails to start as described above, i get the "Not loaded. A runtime error occurred while loading the COM-Addin-In." error.
- I then removed the signature process via "Add-in Express" / Signing options
- I built the Add-in
- I then signed adxloader.dll, adxloader64.dll and my Add-in DLL as well as another DLL that is built in the process. This was done manually. I have a batch that does the job. This is how I do it:
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86\signtool.exe" sign /f "d:\Development\Zertifikat\mycertificate.cer" /t http://timestamp.sectigo.com /csp "eToken Base Cryptographic Provider" /k "[{{MyPassword}}]=Sectigo_MySigDate" ".\adxloader.dll"
--> Same thing for the other 3 files.
After signing I copy the 4 files to my installation folder of the plugin. I run Excel and activate the plugin again via Options / Addins.
The plugin works! It must be something in the Add-in Express signing process that corrupts the dlls so they dont work. Any idea what this could be?
I would also be happy if i could do this workaround (which I can't currently).
- Build Add-In
- Call my batch to sign
- Build Setup Program
The problem here is that the setup program builds the Add-in, too. This of course removes the signatures again. Can I somehow turn off that the build project also builds the Add-in?
I would really be happy to get help as the plugin cannot be used by our customers if they are not signed.
Thanks Norman |
|
|
Norman Neubert
Posts: 13
Joined: 2022-06-09
|
|
PS: I tried the post build event in the setup project to call my batch: Seems the post build event is called BEFORE the Add-in is built so the signatures get removed again. :( |
|
|
Norman Neubert
Posts: 13
Joined: 2022-06-09
|
Found the solution:
- In the deployment project: Add PreBuildEvent with your batch that signs your files. Please be aware that you have to sign these:
...\Project\obj\Release\XXX-Addin.dll
...\Project\SubprojectDLL1\bin\Release\SubprojectDLL1.dll
...\Project\SubprojectDLL2\bin\Release\SubprojectDLL2.dll
...\Project\Loader\adxloader64.dll
...\Project\Loader\adxloader.dll
Subproject1/2 of course is only needed, if you have any. Please be aware that the XXX-Addin.dll has to be signed in the folder OBJ, the suproject dlls have to be signed in BIN. Maybe its only like that in my project, but check it. Took me several installs to understand where the project picks the files from. Thinking about it, I probably could have read it in the project file itself.
- Then: right click on the deployment project and then click properties
- Click on "Configuration manager".
- I had to remove all marked projects to get the build to do the right thing with my PreBuildEvent batch file.
So I first build my Add-in.
Then I build my deployment project. the deployment project then runs the PreBuildEvent batch, signs everything relevant, then the deployment project itself is run. Everything stays signed as it should.
And the best thing: The Add-in works when I install it :)
Another benefit of using the batch solution to sign files is that you can add your token password to the batch so you dont always have to enter the password. But of course only do that in a secure environment where noone has access to the batch file.
I still wonder why "Add-in Express" / Signing options doesn't work, but I guess it makes no difference anymore for me.
Have a nice day
Norman |
|
|
Andrei Smolin
Add-in Express team
Posts: 18833
Joined: 2006-05-11
|
Hello Norman,
Norman Neubert writes:
C:\Program Files (x86)\MyAddin\MyAddinName\adxloader.dll
Nicht geladen. Währens des Ladens des COM-Addin-Ins ist ein Laufzeitfehler aufgetreten.
Not loaded. A runtime error occurred while loading the COM-Addin-In.
There are several scenarios that cause the add-in not to load. Some of them are reflected in adxloader.log; it is recommended to check this log file before continuing.
Norman Neubert writes:
I use SHA-1.
It is recommended to use SHA256 with modern systems.
Norman Neubert writes:
It must be something in the Add-in Express signing process that corrupts the dlls so they dont work. Any idea what this could be?
Such a problem might occur if you use Add-in Express 10.1 or earlier; that issue was fixed in Add-in Express 10.2. Note however that this Add-in Express version doesn't support SHA384.
Norman Neubert writes:
Please be aware that the XXX-Addin.dll has to be signed in the folder OBJ, the suproject dlls have to be signed in BIN. Maybe its only like that in my project
As far as I understand, this is caused by Visual Studio: if you need to do something with the output assembly in the PostBuild event, you should do this in the OBJ folder. I'm not sure whether all Visual Studio versions demonstrate this behavior. Anyway, there's a simple workaround: since all these things are required for add-in deployment, you can sign all the files in the pre-build event of the setup project.
Regards from Poland (GMT+1),
Andrei Smolin
Add-in Express Team Leader |
|
Forums
Topics
Search
Help
Login
Register