About IlkkaV

IlkkaV · ‎Nov 27, 2015

...and now after another cup of coffee I just ran a SetProperty action setting MYPROPERTY to [MYPROPERTY] after the managed custom action and that's it.

IlkkaV · ‎Nov 27, 2015

If I run the custom action, it does set the property just fine and the control which has the property value as its Enabled condition gets enabled if I back away to the previous dialog page and return to the one where the custom action was run. So if I could just trigger re-evaluation of conditions after setting that property from a custom action like it does if I have a control triggering a SetProperty action on the same page, my problem would be solved.

IlkkaV · ‎Nov 26, 2015

I'm struggling with an issue where I have a managed code custom action (a C# DLL) that's doing some DB connectivity validation for me. The DLL itself runs successfully and its return value is also stored into a property I defined when assigning a custom method signature. According to MSI log the return value is stored into a property with a proper value, but still any controls or events depending on that property value aren't evaluated, i.e. a control that's supposed to be enabled after a successful connectivity check doesn't get enabled. If I add a separate button that set the same property value with a SetProperty action, everything works like it should. How could I get the managed custom action result to take effect in the UI?

IlkkaV · ‎Nov 25, 2015

Thanks again hidenori, seems to work fine once again 🙂

IlkkaV · ‎Nov 24, 2015

Unfortunately there's a little problem with that. Even though I've hidden the actual property containing the password as well as the property used for passing custom action data, it's still written to the log at this point: [CODE]MSI (s) (E4:A8) [12:05:59:540]: Executing op: CustomActionSchedule(Action=CreatePasswordAlias,ActionType=3073,Source=BinaryData,Target=f10,CustomActionData= )[/CODE] Any ideas on how to solve this one?

IlkkaV · ‎Nov 23, 2015

hidenori wrote: Have you considered using the MsiHiddenProperties property? I forgot about that one, it's just the thing I need! Thanks 🙂

IlkkaV · ‎Nov 23, 2015

Hi I have a Basic MSI project and a slight dilemma there. I'd need to ask user credentials during the UI phase and pass them to a custom action in the execute phase to be handled. However, doing that the normal way using CustomActionData would cause those credentials (especially the password) to be written to the MSI log file. I wouldn't like to disable MSI logging as that provides useful troubleshooting information but having passwords there is an obvious security issue. Is there a way to prevent certain data from being written to the log in clear text? Or do I have to write a separate application that's launched during the execute phase to request those credentials?

IlkkaV · ‎Aug 28, 2015

Yes, it's a Basic MSI project. I'll check the thread you linked, thanks for the tip!

IlkkaV · ‎Aug 27, 2015

Is there a way to filter out localDB instances for the SQL Server browser/login dialog? The product I'm working on doesn't currently support localDB, so I'd like to display only valid choices for a server in the menu. Any tips would be much appreciated.

IlkkaV · ‎Aug 06, 2015

Thanks Josh, that was it 🙂 I've written so much InstallScript custom actions for basic MSI projects that I had automatically set HWND as the parameter there and failed to spot that while wondering what's wrong.

IlkkaV · ‎Aug 05, 2015

I'm having an issue running even the most simple InstallScript Suite actions in an Advanced UI/Suite project. Log shows the following when running the action: [CODE]8-5-2015[02:15:32 PM]: Running event 'Test' 8-5-2015[02:15:32 PM]: Launching InstallScript action in function 'Test' 8-5-2015[02:15:32 PM]: Engine: request for proxy handler, 0, 0 8-5-2015[02:15:33 PM]: Action returned value 0x80020005 8-5-2015[02:15:33 PM]: Action 'Test' returned status 0x80070643[/CODE] That function consists of a single SuiteLogInfo call in a nearly-stock Setup.rul. There seems to be something off with this particular project as I had to specifically define paths to default InstallShield libraries to get it to even compile and a similar test function in a freshly created Suite project works fine. However, reconstructing the project from scratch will be quite a task, so any hints that could help with restoring the current project file into a usable state would be highly appreciated.

IlkkaV · ‎Jan 02, 2015

MichaelU wrote: Have either of you tried InstallShield 2014 SP1 in your scenarios? We did fix at least one rare setup.exe crash that manifested in ntdll.dll in the service pack, so it's possible that rebuilding with it will resolve the error. I upgraded to 2014 SP1 today. Now I just need to gather some data from a few days' worth of test runs.

IlkkaV · ‎Oct 23, 2014

Problem solved. It was indeed settings, particularly this part: "4. Went to Components view and marked the newly created component as 64 bit". I thought I had done exactly that, but a closer review revealed that I had accidentally moved the 32-bit version to the 64-bit folder and marked that as 64-bit. The component for the DSN I wanted to make was still marked as 32-bit and it's not that much of a surprise that it did indeed install 32-bit DSN in that case. Now that the components are in their correct locations and have the correct settings, the data source is just fine. Thanks Cary R for your help.

IlkkaV · ‎Oct 23, 2014

So much for the importing idea as I can't seem to locate any option or tool for doing so. Is it just the lack of coffee or isn't there an option for that? All I can do is create a new DSN and configure it from scratch.

IlkkaV · ‎Oct 22, 2014

Cary R wrote: I can see myself in the near future needing to do this exact task, so I just gave this a quick try with the following steps: 1. Created a new project 2. Set TemplateSummary to x64;1033 3. Imported a DSN from the ODBC Resources view in InstallShield 4. Went to Components view and marked the newly created component as 64 bit 5. Installed It successfully created it as a 64 bit System DSN. So, based on your steps listed, it should work. Maybe the logfile will show something going wrong during the InstallODBC action? I would also recommend a sanity check by viewing the package in Direct Edit mode to make sure everything looks like it should, since Release flags are involved. Thanks for trying it out. It's good to know that the functionality works properly and I just need to check what bit is still wrong in my project. I also created my data source from scratch in InstallShield, so I'll try importing an existing functional DSN and see what part I was missing in my manual configuration.

Online Status	Offline
Date Last Visited	‎Mar 18, 2019 12:11 PM

Re: Managed custom action result property doesn't work like a regular property

Re: Managed custom action result property doesn't work like a regular property

Managed custom action result property doesn't work like a regular property

Re: Preventing passwords from getting written to log files

Re: Preventing passwords from getting written to log files

Re: Preventing passwords from getting written to log files

Preventing passwords from getting written to log files

Re: Filtering localDB instances from the SQL Server login dialog

Filtering localDB instances from the SQL Server login dialog

Re: Problem with InstallScript actions in a Suite project

Problem with InstallScript actions in a Suite project

Re: Random ntdll.dll crashes in installations created with InstallShield 2014

Re: How to create a 64-bit ODBC entry?

Re: How to create a 64-bit ODBC entry?

Re: How to create a 64-bit ODBC entry?

Re: Managed custom action result property doesn't work like a regular property

Re: Managed custom action result property doesn't work like a regular property

Managed custom action result property doesn't work like a regular property

Re: Preventing passwords from getting written to log files

Re: Preventing passwords from getting written to log files

Re: Preventing passwords from getting written to log files

Preventing passwords from getting written to log files

Re: Filtering localDB instances from the SQL Server login dialog

Filtering localDB instances from the SQL Server login dialog

Re: Problem with InstallScript actions in a Suite project