automation interface

[aevanne]

Hi,

I see that the studio admin package adds an automation interface over the studio package. What does this do?

Thanks,
Aevanne.

[CandiceJones]

Take a look at all the time saving benefits below that you get to unlock with our flagship Studio Admin edition:

o PackageAware: Capture and convert legacy or Windows Installer setups into InstallAware based MSI setups

o Database Import Wizard: Directly import MSI and MSM databases into InstallAware scripts

o Automation Interface: Build applications that programmatically create and build setup projects without InstallAware

http://www.installaware.com/forum/viewtopic.php?t=4584

[bokkie]

Hi,

I see that the studio admin package adds an automation interface over the studio package. What does this do?

Thanks,
Aevanne.

The Admin edition includes some dlls that you can add to, say, a C# application. With them, you can create a project and populate it with code, files to be installed, etc. Once you've created your project you can open it in the IDE if you want to or throw it into the miabuild utility which'll render into an installation package. An example I use which I'm porting to IA is to run a C# program which reads an XML manifest file describing the contents of the package. The automation interface will be used to convert the XML schema into an IA project. That way, other developers can add or remove objects from an installation without requiring the IDE.

[CandiceJones]

I also wanted to add that in general while an automation interface is a must-have with legacy tools like InstallShield, its overkill 99% of the time with modern tools like InstallAware.

Smart use of Compiler Variables in InstallAware generally renders the automation interface irrelevant. They're a lot easier and a lot more versatile.

Of course, if you need to emit widely distinct setup projects...then the automation interface still makes sense; however very few setup projects have that kind of stringent requirement.

[aevanne]

Thanks

[JeffTucker]

Is there some way that an automated build could set the project version (like 7.0.310.0) automatically and have a new version and update pack created?
We have an external file called "SmartClient.Build.Number" that is updated by NAnt that contains the real product version. It is tough to start and stop our automated processes just so we can keep that number the same as the product version. I'd like to have the text in the build number file drive the product version.