Doctor Deploys Blog

Many times people want to take advantage of the Wix v3 patch building features but didnt build their original product using Wix. for example, they may have used Install Shield, WiX v2 or one of the other tools out there. I ran into this when I needed to create a patch for a product we shipped from Visual Studio before the Visual Studio build moved to WiX v3.

 WiX v3 has a feature I added a while back to support this scenario. It allows you to point at an admin image of your msi based install package. This will be very familiar to some of you who have used patchwiz and pcp’s in the past. The difference here is that your patch authoring can be done using the WiX v3 Patch element and it follows the same workflow as patching a WiX v3 based msi after the first stage of creating the diffs.

Something I found really easy, and I could see this being used by smaller products who dont have a lot of infrastructure, is the ability to hand edit your admin image to product the patch. For example, I wanted to update a single file in my product:

1. I created an admin image
2. I made a copy of the admin image
3. I updated the loose file in my copy of the admin image

After running it through the series of command lines, I got a patch that updated the file. Pretty simple…

The command lines you need to run are all the same as the ones in my sample: Building a Patch using the new Patch Building System - Part 3. The only difference is that you need to pass the -ax command with a path to extract embedded binaries to instead of the -xi switch. This tells torch that the input is admin image instead of xml. Also, specify the path to the msi in the admin images instead of the wixpdb as the target and upgrade. Everything after that should follow the same process.

Let me know how it works!

Bonus feature: One of the most useful things in the WiX v3 patching system is the ability to filter whats in your patch using patch families to only ship your customers the updates they need. This allows you to grab changes per Fragment from your wix source. When patching from admin images, there is no source so you would think that the filtering isn’t suppoted. Not so! This was one of the more fun parts of this implementation. We “auto-fragment” the msi into what we consider to be the optimal chunks to give you the ability to filter if you choose to do so.

Original post by Petermarcu

Members of the Windows Installer team will be at both the TechEd Developers (June 3-6) and TechEd IT Professionals (June 10-13) conferences in sunny Orlando, Florida. For information about our Breakout and Interactive Theatre Sessions, please see my previous post. In addition to the scheduled sessions, we will be staffing the Technical Learning Center (TLC) for both conferences. Information on the TLC area for the Developers conference is available here and information on the TLC area for the IT Professionals conference is available here.  

Robert Flaming and Hemchander Sannidhanam will be manning the TLC area at the Developers conference. You will be able to find them at the Microsoft Product Demo Station area during the following times:

·         Robert Flaming – Windows Presentation Foundation

o   June 03 8:30 AM - 12:00 PM

o   June 03 11:45 AM - 2:45 PM

o   June 03 2:30 PM - 6:00 PM

o   June 04 8:15 AM - 11:45 AM

o   June 04 11:30 AM - 2:45 PM

o   June 04 2:30 PM - 6:00 PM

o   June 05 8:15 AM - 11:45 AM

·         Hemchander Sannidhanam - .NET Framework

o    June 03 8:30 AM - 12:00 PM

o    June 03 11:45 AM - 2:45 PM

o    June 04 8:15 AM - 11:45 AM

o    June 04 2:30 PM - 6:00 PM

o    June 06 11:30 AM - 2:45 PM

o    June 06 2:30 PM - 6:00 PM        

Tyler Robinson and Ken Wong will be manning the TLC area at the IT Professionals conference. You will be able to find them at the Microsoft Product Demo Station area during the following times:

·         Tyler Robinson – Vista Application Compatibility and Deployment

o   June 10 11:45 AM – 2:45 PM

o   June 11 11:45 AM – 2:45 PM

·         Ken Wong – Vista Application Compatibility and Deployment

o    June 10 11:45 AM - 2:45 PM

o    June 11 8:15 AM - 11:45 AM

o    June 11 2:30 PM - 6:00 PM

o    June 12 8:15 AM - 11:45 AM

o   June 12 11:30 AM - 2:45 PM

See you there!

[Author: Tyler Robinson]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

I should have made this post about 6 months ago as I was implementing the WixPdb feature in WiX but better late than never :).  The wixpdb was conceived as a solution for a limitation in the original patch building system. Originally, WiX v3 patching only supported creating transforms between two wixout files. This was flawed in that many things modify the output after the wixout is generated by light which weren’t being reflected in patches. I knew I needed the patch build system to be able to create transforms from something closer to the final output. Thats what the WixPdb is. It is all the data in the output right before creating the final msi. With that data, we can now create more accurate transforms to what people expect when diffing two products. I updated my blog with samples on how to build patches to show that I now recommend using the wixpdb instead of the wixout.

