I don't suppose...

[Hamilton-Scott]

...that the automation objects in 2008 are now .Net managed and no longer those awful, disgusting, obnoxious, foetid, vulgar and revolting COM objects that currently exist? 😄

[RobertDickau]

One gets the impression that you don't care for the COM objects. The Automation interface has been much enhanced in InstallShield 2008, but I believe the general architecture is the same; you (meaning "everyone") can cast your vote for something different by submitting a feature request at www.installshield.com/feedback.

[Christopher_Pai]

Personally I use TFS / MSBuild / Team Build for my entire solution. TFS calls my solution which calls my ISPROJ which calls the Macrovision targets which calls the SABLD. Whew..... it's actually simpler then it sounds.

The only custom task I currently have is for using the automation interface ( I could have just as easily done it with XML XPath ) to update the version #. And this is only because I have not refactored my automation to use the new SABLD feature of ProductVersion being a command line argument.

I suppose some people heavily need the automation interface, but I personally don't see a need for it. But when I do use it from .NET, I just use pure reflection instead of generating an interop assembly for it. The end result is it looks alot like calling it from VBScript.

[Hamilton-Scott]

Robert,

I can live with the COM objects but this is why I use them. I have a C# app that takes a hand-rolled XML configuration file which describes the features and components I need to install. You might appreciate that making regular edits to the project in the IDE can be time consuming especially as I eschew the use of dynamic file linking. This means anyone can edit our XML file and add or remove components from the installation using a simple editor. Once that's done, my C# app takes a template of the .ism and makes a copy of it and then uses the COM objects to create the features etc. It all works well and once the new .ism project is saved I then pump that into issabld.exe for media generation.

Of course, if I were using VB then the COM objects tie in very nicely, but as I'm committed to C#, full-on managed code would have been preferred and is more compatible with the .Net architecture. It would have been nice to the objects migrated but I do understand that this is not a priority.

[Hamilton-Scott]

Christopher Painter wrote:
...But when I do use it from .NET, I just use pure reflection instead of generating an interop assembly for it. The end result is it looks alot like calling it from VBScript.

Christopher, can you share a coding snippet with me as I'm interested in your alternative approach? I don't want you to divulge anything you consider confidential to your own knowledge base but it has aroused my interest in the reflection route.

[MichaelU]

My understanding is several of the small inconsistencies that led to some properties being exposed as properties, and others being exposed as get/set accessors, have been addressed. This should make the .NET experience much less jarring.

[RobertDickau]

One approach is described in KB article Q110820, "INFO: Using InstallShield Automation Interface in C#"; an example C# command-line application (after adding to the Visual Studio project a COM reference to "InstallShield 14 Automation Interface") might look like:[code]using System;
using System.Collections.Generic;
using System.Text;

namespace ISWiAuto14CS
{
class Program
{
static void Main(string[] args)
{
ISWiAuto14.ISWiProject ism = new ISWiAuto14.ISWiProject( );
ism.OpenProject(
@"C:\InstallShield 2008 Projects\BasicMsiTest.ism", false);
Console.WriteLine("ProductVersion was: " + ism.ProductVersion);
ism.ProductVersion = "1.2.3";
Console.WriteLine("ProductVersion is now: " + ism.ProductVersion);
ism.SaveProject( );
ism.CloseProject( );
}
}
}
[/code]

[Hamilton-Scott]

Thank you gentlemen. I look forward to trying this out when my 2008 media arrives in the post. Michael, I think I'm in tune with what you are getting at as I think I raised a bug ticket in repsonse to a support call about a 'missing' property or something on those lines.