I've really been loving my new laptop that Cheryl gave me for my birthday. Naturally I wipped the drive them moment I got it and I decided to give Vista a try. There has been a learning curve here and there, but as we all know, struggle is critical to the path of learning.
So for the past couple of days at work I've been spending a few minutes here and there trying to get a Vista image together for testing my installations. My first road block occurred when I accidentally brought in the Feb CTP and Creative PC-DVD drive ( my Dell GX270 didn't have a DVD ) and it didn't like my RC1 product key. Then I tried to download the RC1 except the firewall and download manager wouldn't play along. Then I brought in my Vista RC1 DVD and wouldn't you know, murphy strikes again! It couldn't copy the install.wim from the disc.
I was really stuck until I figured out that I could stick the DVD in my coworkers computer and copy the sources directory to a network share and ultimatly to my second hard drive. A few minutes later I booted the Vista PE, dropped to a command prompt, switched over to the harddrive and ran setup.exe.
The windows setup is so much nicer then the old days of dropping to MSDOS and doing a winnt /b. All in all I'm VERY impressed with what I see in Vista.
I don't care what the rablle says over at SlashDot.... keep up the good work Microsoft.
Historical archive 2003-2011
October 06, 2006
October 04, 2006
VDPROJ replace shouldn't be Votive
While discussing the possible future replacement of Visual Studio Deployment Projects I mentioned that it would be nice if the replacement was also open source and backwards compatible with previous versions of Visual Studio and not just a feature of Orcas.
Robmen pointed out that there already was an open source add-in called Votive.
While it meets part of the definition of what I said ( an open source add-in for 2003/2005 ) it certainly does not meet the definition of a replacement for vdproj.
Personally I have no intention of authoring anything except the most simple installation fragments in direct XML regardless of now nice the text editor gets. I expect a graphical RAD tool that is designed for user work flows and data validation. Beyond that, let that tool store the data in XML behind the scenes and use WiX to build the project.
My best analogy is the way VS2005 handles Forms and the way InstallShield exposes views and the Direct Editor. I want a designer view and a code view. I want to do most of my work in the designer view knowing that it's really just generating rock solid XML for me in that I can choose to tweak in the code view.
Robmen pointed out that there already was an open source add-in called Votive.
While it meets part of the definition of what I said ( an open source add-in for 2003/2005 ) it certainly does not meet the definition of a replacement for vdproj.
Personally I have no intention of authoring anything except the most simple installation fragments in direct XML regardless of now nice the text editor gets. I expect a graphical RAD tool that is designed for user work flows and data validation. Beyond that, let that tool store the data in XML behind the scenes and use WiX to build the project.
My best analogy is the way VS2005 handles Forms and the way InstallShield exposes views and the Direct Editor. I want a designer view and a code view. I want to do most of my work in the designer view knowing that it's really just generating rock solid XML for me in that I can choose to tweak in the code view.
October 03, 2006
Implementing Auto Updating Applications
[Edit May 2008] I no longer use MSI.Interop. That interop was full of bugs, lacked many features and was no longer actively being developed or supported. Instead I reccomend the new DTF SDK from Microsoft as released by WiX. DTF brings a new Microsoft.Deployment.WindowsInstaller library that just runs circles around MSI.Interop.
http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
One of the nice things about Per-Machine installations is that they are always managed. So provided that you get your ducks in a row following proper design patterns ( for example: Deferred Custom actions with the msidbCustomActionTypeNoImpersonate execute option and the SecureCustomProperties property ) you can simply advertise the package with the msiexec /JM command or run it as an Administrator and future upgrades can be serviced from the same source location without Administrative privileges by simply executing the update package with the REINSTALLMODE=vomus REINSTALL=ALL properties.
But wouldn't it be nice if the user didn't have to manually run the installation to perform the upgrade? Well, they don't. :) When you install your application you can save the OriginalDatabase or the ProductCode property somewhere your application can access it. With this information available to your application at runtime you can go find the MSI database and determine if there is a newer version available.
The following example in C# uses MSI.Interop.
using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;
using Pahvant.MSI;
namespace TestApp
{
class Program
{
static void Main(string[] args)
{
string msiPath = "C:\\TestApp.msi"; // Get this as described in the blog
Pahvant.MSI.Database database = new Pahvant.MSI.Database( msiPath, Pahvant.MSI.Database.OpenMode.ReadOnly );
Pahvant.MSI.View view = new Pahvant.MSI.View( database, "select `Value` from `Property` where `Property`='ProductVersion'");
view.Execute();
Record record = view.Fetch();
string productVersion = record.GetString(1);
if( Application.ProductVersion != productVersion )
// Call Prompt For Upgrade Method
}
}
}
If your upgrade method, you'll probably want to shell out to msiexec async and terminate to avoid a locked file during Costing. Bonus points will be awarded by your user if you also pass a public property to indicate that an automatic upgrade is occuring so that your install restarts the application when it's finished upgrading.
http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
One of the nice things about Per-Machine installations is that they are always managed. So provided that you get your ducks in a row following proper design patterns ( for example: Deferred Custom actions with the msidbCustomActionTypeNoImpersonate execute option and the SecureCustomProperties property ) you can simply advertise the package with the msiexec /JM command or run it as an Administrator and future upgrades can be serviced from the same source location without Administrative privileges by simply executing the update package with the REINSTALLMODE=vomus REINSTALL=ALL properties.
But wouldn't it be nice if the user didn't have to manually run the installation to perform the upgrade? Well, they don't. :) When you install your application you can save the OriginalDatabase or the ProductCode property somewhere your application can access it. With this information available to your application at runtime you can go find the MSI database and determine if there is a newer version available.
The following example in C# uses MSI.Interop.
using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;
using Pahvant.MSI;
namespace TestApp
{
class Program
{
static void Main(string[] args)
{
string msiPath = "C:\\TestApp.msi"; // Get this as described in the blog
Pahvant.MSI.Database database = new Pahvant.MSI.Database( msiPath, Pahvant.MSI.Database.OpenMode.ReadOnly );
Pahvant.MSI.View view = new Pahvant.MSI.View( database, "select `Value` from `Property` where `Property`='ProductVersion'");
view.Execute();
Record record = view.Fetch();
string productVersion = record.GetString(1);
if( Application.ProductVersion != productVersion )
// Call Prompt For Upgrade Method
}
}
}
If your upgrade method, you'll probably want to shell out to msiexec async and terminate to avoid a locked file during Costing. Bonus points will be awarded by your user if you also pass a public property to indicate that an automatic upgrade is occuring so that your install restarts the application when it's finished upgrading.
October 01, 2006
As mentioned on SlashDot, October is National Breast Awareness Month. In honor of my wife who is struggling with cancer we will be Going Pink For October.
September 19, 2006
Change Change Change
I've moved onto a new job and whew, I can confidently say after a year of beating my head against the wall trying to get these two piece of shit technologies to work:
Visual Studio Deployment Projects Suck!
Visual Studio Installer class Custom Actions Suck!
To quote Heath Stewart:
"Certainly. From an SE perspective, .vdproj outputs are difficult to service. You also can't do anything more advanced with them without modifying the reusltant [sic] MSI."
Recently Robmen mentioned that Derek Cicerone was departing WiX. During this post he mentioned that Derek was instrumental in getting the Visual Studio team
to adopt WiX for their installer. Everyone thought that this meant the VS team was also dumping .vdproj and replacing it with a WiX project type.
We could ONLY wish. So until that day comes, I urge you to sign the 'petition' and let Microsoft know what you think:
http://blogs.msdn.com/robmen/archive/2006/09/18/761580.aspx#comments
Visual Studio Deployment Projects Suck!
Visual Studio Installer class Custom Actions Suck!
To quote Heath Stewart:
"Certainly. From an SE perspective, .vdproj outputs are difficult to service. You also can't do anything more advanced with them without modifying the reusltant [sic] MSI."
Recently Robmen mentioned that Derek Cicerone was departing WiX. During this post he mentioned that Derek was instrumental in getting the Visual Studio team
to adopt WiX for their installer. Everyone thought that this meant the VS team was also dumping .vdproj and replacing it with a WiX project type.
We could ONLY wish. So until that day comes, I urge you to sign the 'petition' and let Microsoft know what you think:
http://blogs.msdn.com/robmen/archive/2006/09/18/761580.aspx#comments
September 15, 2006
Windows Vista RC1
If you have not already, it's time to go over to Microsoft and download a copy of Windows Vista RC1!
a
InstallShield 12 has put a lot of thought into Vista. I'd get it if you haven't already.
As a personal aside I recently purchased a Gateway MX6920 laptop from BestBuy for $799. Sporting 15.4" WXGA, 1.6Ghz Core Duo, 1GB of PC4200 DDR memory, Intel945GM graphics, 120GB 5400 RPM HDD, Dual-Layer DVD burner, 802.11a/b/g Wifi, USB 2.0, Firewire and 4-n-1 memory reader really runs Vista nicely. I could have spent less or more for a laptop but I think this is a pretty good sweet point for now.
a
InstallShield 12 has put a lot of thought into Vista. I'd get it if you haven't already.
As a personal aside I recently purchased a Gateway MX6920 laptop from BestBuy for $799. Sporting 15.4" WXGA, 1.6Ghz Core Duo, 1GB of PC4200 DDR memory, Intel945GM graphics, 120GB 5400 RPM HDD, Dual-Layer DVD burner, 802.11a/b/g Wifi, USB 2.0, Firewire and 4-n-1 memory reader really runs Vista nicely. I could have spent less or more for a laptop but I think this is a pretty good sweet point for now.
Change
Robmen has recently been hinting that a change was coming his way. Well the winds have changed for myself also and I'm moving on to new challenges. I'd like to say thanks for the memories to my friends at Overwatch Systems and say hello to my new friends at Hart InterCivic.
Subscribe to:
Posts (Atom)