Down the road, I look forward to seeing what other features we can get out of the wixpdb. It provides a ton of information an allows you to potentially connect install time errors all the way back to the wix source and line number. Static analysis is another benefit. I updated smoke to be able to take the wixpdb so it will give you source and line number information for ICE errors. Statis analysis on the wixpdb itself may also be interesting because it contains more data than in the msi. It is the one place where the wix source data and the msi data connect. Let me know if you have any ideas of how to use the wixpdb in some cool ways…

Original post by Petermarcu

In an effort to cut down on spam to the WiX mailing lists, I will be flipping the switch to require that you subscribe to the list before being allowed to send mail to it in the next few days. The hope is that the requirement for spammers to respond to a confirmation email will raise the bar high enough that they’ll just leave us all alone. I also hope that this requirement doesn’t scare off anyone wanting to participate in the WiX community.

Switching the mailing list to require subscription was easily the most discussed topic on the wix-users mailing list in a long time. I really appreciated all of the feedback since it made it pretty clear which way to go. I just needed to go get a few logistical things pulled together such as updating the WiX web site with information about how to join the mailing lists (the updates should go out later today).

The last bit of feedback on the thread also gave me a good laugh tonight. I’ll leave you with that comment as well as the link to join the wix-users mailing list if you are interested:

> Come on, guys, all it takes is a single, emtpy e-mail to

> wix-users-request@lists.sourceforge.net?subject=subscribe

> and, I guess, a reply to a confirmation mail. Couldn’t be easier…

Planting a flag on the peak of Everest is easy as well - all you have to do is press the stick firmly into the snow.

 

Original post by Rob Mensching

After years of being blue, Soma announced that MSDN has finally gone red.

Everyone knows how much I absolutely love a red UI so this is a fantastic upgrade in my mind. Windows Vista went red earlier this year, MSDN goes red now and I expect Office will give up their blue to start sporting a nice red ribbon with their next service pack.

If anyone asks, just tell them that the WiX toolset was setting this “red” trend waaaay back when.  That’s right, we were the trend setters for all this 2008 “red is the new black” back in 1999.

 

PS: Yes, I am joking. <smile/>

Original post by Rob Mensching

Let me start by saying I’d love to get people’s feedback on the content of this post…

When Toyota designs a car they would never ignore the fact that no matter how great a car they build, they have to be able to get it to their customers. Additionally, they have to be able to get it to them at a reasonable cost. Imagine that Toyota decided that it would be cool to create a car that is 4 seats wide. Assume they ignored that the world’s infrastructure is built to handle cars two seats wide. Can you imagine what would happen if they did that? Cars wouldn’t fit on boats, on trucks, in garages, etc. In short, the cars would sit at the factory. Assuming the world wants the car people would scramble to create the infrastructure to get the cars to the users. In the end all of this would drive up the cost of shipping the cars and cause customers to pay more money to get it.

Software is no different

Unfortunately, software is often designed without considering its ship vehicle. What usually matters to developers is that it runs on their machine. It is designed and built until it works and is tested. Only then is deployment thought about. At that point, the application usually does tons of things that make software deployment a nightmare and costs way more that it would have if it were considered up front.

There’s a way out

The standard for deployment on Windows is the Windows Installer (MSI). Luckily, for the applications that think about deployment last, Windows Installer is very extensible. If you want to run a bunch of custom code during install, you can. Having to do this is usually a sign that your application was not designed to make your deployment simple. You have to build a bunch of infrastructure as a band-aid for something that could have likely been avoided. Whenever you see this, consider an upstream design change. This is more likely feasible if you aren’t just about to ship your product and you are scrambling to build an installer package.

Make it simple

Setup can be really simple. Everything on a machine boils down to very simple things: Files, registry keys, and shortcuts. Windows Installer happens to handle Files, registry keys, and shortcuts very well. It’s actually really easy to use if all you need to do to deploy your application is copy files, write registry keys, and add shortcuts to the system.

Its often not your application’s fault

IIS did not make it easy to copy files to a location to install a web site. .NET didn’t make it easy to GAC an assembly or NGEN it by copying it to a location. Both of these are things I like to call custom stores. Applications that expect other applications to extend them or use them as a platform need to be even more conscious of the deployment problems they cause. When platforms don’t consider what it will take to deploy on top of them they make every one of their customers building solutions has to modify their shipping container to handle their custom store. Although we cant get rid of the custom stores that have already shipped, we can hopefully prevent more and more custom stores from being produced. I think people building on top of platforms should push back more when their platforms create more and more custom stores.

Start development with deployment

When building your applications, think about deployment as you design your app. Think, “Can I put this on my customers machine by only copying files”? If it starts to get hard, don’t just write custom code to solve it. Think, “Could my application make itself easier to deploy?” Ideally, you could build your application to a folder and just run it without any configuration steps. You should create an empty installer package at the beginning of your project and build it up as you ad functionality to your product.

Application virtualization is on the horizon

