Referenced DLL Missing in Managed Custom Action

[cs1234]

I have a managed custom action (stored in binary table), which has another managed dll as a reference. I added this dll as a dependency in the ISClrWrap table, which worked fine. If, however, I call functions in the referenced dll, which use dll import to call functions in an unmanged dll, I get an error that it cannot find the unmanaged dll.
The custom action is being run before the files are being installed to disk.
Any suggestions on how to deal with this? Is it possible to use these functions?

Thanks,
Caroline

[MichaelU]

If the unmanaged file is on disk somewhere, you just need to ensure it can be found. This may be easiest to do by changing the current directory. If it's not available on the disk yet, you'll have to figure out how to get it somewhere it can be found. One approach would be to reschedule your action; another would be to keep a copy in the Binary table and to extract it yourself with MSI APIs.

[cs1234]

The file isn't on disk yet. I'm trying to run an action which loads the previous install and data storage location from our database, so that I can show those to the user as a default location during installation. (This is for the case where they have uninstalled our software, and want to reinstall (we give them the option of saving all their settings on uninstall)).

How would I add the dll to the binary table? (forgive me if this is a silly question, I'm still new to this.) I tried adding the unmanaged dll as a dependency in the ISClrWrap table, but that didn't seem to solve the problem.
Is there some location that I need to set the current directory to if I include the dll in the binary table before the functions from the unmanaged code is called?

[MichaelU]

Yeah, the ISClrWrap table doesn't support unmanaged dependencies. I forgot the support files option; that would automatically extract a file into [SUPPORTDIR]. However adding files to the Binary table should be as easy as going to the direct editor, adding a row, and browsing to your file; extracting it would be the hard part. Either route, once it's extracted to a known location, I'd make your entry function change the directory before calling into the intermediate assembly.

[Christopher_Pai]

I'd look into using DTF for managed custom actions. DTF will automatically include non-GAC'd assemblies that you add as references and any other non-managed resource provided that you add it to your project as build action content.

http://blogs.msdn.com/jasongin/archive/2008/05/23/custom-action-project-templates.aspx

[cs1234]

Thanks for the help. I went with the Support Files way, and that worked like a charm. I will look into DTF in the future maybe when time permits.

[savy17]

I have similar problem as CS1234 has mentioned in this post. However in my case, the custom action is run after starting the services. So that means at that time, files are already installed on the disk.

However I am not able to use ISClrWrap table as my managed code uses another managed dll that in turn uses unmanaged dll.

I didn't queit get what you mean by changing the current directory. Can you please explain how I would be able to achieve this. And is Support File option can be used in this case? If so, how can I use that?

Kindly suggest some solution

MichaelU wrote:
If the unmanaged file is on disk somewhere, you just need to ensure it can be found. This may be easiest to do by changing the current directory. If it's not available on the disk yet, you'll have to figure out how to get it somewhere it can be found. One approach would be to reschedule your action; another would be to keep a copy in the Binary table and to extract it yourself with MSI APIs.

[savy17]

CS1234,
I am having same issue as you had earlier. It is just that in my case, I am calling this custom action after services started.
I had looked at Support Files option but couldn't quiet understand how to use it. Can you explain a bit more so that I can follow the same.
Thanks,

cs1234 wrote:
Thanks for the help. I went with the Support Files way, and that worked like a charm. I will look into DTF in the future maybe when time permits.

[cs1234]

If the files are already on disk, you probably just need something like the following at the start of your custom action to change the current directory.

System.Environment.CurrentDirectory = "

[savy17]

When you say at the start of Custom Action, does that mean in the C# code where the actual code is written or in InstallShield itself?
And by the way how does Support Files work?

cs1234 wrote:
If the files are already on disk, you probably just need something like the following at the start of your custom action to change the current directory.

System.Environment.CurrentDirectory = "

[cs1234]

I meant to add a line of code like that to the beginning of your c# code.

For support files you add the files to the Language Independant section of the support files page. (I don't have a copy of Installshield available right at the moment, so the exact names may not be right).
Then when your installer runs these files get extracted to a temporary location. You can get the temporary location from the SUPPORTDIR property.

Hope that helps a bit, but if your files are already on disk, you probably shouldn't need to use the support files, you should just set your custom action to run from an installed file (there is an option when you go through the custom action wizard to pick the location of the action). and then set the current directory to the location of your files at the beginning of custom action. I believe you still need to set the Depenecy values in the IsClrWrpr table for any managed dependencies.

[savy17]

Thanks CS1234. I was able to get away with using just the managed dlls and hence ISClrWrap table worked for me.