We have a half dozen products pacakged in MSIs, and for good or bad, we have a significant amount of code in custom actions. An example, we have a function that adds messages to the installer log.
In each of our products we have a single monolithic script file that is a collection of script functions. Much code is duplicated between the different installers. The logging function, for instance, shows up in all these files.
This is a maintenance nightmare. If I change one file I have to change them all. I have to be careful of package-specific tweaks that previous maintainers performed on similar functions. I would much rather have a single file containing common code. For instance, I want to extend our logging function. I now have to duplicate my effort to change that function in a dozen different places.
We are missing something. What mechanism should I be using to factor common code in my custom action scripts? Is there an article I can read? Am I in the right forum?
TIA
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Custom Action script organization
Started by
SkipSailors
, Oct 14 2004 18:47
4 replies to this topic
Volynkin
-
- Members
- 5 posts
Posted 15 October 2004 - 03:51
umm.... how about using common programming practice? Such as splitting your project into several source code files, create headers for each of them and pull them all together in the main file with preprocessor commands such #include.
You can definately do that if you make your CA DLL in C/C++ just as well as in IS InstallScript.
For example:
In your main script file for every installer you have:
You can definately do that if you make your CA DLL in C/C++ just as well as in IS InstallScript.
For example:
In your main script file for every installer you have:
| CODE |
#include "common\log.h" UINT __stdcall CustomFunction (MSIHANDLE hModule) { UpdateLog(pLog); //TODO: Put your SetupAPI routine here return ERROR_SUCCESS; } |
in your "common" folder you will have two files: log.cpp and log.h
log.cpp will look like:
| CODE |
void UpdateLog(int *myLog) { //TODO: Put your log routine here } |
and finally your log.h will have the following:
| CODE |
#ifndef LOG_H #define LOG_H void UpdateLog(int *myLog); |
Now, all you have to do, is to put log.h/cpp files into "common" folder and access that module from all the installers that require its functions.
Edited by Volynkin, 15 October 2004 - 03:52.
Zweitze
-
- Full Members
- 522 posts
Posted 15 October 2004 - 08:46
It these functions make up complete CAs, which should always be inserted at the same place:
Create a merge module (MSM), and use that in all your installs.
Create a merge module (MSM), and use that in all your installs.
SkipSailors
-
- Members
- 34 posts
Posted 15 October 2004 - 16:56
I think I see my issue. Can I translate these common coding practices to CAs implemented with JScript?
We have decided that in order to have access to the Installer object, and in order to hire "Install Engineers" that don't need to know how to operate compilers, JScript is the preferred language for CA.
We are developing some expertise in .NET and it would be relatively easy to steal some talent in C#. C and C++ talent is a little harder to come by here.
We have decided that in order to have access to the Installer object, and in order to hire "Install Engineers" that don't need to know how to operate compilers, JScript is the preferred language for CA.
We are developing some expertise in .NET and it would be relatively easy to steal some talent in C#. C and C++ talent is a little harder to come by here.
Skip Sailors
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 19 October 2004 - 08:28
I think that VBScript is more commonly used for custom actions then JScript.
Stefan Krüger
InstallSite.org twitter facebook