Here is an interesting read from Bob Corrigan:
ack/nak: idea: don't sell to the wrong buyers
Historical archive 2003-2011
March 27, 2008
March 22, 2008
Windows Installer 4.5 Beta 2 is available.
I just got the word two hours ago:
"Hello Windows Installer (MSI) 4.5 Beta Testers!
"Hello Windows Installer (MSI) 4.5 Beta Testers!
This message is to let you know that we have just made the Windows Installer 4.5 Beta 2 build, tools and documentation available on Microsoft Connect. This is our last planned beta release before we ship Windows Installer 4.5, so your feedback is especially important at this stage. Please log into the Windows Installer 4.5 beta program on Microsoft Connect today to access the new bits!
- Tyler Robinson, Windows Installer Lead PM"
Go to http://connect.microsoft.com/ and subscribe to the beta if you haven't already.
March 20, 2008
Another Release Engineer Needed
A little while back I posted about a job opening at CompassLearning and now I have another position that needs to be filled. If you live or want to relocate to the Austin area and you are interested in joining my newly forming build and install team, I'd really love to hear from you. It's going to be a lot of work but I really think it's going to be fun.
Software Developer – Software Build Engineer
Multimedia Games is a leading supplier of interactive systems, electronic games, and player terminals for the Native American gaming market, as well as the growing casino, charity bingo and video lottery markets. Multimedia designs and develops networks, software and content that provide its customers with comprehensive gaming systems delivered through a telecommunications network that links its player terminals with one another both within and among gaming facilities. The Company’s ongoing development and marketing efforts focus on Class II and Class III gaming systems and products for use by Native American tribes throughout the United States, video lottery systems and other products for domestic and international lotteries, and products for charity bingo opportunities.
This developer position is responsible for the implementation and ongoing support of a complex automated software configuration management system. The position will be responsible for contributing to development of the tools used in the software build process and for Installer development. Participation in the implementation of automated deployment systems is also likely. Under the guidance of a senior Deployment Engineer, the candidate must be able to support these internal production systems and contribute to the improvement of same.
Education and Experience: B.S. in Computer Science and 1-3 years of experience in software configuration management and automated software build systems.
Required Skills: Candidates must possess strong knowledge of: Version Control systems such as StarTeam and AccuRev, support of complex automated software build processes, experience with Installshield and Microsoft Installer technologies, and Microsoft SMS or similar software distribution systems. NET 2.0 (C#) development experience is also required.
In addition to the technical skills listed above, the candidate must possess strong organizational skills, be a self starter, highly motivated, and be very customer service oriented.
Desired Skills: Development experience with Microsoft Active Directory, experience with virtualization systems such as Virtual Server 2005 or VMWare, and basic web services development experience. Experience with automation of Build smoke testing and QA system imaging once builds have been smoke tested is a plus.
Multimedia Games, Inc. is an Equal Opportunity Employer
No agencies please.
Software Developer – Software Build Engineer
Multimedia Games is a leading supplier of interactive systems, electronic games, and player terminals for the Native American gaming market, as well as the growing casino, charity bingo and video lottery markets. Multimedia designs and develops networks, software and content that provide its customers with comprehensive gaming systems delivered through a telecommunications network that links its player terminals with one another both within and among gaming facilities. The Company’s ongoing development and marketing efforts focus on Class II and Class III gaming systems and products for use by Native American tribes throughout the United States, video lottery systems and other products for domestic and international lotteries, and products for charity bingo opportunities.
This developer position is responsible for the implementation and ongoing support of a complex automated software configuration management system. The position will be responsible for contributing to development of the tools used in the software build process and for Installer development. Participation in the implementation of automated deployment systems is also likely. Under the guidance of a senior Deployment Engineer, the candidate must be able to support these internal production systems and contribute to the improvement of same.
Education and Experience: B.S. in Computer Science and 1-3 years of experience in software configuration management and automated software build systems.
Required Skills: Candidates must possess strong knowledge of: Version Control systems such as StarTeam and AccuRev, support of complex automated software build processes, experience with Installshield and Microsoft Installer technologies, and Microsoft SMS or similar software distribution systems. NET 2.0 (C#) development experience is also required.
In addition to the technical skills listed above, the candidate must possess strong organizational skills, be a self starter, highly motivated, and be very customer service oriented.
Desired Skills: Development experience with Microsoft Active Directory, experience with virtualization systems such as Virtual Server 2005 or VMWare, and basic web services development experience. Experience with automation of Build smoke testing and QA system imaging once builds have been smoke tested is a plus.
Multimedia Games, Inc. is an Equal Opportunity Employer
No agencies please.
InstallShield 2009 Beta Part II ( Managed CA's )
Edit:
As an aside, as much as I appreciate the work Acresso did on Managed CA's, DTF is a better direction to go.
1) It solves the problem of tatooing the msi process with a fixed version of the CLR
2) It's linker ( MakeSfxCa ) is more flexible for including dependencies an
3) The interop is simply better
4) The hosting process has a better debugging story
5) It's open source so it's easier to see problems and get resolutions to issues
6) It's not tied to one vendors authoring tools
In previous posts I've discussed the use of the InstallScript function CoCreateObjectDotNet()to include Managed Code in your InstallScript custom actions without any installation or registration of .NET assemblies. Still this had the downside of having to write InstallScript CA's to act as a wrappers for your managed assembly. This increased the complexity of the solution and added slightly to the package size and execution latency.
In late 2006 I had an email discussion with Robert Dickau where I suggested the possibility of supporting managed code CA's directly similar to the way InstallShield already has support for non Type1 DLL function exports via the "New Standard DLL" pattern. I also suggested that it would be good if they could support passing the MSI handle and providing a simple C# SDK that included a basic MSI interop.
While I'm not sure if I really inspired the next feature or if it's just a case of great minds think alike ( except for certain great minds who seem hell bent on denying the fact that managed code is the future of windows development), InstallShield development has once again jumped in with some really cool stuff:
Support for Managed-Code Custom Actions
InstallShield lets you add managed-code custom actions to Basic MSI, InstallScript MSI, Merge Module, and Web projects. This type of custom action calls a public method in a .NET assembly that is written in managed code such as Visual Basic .NET or C#.
Ok, that doesn't really give it justice. Let me show you a simple example. Let's say you are writing a VSTO 3.0 Installer and you need a random number to write to the Office 2007 Count Registry Value. You could break out a C++ compiler and track down a standard library for generating a random number and build it as a MSI Type 1 DLL CA, but the odds are increasing every day that your team doesn't have those obsolete skills anymore but instead is getting really good at writing managed code in C# or maybe VB.NET. Since you are deploying a VSTO installer you already have a dependency on the framework so why not just put the BCL to work for you?
Consider this simple code fragment:
Now let's wire it up into InstallShield 2009:
We browse to the DLL ( Just like other CA types ):
Now here is where it gets a little cooler. With standard DLL's you have to export them as stdcall and use Depends to confirm the function name. With CoCreateObjectDotNet() the assembly has to be attributed as ComVisible(true). However, with the new pattern you don't need ComVisible and InstallShield uses reflection to help you complete the contract:
Now let's assign the return code to a public property:
Finally, let's schedule it in the sequences:
Finally, let's just display it on the welcome dialog so we can see it works:
That's pretty much all there is to it. You may have noticed that I scheduled the CA in both the Install UI and Install Execute sequences and set it to only execute once. This means I'll have to add the public property to SecureCustomProperties if I expect the data to persist during UAC/Elevated/Managed full UI installs. Otherwise I'm ready to use this property in the Registry table as [RANDOMNUMBER].
If you are curious how it works, you'll have to download the beta. Take a look at the CustomAction and ISClrWrap tables.
BTW there is also the possibility of using a "standard signature" which allows passing the MSI handle. There is rumors that Beta 2 will have an interop included so I'll have to show how that pattern would work at a later date.
As an aside, as much as I appreciate the work Acresso did on Managed CA's, DTF is a better direction to go.
1) It solves the problem of tatooing the msi process with a fixed version of the CLR
2) It's linker ( MakeSfxCa ) is more flexible for including dependencies an
3) The interop is simply better
4) The hosting process has a better debugging story
5) It's open source so it's easier to see problems and get resolutions to issues
6) It's not tied to one vendors authoring tools
In previous posts I've discussed the use of the InstallScript function CoCreateObjectDotNet()to include Managed Code in your InstallScript custom actions without any installation or registration of .NET assemblies. Still this had the downside of having to write InstallScript CA's to act as a wrappers for your managed assembly. This increased the complexity of the solution and added slightly to the package size and execution latency.
In late 2006 I had an email discussion with Robert Dickau where I suggested the possibility of supporting managed code CA's directly similar to the way InstallShield already has support for non Type1 DLL function exports via the "New Standard DLL" pattern. I also suggested that it would be good if they could support passing the MSI handle and providing a simple C# SDK that included a basic MSI interop.
While I'm not sure if I really inspired the next feature or if it's just a case of great minds think alike ( except for certain great minds who seem hell bent on denying the fact that managed code is the future of windows development), InstallShield development has once again jumped in with some really cool stuff:
Support for Managed-Code Custom Actions
InstallShield lets you add managed-code custom actions to Basic MSI, InstallScript MSI, Merge Module, and Web projects. This type of custom action calls a public method in a .NET assembly that is written in managed code such as Visual Basic .NET or C#.
Ok, that doesn't really give it justice. Let me show you a simple example. Let's say you are writing a VSTO 3.0 Installer and you need a random number to write to the Office 2007 Count Registry Value. You could break out a C++ compiler and track down a standard library for generating a random number and build it as a MSI Type 1 DLL CA, but the odds are increasing every day that your team doesn't have those obsolete skills anymore but instead is getting really good at writing managed code in C# or maybe VB.NET. Since you are deploying a VSTO installer you already have a dependency on the framework so why not just put the BCL to work for you?
Consider this simple code fragment:
Now let's wire it up into InstallShield 2009:
We browse to the DLL ( Just like other CA types ):
Now here is where it gets a little cooler. With standard DLL's you have to export them as stdcall and use Depends to confirm the function name. With CoCreateObjectDotNet() the assembly has to be attributed as ComVisible(true). However, with the new pattern you don't need ComVisible and InstallShield uses reflection to help you complete the contract:
Now let's assign the return code to a public property:
Finally, let's schedule it in the sequences:
Finally, let's just display it on the welcome dialog so we can see it works:
That's pretty much all there is to it. You may have noticed that I scheduled the CA in both the Install UI and Install Execute sequences and set it to only execute once. This means I'll have to add the public property to SecureCustomProperties if I expect the data to persist during UAC/Elevated/Managed full UI installs. Otherwise I'm ready to use this property in the Registry table as [RANDOMNUMBER].
If you are curious how it works, you'll have to download the beta. Take a look at the CustomAction and ISClrWrap tables.
BTW there is also the possibility of using a "standard signature" which allows passing the MSI handle. There is rumors that Beta 2 will have an interop included so I'll have to show how that pattern would work at a later date.
March 19, 2008
InstallShield 2009 Beta Part I ( Multiple Instances )
I'm not really sure if I can talk about this or not.... so lets just say I didn't sign an NDA and don't take anything I say here as some kind of future looking statement or something. In other words, anything can change from the beta to gold.
That said, I've been so swamped lately that I really haven't given this the attention it deserves: InstallShield 2009 is in beta and I'm really excited about a couple features!
At my last job, I was responsible for build and install for a single tenant SaaS system that consisted of ASP.NET WebServices, WinUI and WebUI clients. This system lent itself to needing the ability to have different versions installed in parallel with different configuration options. At the time, InstallShield 12 had the ability to generate and embed product code changing multiple instance transforms but the bootstrapper lacked the ability to service these instances. As a result I authored a custom bootstrapper that interacted with the MSI API and simple reflection against the MSI database to connect the pieces into a solution that looked very much like InstallScripts multiple instance support. In fact I wrote about this on my blog: Multiple Instance MSI's and InstallShield 12. This blog article has continued to be very popular among my visitors.
Well to make a long story short, I met the InstallShield development team last year and decided to give them an informal presentation on where I though a future version of InstallShield could go. And go did they:
Support for Installing Multiple Instances of a Product
InstallShield now includes support for creating an installation that allows an .msi package to be used to install multiple instances of a product in the same context on the same machine. Use the new Multiple Instances tab for a product configuration in the Releases view to define different instances of your product and configure the properties that are associated with each instance.
At build time, InstallShield creates a product code–changing instance transform for each instance and streams the instance transforms into the .msi package. At run time, the setup launcher displays a new instance selection dialog that lets end users specify whether they want to install a new instance, or update or maintain an already installed instance.
In addition, if you build a patch in the Patch Design view for a product whose installation includes multiple-instance support, InstallShield now creates a patch that enables end users to update a specific instance or all instances. At run time, the Update.exe file displays a patch version of the instance selection dialog.
A new /instance command-line option is available for Setup.exe and Update.exe. This option lets you specify which instance you want to install, update, or uninstall; it also lets you suppress the instance selection dialog.
Multiple-instance support is available for Basic MSI and Web projects.
But this is but one of many great new features that should be in InstallShield 2009. I'll write about more of them when I get some free time. ( Hint: MSI 4.5 support, Feature linked Prereqs, .NET Managed Code Custom Actions without InstallScript and without ComVisible(true), ability to use an MSI handle and MSI interop from within the CA ) and much much more.
March 13, 2008
Examining the Tao of the Windows Installer: Rule 1
The Tao of the Windows Installer has been around for quite a while, but I figured this would be a good time to revisit this very comprehensive set of rules and add my own experiences with these rules.
Rule 1: Learn the Windows Installer Technology
The importance of this rule cannot be overstated. If you only follow one rule, this is the one to choose.
Microsoft Product Support often speak to Installer users who are installing packages which they created with a sophisticated high-level re-packaging tool, without any understanding of how the Installer actually works. While these tools are excellent at what they do and they abstract the user from the details on a day-to-day basis, the lack of Installer knowledge becomes a real problem when the package does not work as expected. Setup authoring is not simply about copying files. The Installer offers extensive functionality and complexity; understand it before you start authoring packages.
Start with this guide, then read the white papers, books, etc mentioned in the Resources section, then follow Rule 2.
The Windows Installer team has picked a very good rule for the first rule. There is certainly not a lack of installer products to choose from when developing installers. As pointed out in the first rule of the Tao, this can be a debilitating crutch for many people.
I was working for Wise Solutions when many ISVs were starting to make the switch from script-based installers to Windows Installer. If you are familiar with the Wise products, you will notice that the "Installation Expert" looks extremely similar between both products. The same is true with the InstallShield products, the wizard front-end is nearly identical. This of course made the switch easier to Windows Installer, but with the product performing all the magic in the background, many people did not grasp the intricacies of Windows Installer.
The number of calls to customer support shot up very quickly. If someone had problems with a registry edit for instance, they were accustomed to being able to examine the script and make any necessary edits. With the Windows Installer products, they are now presented with a massive relational database and not much guidance on where to start.
One of the things we used to do during our Wise training courses was have the students create an installation using ONLY the tables. This was akin to opening up Orca and creating a very basic installation (which we later did in our Inside Windows Installer course). It was very uncomfortable for most people, but that is really one of the best ways to learn. Take a step outside of your comfort zone.
I can't overemphasize this point enough. I was "fortunate" enough to be forced to learn Windows Installer the hard way. I don't think I would have the same understanding that I have today had I exclusively used the available third party tools on the market. To this day, there are things I still prefer to do in Orca (ICE validation, transforms, quick edits for testing, etc.). Give it a shot. Fire up Orca and have some fun with it.
Rule 1: Learn the Windows Installer Technology
The importance of this rule cannot be overstated. If you only follow one rule, this is the one to choose.
Microsoft Product Support often speak to Installer users who are installing packages which they created with a sophisticated high-level re-packaging tool, without any understanding of how the Installer actually works. While these tools are excellent at what they do and they abstract the user from the details on a day-to-day basis, the lack of Installer knowledge becomes a real problem when the package does not work as expected. Setup authoring is not simply about copying files. The Installer offers extensive functionality and complexity; understand it before you start authoring packages.
Start with this guide, then read the white papers, books, etc mentioned in the Resources section, then follow Rule 2.
The Windows Installer team has picked a very good rule for the first rule. There is certainly not a lack of installer products to choose from when developing installers. As pointed out in the first rule of the Tao, this can be a debilitating crutch for many people.
I was working for Wise Solutions when many ISVs were starting to make the switch from script-based installers to Windows Installer. If you are familiar with the Wise products, you will notice that the "Installation Expert" looks extremely similar between both products. The same is true with the InstallShield products, the wizard front-end is nearly identical. This of course made the switch easier to Windows Installer, but with the product performing all the magic in the background, many people did not grasp the intricacies of Windows Installer.
The number of calls to customer support shot up very quickly. If someone had problems with a registry edit for instance, they were accustomed to being able to examine the script and make any necessary edits. With the Windows Installer products, they are now presented with a massive relational database and not much guidance on where to start.
One of the things we used to do during our Wise training courses was have the students create an installation using ONLY the tables. This was akin to opening up Orca and creating a very basic installation (which we later did in our Inside Windows Installer course). It was very uncomfortable for most people, but that is really one of the best ways to learn. Take a step outside of your comfort zone.
I can't overemphasize this point enough. I was "fortunate" enough to be forced to learn Windows Installer the hard way. I don't think I would have the same understanding that I have today had I exclusively used the available third party tools on the market. To this day, there are things I still prefer to do in Orca (ICE validation, transforms, quick edits for testing, etc.). Give it a shot. Fire up Orca and have some fun with it.
March 10, 2008
Release Engineer Needed
If you are an Expert in MSI / InstallShield and interested in working on a very, very large install, you might want to check out this open position at CompassLearning. I interviewed with the team and I was extremely interested in the project but ultimately I had to turn the position down for mostly personal reasons.
Shoot me an email if you are interested and I'll put you in contact with the hiring manager.
Company: CompassLearning
Job Title: Release Engineer
Description: Job description:
You will work closely as a member of the Build/Release team within CompassLearning Product Development organization in a dynamic, fast-paced environment where your abilities to multi-task, fire-fight, and your passion for automation and efficiency will help you excel at your job. You are highly self-directed and team oriented. Your initiative and flexibility in an ever changing environment will be critical to our success and our continued ability to scale. You will make an immediate difference at CompassLearning with your exceptional scripting abilities and your in-depth knowledge of installation and deployment processes. Most importantly, you will constantly be on the lookout for ways to streamline, enhance and automate release processes, and thus continue to refine and redefine your position.
Responsibilities:
• Design and develop installation packages in InstallShield.
• Manage source control activities including detailed access permissions, branching, labeling, development merges, and auditing.
• Set up and maintain lab for build machines and release engineering servers.
Requirements:
• Expertise writing installers - specifically Install Shield, and InstallShield Scripting
• Bachelor’s degree in Computer Science, Computer Engineering, or some other related discipline.
• At least 5+ years experience in build/release engineering and configuration management with thorough knowledge of all phases of the software development life cycle.
• Strong hands-on experience with shell scripting, Perl, DOS batch etc.
Desired Skills:
• Exposure to automation tools like Cruise Control
• 1-2 years of Java and/or C++
• Experience with databases – MS SQL Server, Oracle, MySQL, etc.
• 1-2 years experience in building and delivering automation infrastructure implemented in .NET and Nant
Shoot me an email if you are interested and I'll put you in contact with the hiring manager.
Company: CompassLearning
Job Title: Release Engineer
Description: Job description:
You will work closely as a member of the Build/Release team within CompassLearning Product Development organization in a dynamic, fast-paced environment where your abilities to multi-task, fire-fight, and your passion for automation and efficiency will help you excel at your job. You are highly self-directed and team oriented. Your initiative and flexibility in an ever changing environment will be critical to our success and our continued ability to scale. You will make an immediate difference at CompassLearning with your exceptional scripting abilities and your in-depth knowledge of installation and deployment processes. Most importantly, you will constantly be on the lookout for ways to streamline, enhance and automate release processes, and thus continue to refine and redefine your position.
Responsibilities:
• Design and develop installation packages in InstallShield.
• Manage source control activities including detailed access permissions, branching, labeling, development merges, and auditing.
• Set up and maintain lab for build machines and release engineering servers.
Requirements:
• Expertise writing installers - specifically Install Shield, and InstallShield Scripting
• Bachelor’s degree in Computer Science, Computer Engineering, or some other related discipline.
• At least 5+ years experience in build/release engineering and configuration management with thorough knowledge of all phases of the software development life cycle.
• Strong hands-on experience with shell scripting, Perl, DOS batch etc.
Desired Skills:
• Exposure to automation tools like Cruise Control
• 1-2 years of Java and/or C++
• Experience with databases – MS SQL Server, Oracle, MySQL, etc.
• 1-2 years experience in building and delivering automation infrastructure implemented in .NET and Nant
March 09, 2008
Why I've Been Quiet
I've had a lot of things on my mind that I really wanted to investigate and share but it's really been a crazy tired year so far. Seriously, I must be busy as heck if I haven't even had a chance to install the InstallShield 2009 beta and start taking a look at new features that originated out of discussions I had with the InstallShield team last spring.
On a personal front my wife Cheryl has had her liver and lung surgeries and is now back on chemotherapy. All of our family has been visiting and really helping out a great deal.
Finally, I decided that it was time for me to move on at my day job. During my time at Hart InterCivic/Manatron I've really stirred up the pot and effected a whole lot of positive change. However, at this time my work as a build/install guy is pretty much complete and it has become obvious to me that it's time for me to stake out my next challenge and attack it.
I spent a couple weeks meeting with potential employers, listening to their needs and considering the needs of my family. As a result of this I've decided to leave Manatron on March 14th and joining Multimedia Games.
Of course this just made me even more busy! One of these days I'm actually going to kick back and relax when I become a short timer instead of burning the candle on both ends trying to close every project known to man king. Ever since Manatron purchased my group last year, we've had an office relocation and a domain migration project on our schedule that kept getting delayed. Naturally these projects come to a boil the moment that I give notice. So for the last week I've been burning the hours planning and executing the transition of all of our systems to it's new environment. If that wasn't enough I've been going through countless `knowledge transfer` sessions where people try to learn everything I know.
Which BTW, how does one cover the subject `Windows Installer/InstallShield In-Depth` in 90 minutes?
On a personal front my wife Cheryl has had her liver and lung surgeries and is now back on chemotherapy. All of our family has been visiting and really helping out a great deal.
Finally, I decided that it was time for me to move on at my day job. During my time at Hart InterCivic/Manatron I've really stirred up the pot and effected a whole lot of positive change. However, at this time my work as a build/install guy is pretty much complete and it has become obvious to me that it's time for me to stake out my next challenge and attack it.
I spent a couple weeks meeting with potential employers, listening to their needs and considering the needs of my family. As a result of this I've decided to leave Manatron on March 14th and joining Multimedia Games.
Of course this just made me even more busy! One of these days I'm actually going to kick back and relax when I become a short timer instead of burning the candle on both ends trying to close every project known to man king. Ever since Manatron purchased my group last year, we've had an office relocation and a domain migration project on our schedule that kept getting delayed. Naturally these projects come to a boil the moment that I give notice. So for the last week I've been burning the hours planning and executing the transition of all of our systems to it's new environment. If that wasn't enough I've been going through countless `knowledge transfer` sessions where people try to learn everything I know.
Which BTW, how does one cover the subject `Windows Installer/InstallShield In-Depth` in 90 minutes?
Subscribe to:
Posts (Atom)