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.
Historical archive 2003-2011
October 15, 2007
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.
October 08, 2007
WiX Code Is Pretty
I know that I frequently express my frustration with the WiX development experience. But there is one thing that I really like about WiX: How darn pretty the XML is. The declarative nature of MSI and the way the data is stored in multiple tables really makes it hard to describe an implementation detail in writing.
For example, I can describe an EXE CA stored in the binary table, scheduled in the execute sequence after InstallInitiatize with no impersonation and deferred execution.
If you have a solid MSI background, you probably have enough information to proceed. But if you are new at MSI and you need me to SHOW you how that all works it can be interesting trying to write it down.
One approach might be to try to describe the table relationships:
Binary Table
NewBinary1 stream in Notepad.exe data here
CustomAction Table
NewCustomAction1 3074 NewBinary1
InstallExecuteSequence Table
NewCustomAction1 1501
I might also try to express the relationships in .IDT format or perhaps MSI2XML ( which InstallShield uses ) but the end result is data that's hard to read and understand. After all, just what the heck is 3074 and 1501 without digging in to understand? Worse, it's not `code` that can be easily stolen ( umm, I mean copy and pasted hehehe ).
<Binary Id="Notepad.exe" SourceFile="notepad.exe"/>
<CustomAction
Return="check" HideTarget="no" Execute="deferred" Impersonate="no"
TerminalServerAware="no" ExeCommand="" BinaryKey="Notepad.exe"/>
<InstallExecuteSequence>
<Custom Action="CustomAction1" After="InstallInitialize" />
</InstallExecuteSequence>
Still, don't expect me to be reading/writing installs like Neo in the Matrix. IMO this is all great, but designers still rule in authoring the majority of my installation logic because of the productivity and reliability gains achieved in automating the authoring.
For example, I can describe an EXE CA stored in the binary table, scheduled in the execute sequence after InstallInitiatize with no impersonation and deferred execution.
If you have a solid MSI background, you probably have enough information to proceed. But if you are new at MSI and you need me to SHOW you how that all works it can be interesting trying to write it down.
One approach might be to try to describe the table relationships:
Binary Table
NewBinary1 stream in Notepad.exe data here
CustomAction Table
NewCustomAction1 3074 NewBinary1
InstallExecuteSequence Table
NewCustomAction1 1501
I might also try to express the relationships in .IDT format or perhaps MSI2XML ( which InstallShield uses ) but the end result is data that's hard to read and understand. After all, just what the heck is 3074 and 1501 without digging in to understand? Worse, it's not `code` that can be easily stolen ( umm, I mean copy and pasted hehehe ).
<Binary Id="Notepad.exe" SourceFile="notepad.exe"/>
<CustomAction
Return="check" HideTarget="no" Execute="deferred" Impersonate="no"
TerminalServerAware="no" ExeCommand="" BinaryKey="Notepad.exe"/>
<InstallExecuteSequence>
<Custom Action="CustomAction1" After="InstallInitialize" />
</InstallExecuteSequence>
Still, don't expect me to be reading/writing installs like Neo in the Matrix. IMO this is all great, but designers still rule in authoring the majority of my installation logic because of the productivity and reliability gains achieved in automating the authoring.
October 05, 2007
IEAK 7 - Another `Fake` MSI using WiX
MSI Expert Stefan Krueger recently blogged that Microsoft has released an updated IEAK 7 that now creates MSI files. I've had a chance to look at it and I can't help notice a few things. But first, let's go back in time a bit to Feb 2006 when Rob Mensching once blogged:
At the time I commented:
Well let's get back to the recent IEAK 7 release. Yes, you guessed it: Microsoft has once again done the exact same thing as Google. If you run the IEAK 7 wizard and build the MSI you'll notice that Microsoft ignored their very own setup expert and took a play straight out out of the Google playbook. They made a fake MSI package that doesn't publish the package and instead goes out of process to Setup.Exe to get the job done. All of this to get around the limitations of GPO without actually making the investment in MSI.
And of course the funniest thing is they used Windows Installer XML v2.0.3620.0 (candle/light) to get the job done. Just like Google.
Google Toolbar Beta for Enterprise includes a Microsoft Windows Installer package that makes organization-wide distribution a snap.
Cool. So, I downloaded the .zip file and popped open the GoogleToolbarInstaller.msi and what should I find? Yep, you guessed it. The GoogleToolbarInstaller.msi file was created by the WiX toolset. Woohoo! How cool is that? Google uses the WiX toolset.
After calming down, I decided to look around and see how well the MSI was actually put together. Then my excitement dropped. The GoogleToolbarInstaller MSI package is a total fake. Their MSI file is nothing more than a wrapper around the old GoogleToolbarInstaller.exe. The Google Toolbar Beta for Enterprise does not use the Windows Installer to actually install the files (I'm not sure what install technology they are using). That means the Google Toolbar Beta for Enterprise does not get all of the transaction guarantees and other administrative/repair features that a true Windows Installer package would provide.
If you are an administrator looking to deploy this package, don't be surprised when you find that this MSI package doesn't behave exactly like real Windows Installer packages. The Google Toolbar Beta for Enterprise MSI package is really just a "Trojan horse" carrying their custom installation system. I really wish Google had used the Windows Installer technology more appropriately.
At the time I commented:
Rob- I'm usually nodding my head with you, but come on, Microsoft did the EXACT same thing with the Windows Media Player 9 Administratios Deployment kit that we talked about a couple blogs ago. Perhaps if AD GPO wasn't so restrictive in only understanding MSI people wouldn't feel the need to wrap legacy installer in a pseudo-msi package.
Well let's get back to the recent IEAK 7 release. Yes, you guessed it: Microsoft has once again done the exact same thing as Google. If you run the IEAK 7 wizard and build the MSI you'll notice that Microsoft ignored their very own setup expert and took a play straight out out of the Google playbook. They made a fake MSI package that doesn't publish the package and instead goes out of process to Setup.Exe to get the job done. All of this to get around the limitations of GPO without actually making the investment in MSI.
And of course the funniest thing is they used Windows Installer XML v2.0.3620.0 (candle/light) to get the job done. Just like Google.
October 04, 2007
Deployment AntiPatterns
I recently came across a blog post from ScottGuthrie (MSFT) titled Tip/Trick: Automating Dev, QA, Staging, and Production Web.Config Settings with VS 2005. In his tip, Scott uses his build automation to produce multiple product configurations that stage different servers with different web.config files. He then gets dozens of ataboys comments from readers including one who wonders if this could be done for Winforms applications to which Scott replies
Now I'm sure Scott is a smart .NET developer, but this type of `xcopy deployment` that is tightly coupled to build automation is crazy. Furthermore, I know he's not alone in this thinking since if you pick up practically any .NET book you won't find deployment covered until the end of the book and even then it's a cursory look at VDPROJ as if deployment is that simple.
Build ( Core Code and Installer Packages ), Installation and Configuration are NOT the same thing. They are distinct steps in an overall process of deploying an application.
You may very well need to do all three of these steps within a single transaction ( for example automatically deploying an application to a Dev Integration Lab as part of a CI process ) but the steps are still separate.
Now some people disagree on whether an Install should actually configure a product or not. Regardless the build output should consist of a setup package. If you want to automate the deployment the build should then call staging automation to apply the package. If the package contains configuration logic, the staging automaton should pass those values to the package. If not, the staging automation should call an external utility and pass the values so that the product is ready to be used. In this way the staging automation could be invoked multiple times to stage Dev, QA, Production, whatever.
Scott's solution might be `OK` for an in house application that only gets `deployed` to a limited no of locations, but if you are working on a real `Product` that gets sold and given to customers all over the world you will really want to make a proper investment in automation.
Yes - you should be able to use the same approach with winforms projects.
Now I'm sure Scott is a smart .NET developer, but this type of `xcopy deployment` that is tightly coupled to build automation is crazy. Furthermore, I know he's not alone in this thinking since if you pick up practically any .NET book you won't find deployment covered until the end of the book and even then it's a cursory look at VDPROJ as if deployment is that simple.
Build ( Core Code and Installer Packages ), Installation and Configuration are NOT the same thing. They are distinct steps in an overall process of deploying an application.
You may very well need to do all three of these steps within a single transaction ( for example automatically deploying an application to a Dev Integration Lab as part of a CI process ) but the steps are still separate.
Now some people disagree on whether an Install should actually configure a product or not. Regardless the build output should consist of a setup package. If you want to automate the deployment the build should then call staging automation to apply the package. If the package contains configuration logic, the staging automaton should pass those values to the package. If not, the staging automation should call an external utility and pass the values so that the product is ready to be used. In this way the staging automation could be invoked multiple times to stage Dev, QA, Production, whatever.
Scott's solution might be `OK` for an in house application that only gets `deployed` to a limited no of locations, but if you are working on a real `Product` that gets sold and given to customers all over the world you will really want to make a proper investment in automation.
October 02, 2007
Using TFS and PowerGen to build PowerBuilder
Over 10 years ago, I cut my OO teeth on a language called PowerBuilder. It had a really cool object called the DataWindow which was very similar to .NET's DataGridView class. This was back in the heyday of waterfall, CMM, big hunking fat clients and script based procedural installs as Windows Installer wasn't invented yet. At some point I became the Build/Install lead on a very large military client/server system and I was introduced to a wonderful tool called PowerGen. You see, natively PowerBuilder only had a `project object` for interactivly building your code. There was also an API called ORCA that you could use ( and later OrcaScript ) but that really sucks. PowerGen had a project file, GUI editor and command line interface that turns it all into child's play.
To make a long story short, I thought I was done with PowerBuilder back in 2003. Then I took a job about a year ago that involved Build/Install work for a TFS/.NET SOA system that was headed in the SaaS direction. After taking care of that I was asked to see what could be done with their legacy PowerBuilder system. I was somewhat shocked to see that they were checking PBL's ( PowerBuilder Libraries... large binary source files that consume tons of space, slow down the VSS client and can't be diff'd ). Worse, they had a completly manual build process.
Fortunately PowerGen once again came to the rescue. After a little custom wiring along the lines of going out of process to build a VDPROJ project, I was able to come up with a solution that incorporated TFS and TeamBuild as the source control repository and build platform. I've since contributed a set of sample scripts that should be able to help point other PowerBuilder/TFS users in the right direction.
To make a long story short, I thought I was done with PowerBuilder back in 2003. Then I took a job about a year ago that involved Build/Install work for a TFS/.NET SOA system that was headed in the SaaS direction. After taking care of that I was asked to see what could be done with their legacy PowerBuilder system. I was somewhat shocked to see that they were checking PBL's ( PowerBuilder Libraries... large binary source files that consume tons of space, slow down the VSS client and can't be diff'd ). Worse, they had a completly manual build process.
Fortunately PowerGen once again came to the rescue. After a little custom wiring along the lines of going out of process to build a VDPROJ project, I was able to come up with a solution that incorporated TFS and TeamBuild as the source control repository and build platform. I've since contributed a set of sample scripts that should be able to help point other PowerBuilder/TFS users in the right direction.
September 26, 2007
Versioning MSI Packages: WiX vs InstallShield
I was reading a blog about using TFS to update the ProductVersion property in a WiX Source file before building an MSI package. I found the solution rather `interesting`: calling exec and going out of process to a PowerShell script to do a search and replace on the .wxs source during the AfterGet target.
I guess I shouldn't be too critical because God knows I've seen it done stranger ways in the past in InstallShield. I've seen using the automation interface, using the interface using reflection from .NET, using the Windows Installer automation when the package source .ISM is in Binary format, using MSDOM/XPath when the package source .ISM is in XML Format and calling VBS Postbuild steps to hit the build MSI. There are probably more strange ways out there but starting with InstallShield 2008 there really is a better way to do it.
IS2008 IsCmdBld and IsSaBld support a -y argument for passing ProductVersion into the build. For MSBuild support using the standard InstallShield targets file, you merely define $(InstallShieldProductVersion) and it's taken care of for you.
Yes, it really IS that easy.
BTW, if you really like how easy this is, you can thank me with a beer for requesting this particular feature.
Unfortunately as this other blog shows, WiX isn't as easy. You could always ask the WiX team to consider the feature request. Then again, you could always just use InstallShield instead since they actually listen to their customers.
I guess I shouldn't be too critical because God knows I've seen it done stranger ways in the past in InstallShield. I've seen using the automation interface, using the interface using reflection from .NET, using the Windows Installer automation when the package source .ISM is in Binary format, using MSDOM/XPath when the package source .ISM is in XML Format and calling VBS Postbuild steps to hit the build MSI. There are probably more strange ways out there but starting with InstallShield 2008 there really is a better way to do it.
IS2008 IsCmdBld and IsSaBld support a -y argument for passing ProductVersion into the build. For MSBuild support using the standard InstallShield targets file, you merely define $(InstallShieldProductVersion) and it's taken care of for you.
Yes, it really IS that easy.
BTW, if you really like how easy this is, you can thank me with a beer for requesting this particular feature.
Unfortunately as this other blog shows, WiX isn't as easy. You could always ask the WiX team to consider the feature request. Then again, you could always just use InstallShield instead since they actually listen to their customers.
Subscribe to:
Posts (Atom)