InstallShield 12 SP1 Released

Macrovision has released InstallShield 12 Service Pack 1 for English system and there is a LONG list of resolved issues. Below is a bullet list of several of the new features/fixes. For more information, read the release notes.

Additionally InstallShield 12 Stand Alone Build SP1 English is available as noted here.

InstallShield 12/InstallShield 12 SP1 Release Notes: (Abridged)

New Microsoft .NET Framework 3.0 Prerequisite Available

InstallShield now includes a .NET Framework 3.0 setup prerequisite that you can add to Basic MSI and InstallScript MSI projects.

Ability to Minimize the Number of UAC Prompts by Advertising as Part of Prerequisite Installation

Use the new Advertise If Prerequisites Are Elevated setting in the Releases view of Basic MSI or InstallScript MSI projects to specify whether your .msi file should be advertised and run after the setup prerequisites in the installation have been successfully installed with elevated privileges on Windows Vista machines. The advertisement may allow end users to avoid the User Account Control (UAC) prompt that would otherwise be displayed for a .msi package that requires elevated privileges.
The Advertise If Prerequisites Are Elevated setting is one of several settings in InstallShield that affect whether an installation triggers UAC consent or credential prompts for elevated privileges. Understanding these different settings will help you create the appropriate UAC experience for your installation when end users run it on Windows Vista systems. For detailed information, see "Minimizing the Number of User Account Control Prompts During Installation" in the InstallShield Help Library.

Also as part of this fix, if you select the "The prerequisite requires administrative privileges" check box on the Behavior tab in the Setup Prerequisite Editor for a prerequisite and the prerequisite is installed on a Windows Vista system, Windows Vista displays a UAC prompt that requires end users to provide consent or credentials. Previously, selecting or clearing this check box had no effect on Windows Vista systems.

Enhanced Validation for the Windows Vista Quality Program

InstallScript Custom Actions No Longer Cause Initialization Delay or Installation Abort on Windows Vista

InstallScript Engine Files

The InstallScript engine files are no longer installed to a subfolder of the Application Data folder. Previously, the IsBe.dll file was cached in this folder on 64-bit target systems temporarily while the installation was running.

Trialware

Now .exe files that are wrapped with trialware protection in InstallShield 12 SP1 can be run on Windows Vista systems. If an .exe file is wrapped with trialware protection in InstallShield 12, without SP1, or in an earlier version of InstallShield, end users cannot run it on Windows Vista systems.

In addition, the InstallShield Licensing Service, which is required for all trialware products, is now started during installation time; this enables end users to run the trialware without administrative privileges, which is especially useful on Windows Vista systems. Previously, end users had to have administrative privileges if they wanted to run trialware on a Windows Vista system.

MSIProvider Now On CodePlex

For the last few months I've been really heavy into C# at work. While I still have A LOT to learn, I don't feel like a fish out of water anymore either. I've been learning quite a bit about ADO.NET and I've decided that it's time to start my first serious open source project: MSIProvider.

I've choosen CodePlex over SourceForge because frankly, I love TFS, I don't really care for CVS, and this project is really about building on top of Microsoft technologies. I've checked in a bunch of files to source control and published the project. There isn't much there besides a bunch of stubbed out classes and a few implemented methods but it's a start.

Simply put, this project is about creating all of the ADO.NET provider objects needed to expose MSI databases as a Factory. This way .NET developers can communicate with MSI databases the same way they do with any other data source. As this project matures I expect there to be spin off projects that use the provider to do useful things with MSI databases.

I sincerely invite anyone who wishes to participate to sign up on CodePlex and join in.

Windows Installer Factory Provider for ADO.NET 2.0

I have to admit that for the last couple of months I really havn't spent much time working on installs. Instead I've been getting waist deep into C# programming, specifically ADO.NET 2.0 Factory Patterns. I guess that's what happens when you go to a new job to work with the founder of the Austin .NET User Group.

Although I've programmed on just about every platform and language over the years, Setup has always been deep in my blood. As I dug deeper and deeper into ADO.NET 2.0, I just couldn't help wonder what would be involved in making a Factory Provider for MSI databases. The goal would be to abstract .NET developer from the ugliness of the MSI API as much as possible. Every interop implementation that I've seen to date either was a direct wrap of the MSI API or Automation interface. Even the prettier ones like Rich's Pahvant.MSI still feels very MSI. What I wanted was the ability for anyone who's ever done ADO.NET to quickly be able to query and update MSI databases.

