Calling a DLL function.

bokkie · Post by **bokkie** » Tue Feb 10, 2009 4:32 pm

Apologies for posting this here as I'm not sure if what I'm asking is in fact a plugin question or not.

If I look at the available project types I can create a C++ or Delphi library which can be referenced and called in MSIcode. I don't have Delphi and I last used it at version 2.0 which was a long time ago when dinosaurs ruled the earth. Neither am I a C++ guru as 100% of my development is C#. This gets me thinking that I can't use C# assemblies in IA and I guess that is because of the method stubs and return types, that sort of thing? Is it possible to use C# assemblies in IA? If not, does someone have a very minimalistic C++ project I could use as a template. I only have VS.Net 2005 and 2008 so I'm not sure if such a beast is loadable/usable in VS.Net anyway.

I'm really only after something that demonstrates the concept, something basic I can extend like a method that returns the ubiquitous "Hello World" to a property in IA as a starter.

Thanks.

MichaelNesmith · Post by **MichaelNesmith** » Tue Feb 10, 2009 5:30 pm

You can call any Win32 DLL which conforms to standard Win32 calling conventions in InstallAware using the Call DLL Function command.

The route you discovered is plug-in authoring, which is a very tight level of integration with the InstallAware IDE - plug-ins natively appear as members your MSIcode script.

Again, as long as your DLL conforms to standard Win32 API calling conventions, regardless of language, it can be consumed. The help file describes the functions you need to export in detail.

bokkie · Post by **bokkie** » Wed Feb 11, 2009 4:40 am

Michael,

I did a little more research on the dll __stdcall issue. Elsewhere, I found a thread where someone suggested using a C# executable and running it using the Run Program statement. That would probably work but I see a couple of questions come to mind which I'd like some advice on:

1. Installing the executable: How would you schedule this during the installation? After all, you'd need it to be installed on the disk before you make use of it. The catch-22 is that if it's part of the general installation it may only exist on disk after the place where you'd want to use it. What strategy would you use to pre-install that file so you can make use of it, say, during the validation process when you are harvesting the user options and pre-installation dialogs? I see there is a Copy/Move Files statement in MSIcode which might be the ticket? What do you think?

2. If the C# executable returns a value (a la Dos return code) can you pass that value back to IA so it can be stored in a property which can be referenced later in the MSIcode? I know C# can return values which a Dos batch file can use as I've used that in the past. I'm not suggesting I want to use a batch file, but if I could get a C# executable to return a value to IA via the Run Program statement then that would help.

I'm not trying to be lazy or bypass the plugin or C++ compatible dll convention but a quick and dirty solution would help me during the evaluation process. The background to this is that I have an IS project that launches some external commands as hidden Dos windows. One of them fires up a C# executable which, under the hood, beetles off to the file system and creates some files and so on. Another C# executable uses WMI to get the disk serial number and uses that to generate a database value which becomes the cacher server id for that machine. This all works and I'm trying to show that what we do in IS can, albeit differently perhaps, be replicated in IA. Down the line, writing a native plugin or C++ __stdcall would be better for architectural reasons but at this moment I'd like to take the path of least resistance during the evaluation and justification process.

StyX · Post by **StyX** » Wed Feb 11, 2009 4:56 am

I can at least answer nr. 1 as I ran into this myself. The sollution that worked the best for me was to simply include the file I needed to use during the setup in the "Support Files". Go to MSIcode -> Right click on Support Files on the left hand side and choose the files you want to add.

Then go to where you want the program to run. Insert the Run program (or simular command) and when you click browse simply select Support Files on the left and you will get a list of the files that you added earlier.

Also note that the files inside Support Files will not be installed to disk.

bokkie · Post by **bokkie** » Wed Feb 11, 2009 5:23 am

Styx, from Stavanger.

Many thanks. That sounds like the approach I need to do. I will look into it this morning.

Peter, not from Stavanger.

bokkie · Post by **bokkie** » Wed Feb 11, 2009 5:53 am

Aha! A result.

I added the executable to the support files in the MSIcode tab. I wired it up to the Run Program statement and passed in two parameters which I added to give the return code in an IA variable. 100% successful.

What I did observe was that if I changed the C# application I had to remove it from the support files and then add it back in again. I sort of expected it to include the support file when I built the media but I thought I'd mention that anyway in case it's useful for others to know. So, no problem running C# applications assuming the .Net framework is installed which in our case will be the case anyway.

Next, I'm trying to get this concept of plugins in contect. I've attached a screenshot from my MSIcode window. Are the items shown in that screenshot what you guys know to be called plugins?

File Attached:

Styx3.png

StyX · Post by **StyX** » Wed Feb 11, 2009 5:56 am

Yes, if you scroll down to the bottom in that column where it says Plug-ins.

The rest are builtin functions as far as I know

bokkie · Post by **bokkie** » Wed Feb 11, 2009 6:26 am

StyX wrote:Yes, if you scroll down to the bottom in that column where it says Plug-ins.

The rest are builtin functions as far as I know

I see. I downloaded the reset file plugin and once I closed and reopened the project it was listed as an available plugin. I'm guessing that when I ran the plugin installation it copied the file(s) somewhere in IA's installation folder in Program Files?

Coming back to one of my earlier questions about plugins am I right in now saying that plugins must be coded and built using Visual C++ and not VS.Net C++? I don't know if there is a difference between the two. If that's the case, then does that mean you can't write a plugin in C# because it is not __stdcall compatible?

EDIT: I located the installation folder where the plugin was installed. I'm just curious how the plugin was 'registered' in MSIcode. I could not find any obvious file in Program Files\\InstallAware but I suspect something is being done somewhere and somehow.

bokkie · Post by **bokkie** » Wed Feb 11, 2009 7:10 am

Styx (plus others who might be interested),

I discovered this previous thread:

http://www.installaware.com/forums/viewtopic.php?t=3424

which culminates in the free download of a plug-in that generates guids. I installed it as the thread documented and made local changes to the build event pathnames and the sample IA project to make it drill down into the IA 8 plug-in folder. The acid test was building the C++ code in VS.Net 2005 and then running the test project installer. Voila! The plug-in was registered in the MSIcode and it worked. As they say in the UK "Does exactly what it says on the tin." At least now I have access to a plug-in I can tear to shreds and try and see how it works. Thanks to andyhore and vkumar for the running dialogue and modified VS.Net code.

Now, if i could just concentrate on walking first...

MichaelNesmith · Post by **MichaelNesmith** » Wed Feb 11, 2009 8:13 am

Peter, like I said earlier, the help file discusses how a plug-in is registered (hint: registry), what function exports are required, and so forth.

Also, if you are starting to use $SUPPORTDIR$, be sure to look into File Bag - it is a more flexible, path-recursive version of $SUPPORTDIR$ which is also Web Media Block aware.

bokkie · Post by **bokkie** » Wed Feb 11, 2009 8:18 am

MichaelNesmith wrote:Peter, like I said earlier, the help file discusses how a plug-in is registered (hint: registry), what function exports are required, and so forth.

Also, if you are starting to use $SUPPORTDIR$, be sure to look into File Bag - it is a more flexible, path-recursive version of $SUPPORTDIR$ which is also Web Media Block aware.

My apologies Michael. It dropped off my radar, so to speak, what with the flurry of excitement and activity I was going through.

File bag? I've seen it somewhere. I shall have a look for it.