sign temp exe files?

[aweber]

I inserted a temporary, exe (console) file to my installer that I have Custom Action logic to use to cleanup old an old installation (if found).

It was not added automatically to the list of files to be signed during the installer-builds. Should I add this file manually to be signed, or is that not necessary?

Thanks,
AJ

[aweber]

I actually can not find how to instruct AI to sign my exe that is set as a Temporary File. I tested my install and got this (which may or may not be from not-signing, but it DOES get called in that action) :

Code: Select all

Info 2769. Custom Action NetInstallerClass_x64 did not close 1 MSIHANDLEs. 
CustomAction NetInstallerClass_x64 returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

Note what's displayed on the screen is this:
"Error 1001. Exception occurred while initializing the installation: System.IO.FileNotFoundException: Could not load file or assembly file 'file///c:\Windows\system32\Files' or one of its dependencies. The system cannot find the file spcified.."

I don't know what that directory is. I haven't changed the .Net Installer class or its location. I have rebuilt the overall app and made other minor changes, but the installer class was being called just fine in previous tests! What is this error???

Using the latest AI: v15.4.1

[Eusebiu]

Hi AJ,

I'm afraid that the temporary files from a package cannot be digitally signed. However, I don't think that the custom action error that you get is caused by the lack of signature.

Please send me the .AIP (project file) and a verbose log of the installation to support at advancedinstaller dot com, so I can investigate them.

Best regards,
Eusebiu

[aweber]

Sent. Thank you.

[Eusebiu]

Hi,

Looking over the configuration of your custom action, I noticed that you specify the "NetInstallerClass_Config.xml" file in the "Config. file path" field which should be located in the %temp% folder, but this file is not present in your project. Are you sure that this file exists in the %temp% folder from your machine when the "NetInstallerClass_x64" custom action runs?

Best regards,
Eusebiu

[aweber]

@Eusebiu I have no idea what that file is or what it contains. I believe it was added there by simply configuring a .NET Installer Class Action. I do not require or access any XML files within my code.

The AI Help says:

Configure file path - This path represents the location where the .NetCustActLauncher will create the assembly's configuration file. The configuration file contains the .NetFramework required version.

I have to assume that the ".NetCustActLauncher" is coded and maintained by AI.

We did not have this issue until we upgraded to v15.4.1. Is that coincidence, or is there a bug in the newest version of AI???

Please increase the priority of this, it is holding-up delivery of our product now.

[Eusebiu]

Hi,

We did not make any change to this feature in the latest versions of Advanced Installer. From the related error message it seems one of your custom action dependencies is missing at run time.

Can you please try to debug your custom action code as explained in the "How to debug a .Net Installer Custom Action" tutorial and see which dependencies are missing?

Best regards,
Eusebiu

[aweber]

I do not think you understand.

As I said early in this topic, we didn't change the .Net Installer class. It was being called successfully in previous tests (with earlier versions of AI).

The class is included in our main DLL/Assembly. That main Assembly runs fine on the build machine - which has Visual Studio and Windows SDK installed. Installing Visual Studio on a VM or PC to test the installer-package would probably not tell us what file is missing, because Visual Studio would install many, many SDK and .Net files automatically. That post/tutorial would be appropriate if the class was launching, but the logic was not working properly.

The very first code-line in the Install method is to write a log message. That is not being written anymore (it previously generated the log just fine). So AI is not launching the .Net class.

There are some old posts in this forum where AI was not properly escaping the paths for the Smart Fields. That must have been fixed long ago, but is it possible a bug was re-introduced? The symptoms appear the same.

[Eusebiu]

Hi,

Indeed, this issue seems appear when a property which contains a folder path is sent as a parameter to a .NET Installer Class custom action. You can see more details and a solution for it in the "Why do I receive the 2869 error" FAQ.

Best regards,
Eusebiu

[aweber]

This is clearly a bug in how AI passes strings to the custom action. The workaround is possibly valid, but the developer would have to probably change some of the source code to compensate for paths that are possibly malformed.

Please file a bug report on this and have it fixed. It's a pretty common task for developers when working with strings, backslashes (such as those in paths) and escape patterns.

Your Help document shows passing [APPDIR] as the actual example for using passed parameters. I'm sure if you try that as documented, you will also encounter an error.

[Eusebiu]

Hi,

I already talked to our developers about this problem and I was informed that this is an Advanced Installer limitation that cannot be fixed. That is why we added an FAQ related to it in our user guide.

The backslash is used in Advanced Installer to escape the special characters and in this case it escapes the quote that comes after the [APPDIR" property. I am sorry for the inconvenience.

Best regards,
Eusebiu

[aweber]

So the logic is that if you are passing as string to the .Net Installer Custom Action that ends with a backslash (and if you are using an installer property - especially one that the user may input on one of the install forms - you may not know this at design/build time), you must escape that manually or add irrelevant characters to your string?

Your developers do not think they can check the string-parameter before starting the custom action? That sounds like a trivial break-fix.

At the bare minimum, please update your documentation and change your example in the Help file.

[Eusebiu]

Hi,

To run the .Net Installer Class custom actions we use the Microsoft support which receives the defined parameters. We use some code only to specify which .NET version to be used when that custom action is executed.

We could, indeed, verify the parameters that are sent to that custom action, but changing them would require a new indirection level which would complicate things a lot. However, if you add a space after a parameter to prevent this problem should not have any side effects.

Yes, we can change this in the documentation. Can you send me the link to the example from our user guide?

Best regards,
Eusebiu

[aweber]

if you add a space after a parameter to prevent this problem should not have any side effects.

You can not really make that statement. If you insert a space into a path-string being passed to a method, the difference can be significant, depending upon what the class is using that string for. It can be interpreted as a different path or a path may not be found or a filesystem search could fail...there are any number of things that the custom code could be using that string for, and it is important that AI pass accurate information to the methods.

The current version Help document ".NET Installer Class Argument Dialog" shows this:

[Eusebiu]

Hi,

Thank you for all your feedback.

We will consider your suggestions and try to make some improvements to this custom action in the future for a better the user experience.

If there is anything else that I can help you with, just let me know.

Best regards,
Eusebiu