Welcome to MSDN Blogs Sign in | Join | Help

Design your Application to Fit Your Shipping Container

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. Your custom code inevitably wont behave properly in some scenarios causing your entire deployment to become fragile. 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 aren't 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.

Published Thursday, May 22, 2008 9:42 PM by Petermarcu

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Doctor Deploys Blog :: Design your Application to Fit Your Shipping Container

# re: Design your Application to Fit Your Shipping Container

Totally agree. I know it is an optimistic view but if we can encourage people to think this way may be things will change and I include Microsoft developers and product managers in this. Rob Mensching posted something similar a while back and used the term SDD (setup driven design), I think a better term would be DDD (deployment driven design) - plus the fact that someone pointed out to me that SDD sounds like a sexually transmitted disease!

Friday, May 23, 2008 5:23 PM by Neil Sleightholm

# re: Design your Application to Fit Your Shipping Container

DDD sounds good to me. I've thought about that as well. I would call it Deployment Driven Development to make it mesh with TDD (Test Driven Development). It would also make sense to plug it right in to TDD where your unit tests run only on an application that is deployed and not on the binaries in the bin folder.

Sunday, May 25, 2008 2:22 PM by Petermarcu

# re: Design your Application to Fit Your Shipping Container

It's a good goal, but one (sadly) most developers don't really care about.  Developers adopt platforms because it makes their development problem easier.   Frankly the deployment problem usually isn't their problem.

And let's say it was their problem.   Do you think that annoyance would be enough for them to drop IIS/ASP.NET as a dependency?   Also let's say they do `push back` to the IIS/ASP.NET team.  Do you think that will really accomplish anything?  Maybe three releases down the line but then your stuck supporting legacy environments because the target machine is on some downlevel version.

BTW one big one in my book is XML.  How come their is no XML Poke/Peek support in MSI like there is for Registry and INI ( limited peek ).

Software just isn't as rigid as the Toyota example.   Developers like to do RAD with the latest and greatest reusuable components and limited plumbing and they expect deployment people to magically solve the integration problems that these dependencies and custom store create.

Eitherway, it's a great goal, but one that I don't worry about because when someone comes to me for help they don't want to hear me preach about DDD, they want me to just solve their problems so that they can ship.

Is that the best way to approach the problem?  Of course not.  But by the time they call me, that's what needs to be done.

Tuesday, May 27, 2008 12:37 PM by Christopher Painter

# re: Design your Application to Fit Your Shipping Container

"But by the time they call me, that's what needs to be done." but isn't that the point, we need to encourage this to be discussed up front. I know it is a hard struggle but by trying may be it will start to get through. I even think it should happen before developers get involved, the product design should be thinking about deployment.

Friday, May 30, 2008 3:43 PM by Neil Sleightholm

# re: Design your Application to Fit Your Shipping Container

Chris, you made some good points. I agree that deployment is always thought of last and people like us are brought in when its too late to change the product. While I agree that the downlevel problem will always exist and you cant solve a problem for everyone at first, ignoring the problem never fixes it. We need to push deployment engineering down into the platforms such that it becomes easy to create robust deployments. Every small step in the right direction helps and laying a good foundation for the future will get us to a point where downlevel has a good deployment story.

Friday, May 30, 2008 4:09 PM by Petermarcu

# re: Design your Application to Fit Your Shipping Container

I agree with you Neil and Peter, I'm just giving an `in the trenches` perspective.

In my experience, when you have the hard conversation with a customer on how to make their application fit inside the box, you can expect 1/3 of them to leave.  Now my side work only accounts for about 10% of my revenue so I could afford to take this risk.  But if I was 100%  consulting,  would I really want to take such a risk of losing business?

Also reminds me of a C# BootCamp I took with a very well known and cocky MS MVP instructor.   He had a huge disdain for `IT` and `Systems`.   When I asked him about deployment strategies he just mentioned VDPROJ and hinted at Installer Class CA's saying only that he's never used them.  

If we can get the platform problems fixed and guys like that on board teaching the right way, that would go a long way to fixing the fundemental problems.

BTW, I like virtualization ( except for the licensing royalty models that are popping up ) but I wonder,  how can we virtualize  ASP.NET/IIS apps?

Wednesday, June 04, 2008 3:40 PM by Christopher Painter

# re: Design your Application to Fit Your Shipping Container

Ah, and in comes App Virtualization. I dont want to change the subject of this post but I should start another post about App Virt.

Wednesday, June 04, 2008 3:55 PM by Petermarcu

# re: Design your Application to Fit Your Shipping Container

Hehehe, change away!

I was in Chicago a year ago meeting with InstallShield and one of their people gave a presentation on AppVirt to a roomful of ISV types.   They asked for questions and my reaction was something along the lines of:

"If we all write and package properly behaving applications per logo guidelines, why would we as ISV's need this?  I can understand Corp Repackager types seeing this as less risk, but will we really expect to see demand from our customers for this format?"

In a sense, at worst, AppVirt seems to me like a big collective admission of failure at making our cars fit on the truck.  At best, it seems like a way of solving our integration problems without all of the complexity of setup ( but trading for other complexities no doubt. )

Wednesday, June 04, 2008 5:19 PM by Christopher Painter

# re: Design your Application to Fit Your Shipping Container

