IA X2: Define File Bag

[Mohamed Koker]

Hi Folks,

There appears to be a significant difference between the behaviour of FileBags in IA18 and IA X2.

The main issue I am seeing is that the temporary folders used to store the contents of FileBags are deleted when you use the Apply Install command in IA X2 so that if I try to reference a method in a dll stored in a file bag, nothing happens.

Is there anything I can do to prevent this deletion or do I have to issue another Define File Bag command after the Apply Install in order to reference a method in a dll stored in a file bag?

Regards

-Mohamed

[FrancescoT]

Dear Mohamed,

if you need to call a Dll why don't you use the SUPPORTDIR location? ... it's most appropriate.

Regards

[Mohamed Koker]

Thanks Francesco!

[Mohamed Koker]

Hi Francesco,

Unfortunately, we now have a problem with IA X2 that I cannot solve.

When we call the Dll function after placing the Dll in the SUPPORTDIR, it works for the first call but after that calls to these functions fail with DLLLOADFAILED.

I have tried calling SetDLLDirectory with the SUPPORTDIR as a parameter based on discussions around similar issues in this forum but this did not work.

This was not a problem in IA 18 so we need your help urgently.

Regards

-Mohamed

[FrancescoT]

Dear Mohamed,

honestly I suppose there are some other causes at the source of your problem ... maybe the dll itself.

I can assure you that there are no problems on the InstallAware side with the DLL load process.
I extensively use DLLs with my projects and I haven't found any issue with using them.

For your convenience, attached you find a test project that repeatedly calls a Dummy DLL within a loop.
The demo calls a DLL function that displays the passed parameter in a Message-Box.

To run the test, just build the project and then execute the generated EXE ... no other actions are required.

PS
It's not necessary to call "SetDLLDirectory" WIN API!

Hope this helps you.

Regards

[Mohamed Koker]

Hi Francesco,

I don't think the problem is with the Dll because it works fine with IA 18.

It also works fine with IA X2 under Windows 7 64-bit but fails after a certain number of calls with Windows 7 32-bit.

Can you please clarify one thing about the correct use of the Call Dll function?

If I want it to pass string parameters as ANSI parameters, do I need to export the DLL function as FuncA in addition to specifying the function name as FuncA in the InstallAware script?

The functions exported by this Dll expect ANSI strings since we have been using this Dll since we first started using InstallAware in 2007 before you supported UniCode.

We currently call the functions without adding an A or W suffix in the InstallAware scripts and this works fine in IA 18 as well as IA X2 under Windows 7 64-bit.

Regards

-Mohamed

[FrancescoT]

Dear Mohamed,

unfortunately part of the recent forum posts have been lost due domain maintenance.

Anyway to recap the problem you have reported; as I have already said I am not able to reproduce the same with any DLL I used.

Due the nature of the DLLs, the fact that your DLL seems to work correctly with a different application, it's not a proof.

If you are able to demonstrate the problem with a sample project (I suggest you to use the one I posted before), I'll be happy happy to verify it.
Of course we can't verify your DLL code and functionality. You should use a standard windows DLL that exports a WIN API function.
Alternatively you could release a very simple C/C++ DLL for this purpose to use with the above IA sample project. In this case 'please include the full C/C++ DLL project.

The "Call DLL function" is in reality a Plug-in and this has not been changed or updated with the release of the latest InstallAware version.

Regards