Sample Plug In

[stevew]

I was wondering if you could give me further details into how to create a custom Plug In?

I have found the cpp sample that shows how to interact with the IDE and setup; although, I have not been able to determine how to program the details of the plug in, even though I am extremely fluent in programming .cpp.

I downloaded your 68 meg sample plug in project (InstallAware Plug-In Update.exe) and tried to install on a stand alone machine. The install failed because i did not have installAWARE on that machine. I did not want to install on my installAWARE computer because it is not clear what that 68 meg plug in file contains ... i don't want to overwrite potentially newer plug in's from InstallAWARE 5.0. Does that download have sample source code or is it just run time? Is the contents already in InstallAWARE 5.0?

Anyway, for example, i have this dll that is a run time for my app. I would like to create a plug in for this dll to:
1. determine version of existing dll in winsys32
2. copy into winsys32 only if setup file is newer.
3. register the dll.

How do i do this? Am i to use the windows API for everything or do i use some InstallAWARE API ? I am slightly confused because it appears i need to code everything using windows API; but that goes against my understanding that InstallAWARE does all installation via the Windows Installer engine.

Can you shed some light into this so I may better understand what i need to do?

Once i understand what to do I need to make some substantial enhancements to the existing Windows Installer 3.0 plug in. I mean i need to create plug in's for each language since the one you have provided appears to be English only. I want to use your Plug In technology since this is great for installing the Windows Installer since it appears to allow bootstrapping the setup. (my understanding of the definition of bootstrapping: a reboot is not required after installation of the Window's Installer and before installing my application)

thanks!

[MichaelNesmith]

Hello,

The MSI 3.0 plug-in installs for all languages. And it will automatically pick the correct language at runtime...so if this was the whole reason you wanted to get into plug-in authoring, no need!

Let me know...

[stevew]

very nice. I just got concerned because at the microsoft site they have different downloads based on the language selection. I assumed the file was different but it must be only the EULA and readme files.

My question was partly to resolve this non-problem (now that you clarified this) but is also, and potentially more importantly, to help me understand what I may be able to do with this product.

I am currently struggling trying to learn what my optoins are. My program that i need to install has a proprietary run time component plus a special kind of multi-language requirement. I now have a stand alone hidden setup to install my run time plus a visually driven setup for the programs. I am switching to the more modern looking InstallAWARE and I tried making my invisible runtime setup into an MSM, but am not sure i like this since i give up the size calculations and nice display of files being installed. I want to try creating a Plug In because I suspect this will create a more visually appealing install.

[MichaelNesmith]

If your plug-in does not need to do anything "special", meaning things that you cannot do in InstallAware script, I would recommend you create an Include Script, enter all your custom installation code in there, and share that in all your setups which need to perform the same tasks. This would be the best way to do it.

Plug-ins are generally recommended for things which are not easy to do using InstallAware script -- while not many, there will of course be cases in which our built-in scripting language does not cover every possible API call, etc.

Let me know more about what your goals are, and I will guide you accordingly.

[stevew]

What about the just because i want to find out for myself first hand?

[MichaelNesmith]

That's a good reason

A good place to start is the help file, which documents the necessary DLL exports that your plug-in must feature.

You will write two plug-in DLLs: one that is called from the IDE, and another that is called during setup. The design time DLL displays its custom line of code in the InstallAware script editor, displays the command window where you can edit the command parameters, participates in the build process, can add files and folders to built setups, and can even directly update the generated MSI file. The run time DLL executes at runtime, not surprisingly, and can make any number of changes to the system using Win32 API calls, or do anything else you can do with a DLL, based on what you are trying to achieve.

Notice that your plug-in does not need to do any installation related tasks. For instance a plug-in has full access to all variables in your setup script, and can update them. So you could have plug-ins that verify serial numbers, return results, etc...

The downloadable plug-in pack you referenced earlier was for InstallAware 2005 and is already included with InstallAware v5.0. That pack updates InstallAware plug-ins and does not contain any sample code.

If you want to find sample plug-in code, including correctly declared function stubs, look in this folder:

Code: Select all

C:\\Program Files\\InstallAware Studio Admin 5\\Templates\\Plug-Ins\\VCPP

If you click File->New->Other, and switch to the Plug-Ins tab, you can also create a skeleton plug-in project.

Hope that's some helpful info to get you started! We've also had some plug-in contributions to InstallAware - they are available on this forum, feel free to download and install them; they will also give you a good idea of what plug-ins can do.

[stevew]

thanks!

i hope you haven't flagged my record as "trouble maker".

Final question. Is uninstalling supported? Is the run time function called for this or is it handled transparently in installAWARE?

[MichaelNesmith]

The short answer here is yes and no

