This blog post is going to be a continual work in progress. Please feel free to contribute to the list via a comment.
Windows Installer Useful Web Sites
Installation Phases and In-Script Execution Options for Custom Actions in Windows Installer
Historical archive 2003-2016
Thursday, November 29, 2007
More Interesting and Uninteresting Comments
Stefan Krueger recently waded into the custom action debate with some very interesting comments.
Stefan references my believe in InstallScript custom actions and mentions a couple downsizes. Mainly Installscript engine size ( package bloat ), possibility of InstallScript engine failure and the temptation to use InstallScript CA's to make system configuration changes instead of built-in MSI patterns. Specifically he says:
Personally my packages tend to be very large and complex so the engine overhead is a non-issue to me. However, I could see it could be a consideration for small packages. I've also found the InstallScript engine to be very reliable.
I find InstallScript's ability to call Win32 API, COM and ManagedCode with very little plumbing ( let's just say you won't be worrying about things like allocating memory, casting datatypes and hosting COM servers and the CLR ) to be one of the strongest reasons for using InstallScript. For example, in one of my client installs I prompt the user for the hostname and port number of an application server. I then pass this information off to a .NET class that invokes uses the information to invoke a webservice. Anyone want to take a guess at how many lines of InstallScript and C# that is? Anyone want to take a guess how many lines that would be in C++? I've been using this code in production for 1 1/2 years now and I've never ever seen it fail.
Another example would be where you need to make a change that MSI doesn't support. The built-in MSI functions make it easy to implement the database queries needed to author data driven CA's and the extensibility makes it easy to interop with whatever external API you need to talk to install, uninstall, commit or rollback the configuration change.
Now for the uninteresting comment. A developer named Carl replied to Stefan's blog with this nugget:
Well, I've said it before and I'll say it again. Some developers just LOVE to HATE InstallShield. Here is another developer who's convinced that I'm wrong and InstallShield sucks. Never mind that he doesn't know the difference between an InstallScript MSI and a Basic MSI with InstallScript CA. Never mind that he mentions InstallShield 7 and that he prefers to use ( shudder ) VBSCript CA's. InstallShield is evil and they have conned the world.
Stefan references my believe in InstallScript custom actions and mentions a couple downsizes. Mainly Installscript engine size ( package bloat ), possibility of InstallScript engine failure and the temptation to use InstallScript CA's to make system configuration changes instead of built-in MSI patterns. Specifically he says:
However I believe that the tasks of a custom action often aren't typical installation tasks (copying files, accessing the registry) but require calling some APIs to interact with other applications.
Personally my packages tend to be very large and complex so the engine overhead is a non-issue to me. However, I could see it could be a consideration for small packages. I've also found the InstallScript engine to be very reliable.
I find InstallScript's ability to call Win32 API, COM and ManagedCode with very little plumbing ( let's just say you won't be worrying about things like allocating memory, casting datatypes and hosting COM servers and the CLR ) to be one of the strongest reasons for using InstallScript. For example, in one of my client installs I prompt the user for the hostname and port number of an application server. I then pass this information off to a .NET class that invokes uses the information to invoke a webservice. Anyone want to take a guess at how many lines of InstallScript and C# that is? Anyone want to take a guess how many lines that would be in C++? I've been using this code in production for 1 1/2 years now and I've never ever seen it fail.
Another example would be where you need to make a change that MSI doesn't support. The built-in MSI functions make it easy to implement the database queries needed to author data driven CA's and the extensibility makes it easy to interop with whatever external API you need to talk to install, uninstall, commit or rollback the configuration change.
Now for the uninteresting comment. A developer named Carl replied to Stefan's blog with this nugget:
Christopher Painter is wrong. InstallScript MSIs are never appropriate. Leveraging the language into MSIs was dreamed up by InstallShield's marketing team to con people into 'upgrading' to InstallShield 7 saying that "you can upgrade to MSI and your old scripted package will still work"
It had no place in an MSI then, and it has none now.
Personally I like VBScript. It has the advantages of being easy to read, open source and can be debugged from within the MSI using the MSOffice debugger.
Well, I've said it before and I'll say it again. Some developers just LOVE to HATE InstallShield. Here is another developer who's convinced that I'm wrong and InstallShield sucks. Never mind that he doesn't know the difference between an InstallScript MSI and a Basic MSI with InstallScript CA. Never mind that he mentions InstallShield 7 and that he prefers to use ( shudder ) VBSCript CA's. InstallShield is evil and they have conned the world.
InstallShield 2008 Beta Support for Visual Studio 2008
Monday, November 26, 2007
WiX Takes The Next Step
I was reading on Windows Installer Expert Stefan Krueger's InstallSite Blog today that that the Visual Studio team is finally incorporating WiX into VSTS. I am very pleased to hear this and I can't help think `about time`. :-)
Regular readers of my blog are no doubt aware that I've been advocating over and over for months that Microsoft make WiX a priority.
Getting the core tool set in VSTS is a very good step but there is still a huge gap in the authoring/designer/editing tools. Considering Microsoft has purchased other products for inclusion in VSTS ( TeamPlain ), I think Microsoft should seriously consider purchasing WiXAware and incorporating it into VSTS as well. This would be a very potent combination of technology that would really make me rethink which tools I use to write my installs.
Eitherway, congratulations go to Rob Mensching.
Regular readers of my blog are no doubt aware that I've been advocating over and over for months that Microsoft make WiX a priority.
Getting the core tool set in VSTS is a very good step but there is still a huge gap in the authoring/designer/editing tools. Considering Microsoft has purchased other products for inclusion in VSTS ( TeamPlain ), I think Microsoft should seriously consider purchasing WiXAware and incorporating it into VSTS as well. This would be a very potent combination of technology that would really make me rethink which tools I use to write my installs.
Eitherway, congratulations go to Rob Mensching.
Wednesday, October 24, 2007
InstallScript Custom Actions are GOOD
We've long heard the rants against Script based CA's, Managed Code CA's and CA's in general. Lately Microsoft has begun blogging about the horrors of even EXE CA's.
IMO when talking about CA problems, is isn't really the CA that is the problem. The problem is in the CA hosting models and therefore it's really MSI that is the problem. And when preaching against CA's in general, yes it is true, somewhere north of 90% of the CA's written by developers truly aren't needed. However the other 10% is really a result of MSI not being `feature complete` as defined by the customer instead of as defined by Microsoft. Unfortunately there doesn't seem to be any change coming in the near future.
So where does that leave us? Type 1 DLL standard call CA's:
But wait, who says they have to be written in C++? Well, no one does really. You see, as I previously blogged, starting with InstallShield 12 InstallScript CA's are really just unmanaged Type 1 CA's.
While there are a couple downsides ( mainly larger package size and slightly slower execution ), I think the upsides far outweigh them.
InstallScript is:
Not based on ActiveScript / Windows Scripting Host.
A C like language that is easier to code in then C++.
A domain specific language that has many proven functions for tackling setup related problems. This results in increased reliability as you aren't making stupid mistakes trying to roll your own everything and reinventing the wheel in C++.
Integrated into InstallShield. This makes it easier to develop, build and test in one easy to use IDE.
Doesn't add additional dependencies to your install. You won't need setup.exe to deploy some runtime to run your CA. You also won't find broken installs because someone built the debug C++ bits or didn't include some C++ runtime dll.
Can be transplanted into other installs. Stream out of one binary table and into another. It'll even work when writing transforms for packages made in other authoring tools.
Can easily use MSI API's to create data driven CA's.
I'm sure I could go on and on but I'll stop right there. InstallScript has really come a long way and is the right tool for the right job.
IMO when talking about CA problems, is isn't really the CA that is the problem. The problem is in the CA hosting models and therefore it's really MSI that is the problem. And when preaching against CA's in general, yes it is true, somewhere north of 90% of the CA's written by developers truly aren't needed. However the other 10% is really a result of MSI not being `feature complete` as defined by the customer instead of as defined by Microsoft. Unfortunately there doesn't seem to be any change coming in the near future.
So where does that leave us? Type 1 DLL standard call CA's:
Ultimately, avoiding CAs is the best approach but, when necessary, you should develop DLL CAs. Immediate DLL CAs can read from the installer package database and should be data driven, making it easier to service that data and providing perhaps some transparency to what your CA does. Those immediate CAs can then schedule deferred, rollback, and commit CAs as necessary based on that data and the current state of the machine. -Heath Stewart
But wait, who says they have to be written in C++? Well, no one does really. You see, as I previously blogged, starting with InstallShield 12 InstallScript CA's are really just unmanaged Type 1 CA's.
While there are a couple downsides ( mainly larger package size and slightly slower execution ), I think the upsides far outweigh them.
InstallScript is:
Not based on ActiveScript / Windows Scripting Host.
A C like language that is easier to code in then C++.
A domain specific language that has many proven functions for tackling setup related problems. This results in increased reliability as you aren't making stupid mistakes trying to roll your own everything and reinventing the wheel in C++.
Integrated into InstallShield. This makes it easier to develop, build and test in one easy to use IDE.
Doesn't add additional dependencies to your install. You won't need setup.exe to deploy some runtime to run your CA. You also won't find broken installs because someone built the debug C++ bits or didn't include some C++ runtime dll.
Can be transplanted into other installs. Stream out of one binary table and into another. It'll even work when writing transforms for packages made in other authoring tools.
Can easily use MSI API's to create data driven CA's.
I'm sure I could go on and on but I'll stop right there. InstallScript has really come a long way and is the right tool for the right job.
Monday, October 15, 2007
Some Good News
We received some good news on Saturday. Cheryl's MRI came back and there is no cancer in her brain. We are so relieved as that's not a road that we want to go down.
Still, we do face some new challenges now that Cheryl has a history of seizures. The neurologist has started her on some medication that takes awhile to adjust to. Basically I'll be taking the next week off of work to be with her and the girls until her parents arrive.
And to make life as interesting as possible, Ashley came down with the stomach bug in the middle of the night and Emma had a swollen and purple finger from an infection caused by a splinter. I just love running to three different Dr's offices in 24 hours!!!
Here's praying for better health in the days, months and years to come. Thank you everyone who's been there for me.
Still, we do face some new challenges now that Cheryl has a history of seizures. The neurologist has started her on some medication that takes awhile to adjust to. Basically I'll be taking the next week off of work to be with her and the girls until her parents arrive.
And to make life as interesting as possible, Ashley came down with the stomach bug in the middle of the night and Emma had a swollen and purple finger from an infection caused by a splinter. I just love running to three different Dr's offices in 24 hours!!!
Here's praying for better health in the days, months and years to come. Thank you everyone who's been there for me.
Friday, October 12, 2007
Exhausted from Cancer
Today was a very trying day that started with a call to 911 at 4am followed by 15 hours at a local hospital. I'm so mentally and physically exhausted right now that it's easier to just share my wife's perspective ( made possible by laptops and hospital WiFI ). My perspective would be too disturbing to post since I actually witnessed and responded to the seizure.
I guess I should be grateful for the first aid / first responder training that I've had over the years. One of my personal hobbies is Scuba Diving and in the Rescue Diver and Nitrox courses we discussed handling O2 toxicity problems including grand mal seizures. I just never imagined that I'd be dealing with it on dry land while waking up from sleep.
Early this morning we had a horrible scare. I had a grand mal seizure occur around 4:00 am. Chris was able to get me on my side, make sure I wasn't choking, and called the ambulance. All I remember is waking up to several paramedics in our room.
At this point, we are at Seton NW Hospital. They have already done an X-ray, CT scan to see if there was anything. They are planning to admit me for 1-2 days. During that time I'll have a spinal tap and an MRI done to see if there is anything happening in my brain. I will probably be put on anti-seizure medicine.
I am so grateful my in-laws are in town to help with the girls. My sister and Chris are with me right now. Please pray they find nothing in my brain, specifically no new tumours, and that this is just a 'fluke'.
I guess I should be grateful for the first aid / first responder training that I've had over the years. One of my personal hobbies is Scuba Diving and in the Rescue Diver and Nitrox courses we discussed handling O2 toxicity problems including grand mal seizures. I just never imagined that I'd be dealing with it on dry land while waking up from sleep.
Subscribe to:
Posts (Atom)