Doctor Deploys Blog

In .NET 4 we have quite a few deployment options available for redistribution. There are basically 2 pivots. The Client/Full profiles and 32bit/32+64bit packages.

Here are the four redistributable options and their corresponding sizes.

The Client Profile is targeted to contain the parts of the .NET Framework that are used by most client applications and gives people the option to carry a little less payload if they use less of the Framework.

The 32+64bit packages are designed to give the option of installing either profile on any target machine regardless of OS architecture. On the other hand, if someone is targeting a pure 32bit customer segment, the 32bit package gives the option of reduced size with reduced breath of deployment.

Original post by Peter Marcu

Over the past few years I have been asked more and more which version of .NET is included in the operating system. The following chart shows from .NET 2.0 onward, which version of .NET is included in both the Client and Server Windows operating systems.

Note that this diagram also shows which pieces are optional and whether or not they are on by default in that particular OS.

Original post by Petermarcu

There is an issue upgrading .NET 4.0 from Beta1 to Beta2 only on Vista RTM and SP1 as well as Windows Server 2008 SP1. This is due to a known issue that was fixed in Vista SP2, Win7, and Windows Server 2008 R2. It is not an issue on XP.

There is a document available here for how you avoid the problem and directions for how to recover if you are already in a bad state.

Original post by Petermarcu

Original post by Petermarcu

Do you own the deployment of your product and require the .NET Framework to be installed before you can install your application? If so, I want to hear from you.

I have a few general questions but any comments are welcome as long as they are constructive and actionable. My goal is to use this data to do what I can to improve the .NET Framework Redist experience in future versions.

Do you have a bootstrapper/chainer that preinstalls .NET? If so, which one (VSI, InstallShield, Wise, ClickOnce, custom)?
Do you block and point your user to the location to download and install .NET?
How large is your application?
How is your product deployed (Web download, CD, DVD, USB)?
What do you think about the size of the .NET package?
Do you know about the small package for .NET 3.5 that will download only what your user need? If so, do you use it?
What do you like about the .NET Framework Redist?
What do you dislike about the .NET Framework Redist?
Do you have any specific problems you can tell me about that you have had in deploying the .NET Framework?

Like I said, the info above will be helpful to me but I dont want to limit responses to these questions. We have a lot of data about the various issues people encounter while installing the .NET Framework but we dont have as much data about the ways people are deploying it and using it as part of their deployment. This is the type of info I’m looking to gather.

You can post as a comment or email me the info if you dont want it posted and seen by all.

Original post by Petermarcu

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

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