If you make your application deployment completely declarative where no custom code has to run on your customers machine, your application will fit into the virtualized application world much better. It will also allow scenarios like drag and drop deployment, running from USB key.

Disclaimer

Many of the things I’ve said as far as guidance are optimistic. The world isn’t as clean as I wish it were. But in the end, I dont think we’ll ever be in a better situation unless people start thinking about the problems and stop making things worse for the Windows eco system by creating custom stores in platforms.

Original post by Petermarcu

As of a few weeks ago, the BinderExtension class in the wix extensibility model has taken on a new meaning. If you currently have a BinderExtension, you will need to rename it to BinderFileManager. Over the past year or so, numerous requests came in to give WixExtensions access to data and bind time to pull disperate data together or get access to data only available at bind time.

For example, if I have a custom table where I need to know the exports of all my native dll’s and I want this table to be populated dynamically by wix, I would need to have access to populate my table after files are resolved. With the new BinderExtension class, this is now possible.

Key Changes:

What used to be called BinderExtension was renamed to BinderFileManager. The BinderFileManager handles things specific to a files, mainly file resolution and comparison. Only one instance of a BinderFileManager can be present in the WixExtensions passed to the wix tools and is commonly used in an extension specific to a build environment.

It is now possible to have a BinderExtension defined in each WixExtension passed to the command line tools. This allows you to:

1. Link disperate data associated with compile time language extensions. It essentially enables extensions to make additional decisions that the WiX linker cant do for you because it doesnt natively support your language extension. Once the linker has pulled all the data together, it may be neccessary for you to read that data and populate additional tables.

2. Populate tables with bind time data such as information from files which are resolved during bind.

 In my series abut writing WixExtensions, I plan to show an example of this functionality. I plan to pick that series back up soon.

Original post by Petermarcu

Back in early 2003, I was learning C# by rewriting WiX v1, which was tens of thousands of lines of VBScript, to create WiX v2. At the same time, Jason Ginchereau was experimenting with C# to create a managed library to interface with the Windows Installer API. I didn’t know about Jason’s work at the time so we created a very limited interop layer in WiX to communicate with the Windows Installer APIs. Jason, on the other hand, worked until he had covered every aspect of managed code interop with the Windows Installer API plus support for reading/writing Cabinet and Zip files. He named the result the Deployment Tools Foundation (DTF):

Deployment Tools Foundation is a rich set of .NET class libraries and related resources that together bring the Windows deployment platform technologies into the .NET world. It is designed to greatly simplify deployment-related development tasks while still exposing the complete functionality of the underlying technology.

Over the last six months or so Jason and I have been working together more. You see, Jason is the dev lead on the Visual Studio team responsible for integrating the WiX toolset into the next release of Visual Studio. Among the various things Jason and I have been discussing is what to do with DTF.

The biggest hurdle was that there were not enough test cycles available to ship DTF as part of the next version of Visual Studio. Even though DTF was used by many teams inside Microsoft, all code that becomes part of a shipping product must have a certain level of verification by official test resources. Since there weren’t enough resources available to ship DTF as part of the product, Jason was looking for alternatives. Joining the WiX toolset community was an interesting option.

The next hurdle was managed code Custom Actions. As noted above, the Deployment Tools Foundation has full support for the Windows Installer API. That means it is possible to create all types of Custom Action (immediate, deferred, impersonated, rollback, commit, you name it) using managed code.

However, a year ago I posted the outcome of the managed code Custom Action discussion I had with Carolyn (MSI Dev Manager) and a couple Windows architects. To sum up that blog entry they had two issues. First, the technical issue was that managed code Custom Actions needed to be run in a separate process. Second, the Windows platform has a strategic goal to reduce the number of Custom Actions.

When I posted that blog entry, DTF suffered from both issues. A month or so after the blog entry, Jason had addressed the technical issue by implementing the necessary interprocess communication mechanisms to move the managed code Custom Actions into a separate process but still be able to communicate with the Windows Installer. He did a very nice job keeping the overhead very, very low (a simple named pipe) and as a result his solution is very robust.

That left the strategic concerns. I struggled with one for a long time. On one hand, I could understand why they don’t want to have a proliferation of Custom Actions. But, at the same time, I saw fewer and fewer native APIs being developed for fewer and fewer native code developers.

I think it was sometime over the week I took off for my birthday that I subconsciously decided what to do. The next blog entry I wrote was titled Obsolete skills where the subconscious decision finally bubbled to the surface. After that, I sat down with Jason and we discussed what it would take to integrate DTF into WiX.

Last night Jason finished the integration work and today you can find the Deployment Tools Foundation in the sdk directory of the latest Windows Installer XML toolset release.

Jason, thank you for all of your hard work and I look forward to watching DTF grow.

 

Original post by Rob Mensching