Can I refer you to the Genuine Scripting for Windows Installer whitepaper here:

http://www.installaware.com/installawar ... taller.pdf

This whitepaper explains how the scripting works, how plug-ins fit in, and so on. I believe reading it will answer your question.

[stevew]

Just as Markus is posting some helpful tools that he has created with PureBasic, I would like to contribute some information to the general knowledge pool. I would have enjoyed if somebody could just tell me this so I think other C programmer dinosaurs will like a leg up with this starting psuedo code:

- add appropriate exported functions to "both" of the def files. otherwise functions won't be called by installaware.
- for the IDE DesignTimeEdit function, ensure that the string is a true string and is returned terminated with a null character. If not, you may not notice a problem until after a compile when the string slowly begins to grow and causes some weird crashing of the IDE.

Code: Select all

DECLARE GLOBALS:

   const char *g_orig_state;
   int g_orig_state_size;


__declspec(dllexport) int WINAPI DesignTimeEdit(int Window, const char* State, char* NewState)
{
char umsg[2048];
int nRet;

if (NewState == NULL){

   // first call
   if (State == NULL){
      g_orig_state = NULL;

      // SET LOCAL VARIABLE umsg TO SOME DEFAULT SETTINGS
      wsprintf(umsg,"%cMy value is this string.%c",34,34);
      nRet = strlen(umsg) + 1;
   }else{
      nRet = strlen(State) + 1;

   }

   if ((g_orig_state = (const char *)malloc(nRet)) == NULL)
   {
      MessageBox((HWND__*)Window, "Out of memory.", "Error", MB_OK);
      nRet = -1;
   }else{
      memset((void *)g_orig_state, 0, nRet);
      g_orig_state_size = nRet;
      if (State == NULL){
         // settings for newly added plug in.
         memcpy((void *)g_orig_state, umsg, nRet);
      }else{
         // plug in has already been added to the script and configured.
         // re-save existing data.
         memcpy((void *)g_orig_state, State, nRet);
      }

      if (ParseCommaText(g_orig_state) == FALSE){
         nRet = -1;
      }else{
         // TODO: SHOW A DIALOG.  UPDATE RESULTS into g_orig_state, nRet
      }
   }
}else{
   // second call
   memcpy(NewState, g_orig_state, g_orig_state_size);
   free((void *)g_orig_state);
   nRet = 0;
}
return nRet;
}

__declspec(dllexport) bool WINAPI CompileTimeBuild(int MSIHandle,const char* State, const char* BuildPath,bool Build,bool& Fetch)
{

   //COPY THE RUN TIME DLL TO FOLDER SPECIFIED IN BuildPath.
   //COPY ANY ADDITIONAL FILES.

   MessageBox((HWND__*)0, umsg, "CompileTimeBuild", MB_OK);

   return false;
}

extern "C" {

__declspec(dllexport) int WINAPI RunTimeExecute(
int Window, const char* Variables, const char* State, lpPlugProgressIndicator Progress, int& Return, char* NewVariables)
{
   //THIS FUNCTION IS ALSO CALLED TWICE.

   //FIRST STEP. PARSE Variables.

   //PARSING THE Variables IS AN EXTREMELY DELICATE PROCESS.  BE SURE YOU DON'T
   //RUSH THIS.  YOU GET A LIST OF ALL VARIABLES AND VALUES FROM INSTALL AWARE.

   //BY USING THE INSTALLAWARE VARIABLES YOU MAY MANIPULUATE INSTALLAWARE TO
   //PERFORM ANY WINDOWS INSTALLER COMMAND SUPPORTED BY INSTALLAWARE.  (I ASSUME
   //THIS IS ALL OF THEM).  BY DOING THIS PROPERLY YOU MAY KEEP YOUR INSTALLATION
   //TOTALLY STANDARDS COMPLIANT AND THE UNINSTALLATION STEPS WILL BE HANDLED AUTOMATICALLY.

   //IF YOU DON'T MIND TO BREAK THE STANDARDS YOU ARE STILL FREE TO CALL ANY WINDOWS API COMMANDS.
   //THESE WINDOWS API COMMANDS DO TASKS THAT WILL NOT GET UNINSTALLED.  THIS IS NOT THE BEST PRACTICE.

   //IMPORTANT: WHEN THIS FUNCTION RETURNS THE SECOND TIME MAKE SURE YOU PASS BACK THE Variables
   //FROM THE FIRST STATE OR ALL VARIABLES WILL BE LOST AND YOUR INSTALL WILL CRASH AND BURN.
   //(THIS HAPPENED TO ME TILL I GOT SMART).

   return 0;
}

}

[MichaelNesmith]

Thank you very much for this contribution Steve, it is greatly appreciated!