PDA

View Full Version : Files in Binary Table are not available in SUPPORTDIR anymore



lysemose
04-24-2006, 11:04 AM
My deferred CA with sequence number 5920 attempts to run a dll stored in the Binary Table and streamed into SUPPORTDIR during setup initialization,
but the dll is not available in SUPPORTDIR

I reported this issue for IS12 Beta 1 - but I do not think there was taken any actions :-(

Christopher Painter
04-24-2006, 11:59 AM
Files listed in the binary table have never been available in the SUPPORTDIR folder, files in the ISSetupFile table are. They are made available by the ISSetupFilesExtract InstallShield CustomAction.

lysemose
04-25-2006, 07:49 AM
Sorry for the mistake - the .dll is stored in the ISSetupFilesExtract table but is not available in SUPPORTDIR when my deferred CA is executed.

It works fine in IS11.5 and before.

Christopher Painter
04-25-2006, 08:38 AM
Check that the CA that does the extraction is still there and look at the MSI log file to see if it gives any error messages when it tries to extract them.

lysemose
04-26-2006, 04:35 AM
I checked the MSI log file and verified that the CA extracts my helper.dll into SUPPORTDIR {FC3F29D6-6C16-4718-8F06-5CF6F17316D2} and verified that the folder existed with my helper.dll.

The next thing I did was to add a messagebox to my CA, and now I can see that the SUPPORTDIR property has changed to the temp folder {5F7A7CAF-32FA-4600-8511-139A11AC9730} which does not contain my helper.dll.

I have zipped and attached the log file and the messagebox.

Christopher Painter
04-26-2006, 07:32 AM
The first GUID is SUPPORTDIR and I don't see it being changed in the log. The second GUID you mentioned is for 'support files' and is a different thing. What is the name of the custom action that is failing? I don't see the problem. Try /l*v to get a more detailed log.

lysemose
04-26-2006, 09:53 AM
The name of the failing CA is "AfterExecute".
Please find attached a new log file and my setup.rul with the failing CA.

Christopher Painter
04-26-2006, 09:59 AM
Your using the Macro Constant SUPPORTDIR instead of the MSI Property SUPPORTDIR. I havn't used this in InstallScript CA's in a long time but I suspect they have different meanings. Try this... Put a couple message boxes in their. One that displays SUPPORTDIR and one that calls MsiGetProperty() ( assign the property "SUPPORTDIR" to a local variable ) and displays that. See if they are different.

This does seem a little wierd, but I havn't used it recently enough to just spout off an answer.

lysemose
04-26-2006, 10:24 AM
I added the next lines to my CA, but the MessageBox shows a blank svSupportDir. I do not think that the property is available for the deferred CA ?

MsiGetProperty(hInstall, "SUPPORTDIR", svSupportDir, nvSize);
MessageBox( "SupportDir = " + svSupportDir, INFORMATION);

Christopher Painter
04-26-2006, 10:37 AM
I was thinking about that, but it's a directory property so I don't see why it wouldn't. Eitherway you can schedule a customaction prior to your CA and set the CustomActionData property to the value of [SUPPORTDIR] and try again.

Still, it seems that just plain SUPPORTDIR should work.

lysemose
04-28-2006, 12:55 AM
I made a fresh basic MSI project in IS10.5 that does nothing else than showing SUPPORTDIR in a messagebox as a deferred CA after Schedule Reboot in the Execute sequence.

Building and running CA-Test-IS105.msi shows the correct SUPPORTDIR.

Then I migrate the project to IS120 and build the project.
Running CA-Test-IS120.msi does NOT show the correct SUPPORTDIR.

I have zipped and attached projects, bitmaps and MSI for both versions.

My conclusion is that IS12 does not set the InstallScript System Variable SUPPORTDIR in my deferred CA.

I consider this as a critical bug that needs to be fixed before release of IS12.

Please confirm !!!!

Christopher Painter
04-28-2006, 01:21 AM
Does it work if you create a fresh basic MSI in 12? I'm wondering if its a bug int the InstallScript refactoring or a bug in the project conversion.

lysemose
04-28-2006, 01:55 AM
A just created fresh basic MSI project in IS12 Beta2 which has the same problem.

I tried to upload the .zip but got the error message:
"File Too Large. Limit for this filetype is 1.95 MB. Your file is 14.36 MB."

MichaelU
04-28-2006, 10:54 AM
I've just tested this, and I do want to clarify that Chris has pointed you in the right direction. The following code returns two different directories when called as an immediate action, and one empty (the MSI one) when called as a deferred. The InstallScript variable SUPPORTDIR is never what you want in a basic msi if you're looking for your Support Files.
function TestSupportdir(hMSI)
string szSupportDir;
number nLen;
begin
nLen = 256;
MsiGetProperty(hMSI, "SUPPORTDIR", szSupportDir, nLen);
SprintfBox(INFORMATION, "SUPPORTDIR", "MSI: %s\nIS: %s", szSupportDir, SUPPORTDIR);
end;Obviously the empty SUPPORTDIR property during a deferred custom action is not desirable. I'm raising this internally and expect to have more to say later.

MichaelU
04-28-2006, 03:35 PM
Alright, this isn't final yet - we're going to look into finalizing the decision early next week - but I expect our story is going to follow MSI pretty directly.

Deferred custom actions (including Commit and Rollback) generally lack access to the Property table, whether directly or through MsiGetProperty. Since IS12 custom actions are now even more completely just a dll custom action (no external running engine to communicate with), this applies to them more directly than before.

If you want to access a property, such as SUPPORTDIR, you need to pass it as CustomActionData. You do this by scheduling an immediate execution SetProperty custom action (or InstallScript with a MsiSetProperty, etc.) to set a property matching the name of the custom action. this value of this propery is then available in the property CustomActionData. So for example you could set MyCustomActionName to [SUPPORTDIR], and then use MsiGetProperty(hMSI, "CustomActionData", szSupportDir, nLen) instead of "SUPPORTDIR".

See http://www.installshield.com/news/newsletter/0308-articles/CustomActionData.asp for more details.

lysemose
04-30-2006, 05:33 AM
To me it looks as a dramatic change in the way CA's are working in IS12 compared to IS10,IS10.5,IS11 and IS11.5.

The consequence is broken backwards compatibility and the need to re-write
the affected projects when migrating to IS12.

One of the big problems is that you get no warnings or errors during migration, build or installation (depends on implementation).

Why did you actually do this change ?

Christopher Painter
04-30-2006, 10:05 AM
The change really, really needed to be done. I understand it will break some code, but that code should be refactored as MichaelU suggests and then we should move on Sure it's a pain to lose access to global variables originating from a IPC mechanism hosted in immeadiate execution, but it really is the "proper" MSI way to do a CustomActionData property set prior to calling a deferred CA.

Christopher Painter
04-30-2006, 03:44 PM
I was thinking about this a little. Perhaps there should be a new InstallScript function that splits CustomActionData properties into a collection. Also perhaps if SUPPORTDIR is null the language could check the collection to see if it has a SUPPORTDIR member defined and return it's value.

This could clearly prescribe a pattern to the developer and cut down on the amount of plumbing that has to be implemented to use the pattern.

MichaelU
05-01-2006, 05:16 PM
I think Chris at least strongly hinted at all the reasons why this had to happen. I agree that it does suck that SUPPORTDIR (the InstallScript variable) has a silent change in behavior between 11.5 and 12.0. But for all intents and purposes SUPPORTDIR is a global variable. The changes that increase the robustness of the engine kill global variables.

The only behavior question left is whether there should be some magic that sets SUPPORTDIR to MsiGetProperty(... "SUPPORTDIR" ...) to try to mimic 11.5 behavior, and I'd argue there shouldn't be. Why? Because of the deferred scenario. If SUPPORTDIR breaks in all cases, you're forced to consciously think of using MsiGetProperty, and this points to the fact that it won't work unmodified in a deferred execution action. If SUPPORTDIR masked a call to MsiGetProperty, there would be no obvious explanation for why it fails in deferred execution.

If it's possible, would you prefer to see a compile-time error for uses of SUPPORTDIR in Basic MSI and/or InstallScript MSI projects? While we can't detect its use at compile time, we might be able to avoid defining it in MSI based projects (I'm theorizing because I'm not intimately familiar with the compile process). Is that potential result helpful enough to be worth our exploring?

lysemose
05-02-2006, 09:05 AM
It's your decision if you want to do this change - I just wonder what you will tell your customers ?

For my part I then need to rewrite my RollBackCA and my DeferredCA using CustomActionData transferring 5 / 12 parameters.

Christopher Painter
05-02-2006, 09:15 AM
I'm probably going to write a common use function and post it on InstallSite soon. Basically I'll write a function that looks something like this:

string MsiGetCustomActionDataAttribute( HWND, STRING );

The function will decode the customaction data and return a specific argument. Usesage would look like:


szSupportDir = MsiGetCustomActionDataAttribute( hMSI, "SUPPORTDIR" );

given CustomActionData = "/SUPPORTDIR=C:\FOO\" then szSupportDir would be set to "C:\FOO\"

Maybe this is too much hand holding but it might be nice if somewhere in the CustomActionWizard or CustomAction view that there is a field that gets enabled for Deferred CustomActions that gets input from the user and is used to sequence a Type 51 CA just prior to the DefferedCA. Basically steer the developer down the right road.