I've only barely begun on this project, but here is what I can report so far. It's really not that difficult to derive the classes needed from various abstract classes and interfaces. For example you can say:

using System;
using System.Data;
using System.Data.Common;
using
System.Data.MSI;
namespace System.Data.MSI
{
public sealed class
MSIFactory : DbProviderFactory
{
public static readonly MSIFactory
Instance = new MSIFactory();
public override DbCommand
CreateCommand()
{
return new MSICommand();
}
public override
DbCommandBuilder CreateCommandBuilder()
{
return new
MSICommandBuilder();
}
public override DbConnection
CreateConnection()
{
return new MSIConnection();
}
public override
DbConnectionStringBuilder CreateConnectionStringBuilder()
{
return new
MSIConnectionStringBuilder();
}
public override DbDataAdapter
CreateDataAdapter()
{
return new MSIDataAdapter();
}
public override
DbParameter CreateParameter()
{
return new object() as
DbParameter;
}
}
}

Then you create an App.Config file to teach the framework about your new Factory Class:

<?xml version="1.0" encoding="utf-8">
<configuration>
<system.data>
<dbproviderfactories>
<remove invariant="System.Data.MSI"/>
<add name="MSI Data Provider" invariant="System.Data.MSI" description=".Net Framework Data Provider for MSI"
type="System.Data.MSI.MSIFactory, System.Data.MSI"/>
</dbproviderfactories>
</system.data>
</configuration>

From there you go about defining each of your classes and wiring them up to communicate with the MSI API. Once this is all done it's time for the big payoff. Retrieving the contents of the Property table into a DataTable becomes as simple as:

using System;
using System.Data;
using System.Data.Common;
using System.Data.MSI;

DbProviderFactory factory =
DbProviderFactories.GetFactory("System.Data.MSI");
DbConnection connection =
factory.CreateConnection();
DbDataAdapter adapter =
factory.CreateDataAdapter();
DbCommand selectCommand =
factory.CreateCommand();
DataTable propertyTable = new
DataTable();
connection.ConnectionString =
"DatabasePath=D:\\somepackage.msi;Persist=MSIDBOPEN_READONLY";
connection.Open();

selectCommand.Connection
= connection;
selectCommand.CommandText = "SELECT * FROM
PROPERTY";
adapter.SelectCommand =
selectCommand;
adapter.Fill(propertyTable);

I have alot of work ahead of me, but I think this would be a really cool project to work on. I'm considering throwing this up on CodePlex if anyone would like to work on it with me. Just drop me a note. Until then, as Rob Mensching would say..... Keep on coding. You know I will.

InstallShield XML Changes and .NET 2.0.

There has been a bug in InstallShield that has been reported on InstallSite.org and discussed various times on the InstallShield Community site. The bug involved the XML File Changes pattern authoring XML files as UTF-16 encoding instead of UTF-8 encoding. Personally I'd never given this bug much thought since my applications always seemed to work after installation. I'd even had a .NET developer who was far more experienced then myself look at the behavior and blow it off as `that shouldn't hurt anything.`

Well last week I noticed that a strange .NET 2.0 problem that I was having was partly caused by this behavior. It seems that the ConfigurationManager class in .NET is somewhat picky here. If I call the OpenEXEConfiguration method it will correctly load the AppSettings from an App.Config ( myapp.exe.config ) file that is authored in UTF-16/Unicode. However, when I made changes to the AppSettings and saved them back to the file, .NET would save the file in UTF-16/ANSI format. The next time I tried to call OpenEXEConfiguration the Framework would throw a Unicode exception. I'd have to open the file in Notepad and do a Save As Unicode to get it to work again.

Now I'm not the best C# developer in the world, but that seems like a bug. Why would the class save the file in a format that it can't read? Perhaps someone can explain this to me.

Now I've also noticed that if I create the XML to say the encoding is UTF-8 it always works whether it's ANSI or Unicode. The problem though was that InstallShield 12 would always write the XML changes as UTF-16.

Well, today MichaelU posted an unofficial hotfix on the InstallShield Community site. It contains an updated version of ISXmlCfg.dll that updates XML files in UTF-8. I've tested it and it solves my problem. Thanks Michael!

BTW, I couldn't help notice that the version # of the file is 14.0.0.58565. Hopefully we'll be seeing InstallShield 14 sometime soon. If I had to take a guess, I'd imagine that there will be a service pack to IS12 to make up for the fact that there wasn't a 12.5 and that IS 14 will be released later this spring or early summer since that's about 1 year since IS 12 was released.