I guess its too late now :) I agree with what you said to InstallShield. AppVirt up until now is all about the repackagers. In order to get it to work without producing an initial setup to repackage, you need a declarative install that will work on all your customers machines regardless of their machine state. If you get to the point where your deployment is declarative, Windows Installer does a fine job of laying files and reg keys down on a machine. You kind of brought the conversation full circle. Maybe application virtualization is the buzz term that people want to say their app can do. In order to play well, they have to consider it as part of thier initial design such that deployment is declarative. It drives the deployment discussion upstream such that they design their app to fit their shipping container. In this case the shipping container is [Put your virtualization solution here].

Wednesday, June 04, 2008 5:32 PM by Petermarcu

# re: Design your Application to Fit Your Shipping Container

At the risk of rambling incoherently... :-)

A couple of thoughts entered my mind.  One was of a show I watched called  `Carrier at War: The Uss Enterprise`.   A navy pilot made a really cool comment ( sorry I don't have the transcript ) something to the effect:

`Anyone can make bombs, what we are really, and I mean really, good at is delivering them.`

Think about it, in weapons systems you don't tell the bomb maker, `sorry, that won't fit on the truck`,  you let the bomb maker roll with it and then go design a new cutting edge delivery system to get that ordinace delivered exactly where and win ( with pinpoint accuracy ) that it's needed.

Anyone see where I'm going with this? :-)

So while I enjoy the effectiveness of MSI, the declarative model just isn't there.  If you look back at Aaron Stebners post from 2004 entitled `custom actions that should be standard actions`  not one of the twenty-one bullet points have been implemented in MSI.

So the truck and application analogy is good, except not all vendors ship sedans.   BTW, does anyone here happen to like Doctor Who or should I just skip the dimensionally transcendental metaphore?

Tuesday, June 10, 2008 1:24 PM by Christopher Painter

# re: Design your Application to Fit Your Shipping Container

I agree with the sentiment. It seems common for developers to (almost arbitrarily) leave something aside under the heading "oh, the install will do that" whether it's appropriate or not. By the time people start building the install they don't want to go back and reconsider because, after all, they're finished with all that. A list of these things would be too long, but it includes writing registry entries to all the user profiles on the system, being sloppy with file versions, wanting uninstall shortcuts in the Start Programs menu, wanting to disable MSI repair, blocking the install for transient reasons (removeable software like service packs, removeable hardware), services that don't stay shut down and cause reboots during updates (and describing it as an install problem). The MSI framework really is a framework, and the better you fit into it the more reliable your installs will be.

Thursday, July 31, 2008 5:05 PM by Phil Wilson

# re: Design your Application to Fit Your Shipping Container

While I agree with your principle, I see WiX as going too far in the opposite direction.

I currently build an installer for an open source product that I don't control the source of.

I've put in a lot of work to make sure that I COULD build the entire installer declaratively.

But now I'm stuck in the position that I can't use Wix, because Wix expects me to have installer fragments integrated into the source version.

So while application developers can be attracted to the idea that custom stores are so important that the installer has to support them, WiX seems to be attracted to the idea that declarative installer build files are so important that automated installer generation becomes close to impossible...

Wednesday, October 08, 2008 2:10 AM by Adam Kennedy

# re: Design your Application to Fit Your Shipping Container

Christopher Painter makes a very compelling point. I've worked in this field for 12 years, and I've seen things become more and more complicated as things move along.

The installation is arguably an equally important part of the process - What do customers see first? The product or the installation thereof? It's the installation. If that goes smoothly, and the uninstallation is just as smooth, it already gives a good impression.

Install developers (setup/deployment engineers/developers - pick your favourite job title) are often brought in in the middle of the development process when functional specifications have been written up and require change control for amendments, where things are simply assumed (as pointed out by other commenters - "oh the installer will do that" - really? That's news to me) and the process falls apart because no-one bothered to speak to those who know deployment best.

That said, my pet peeves are things like having to write code to create users and shares, and modify XML (not just read it), and the setup engine could have provided that. Why didn't it?

It is irrelevant which tool you use (Wix, Wise, InstallShield, Orca - All irrelevant) because all of them have try to make sense of the more and more complex requirements foisted on those using them. Perhaps it is a return to simplicity, perhaps it's up to the biggest vendors to lead the way (*ahem* Microsoft *ahem*).

Wednesday, October 08, 2008 12:28 PM by Stefan Paetow

# re: Design your Application to Fit Your Shipping Container

The basic premise of this post seems to be the lack of developer awareness during the design and/or development process of the need to reduce the cost of deployment.

Minimising installation complexity makes perfect common sense and something that is not a new requirement, rather one that existed since the early days of Windows. Whilst the concept sounds easy enough, putting it into practice is far from plain sailing. If all that were required of modern complex applications were to copy files, create registry data and the odd shortcut here and there, application deployment would a piece of cake. Unfortunately software has developed beyond the point of no return, requiring infinitely more complex systems than ever before.

Sure there are some aspects of installation that could be simplified, for example reduced cross application dependency and the increased use of side-by-side private assemblies, all with aim of producing, to a degree, an isolated application. Will any of this happen? Ha!

Wednesday, October 08, 2008 12:29 PM by Tim Owers

Leave a Comment

(required) 
required 
(required) 
 
Page view tracker