Tuesday, January 30, 2007
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.
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.
Thursday, January 18, 2007
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.
Tuesday, January 16, 2007
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:
public sealed class
MSIFactory : DbProviderFactory
public static readonly MSIFactory
Instance = new MSIFactory();
public override DbCommand
return new MSICommand();
public override DbConnection
return new MSIConnection();
public override DbDataAdapter
return new MSIDataAdapter();
return new object() as
Then you create an App.Config file to teach the framework about your new Factory Class:
<?xml version="1.0" encoding="utf-8">
<add name="MSI Data Provider" invariant="System.Data.MSI" description=".Net Framework Data Provider for MSI"
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:
DbProviderFactory factory =
DbConnection connection =
DbDataAdapter adapter =
DbCommand selectCommand =
DataTable propertyTable = new
selectCommand.CommandText = "SELECT * FROM
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.
Monday, January 15, 2007
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 18.104.22.168565. 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.