Why is the Installer is My Least Favorite Piece of the Microsoft Platform.
I worked on a project where we were contractually restricted to Microsoft products after years of using Java and Open Source tools. Microsoft tooling is kind of interesting because you get a integrated environment where the MS teams have taken on the burden of implementation. It's not a confused jungle of choices where some big pieces integration are left to you. The MS world moves at a pace driven by Microsoft itself, often faster than JCP driven Java. OSS and Java either barely move or go really fast but in a whole bunch of different directions all at once. Which is pretty, is much a matter of personal taste.
Microsoft and its tooling is installed and managed through GUI installers that bind the installed software/tool to the target machine. Its not like a directory is created and some stuff is registered. Files are copied different places and system libraries can be updated or overwritten. This installer and its implications has turned out to be the most annoying thing about the Microsoft environment. It makes it hard to create and "make available" customized tools across a team. In the Microsoft world this almost always involves software distribution through a centralized team or the work of creating a custom installer to do what you want.
Java requires that you install the JRE/JDK but every Java tool I've used is installed just by unpacking a jar file or by installation as a plugin to an ide. Tools can be distributed via any fileshare for instance checked into a Version Control System (VCS) or dropped onto a shared drive in its runable format. Developers or users then update their VCS workspace or select the shared drive and run the updated tools often without any configuration work. Force updating a new version of Eclipse to 100 users can be done by the dev team without "operations" support. The tool owner can in VCS and then tell everyone to "get latest". In the Microsoft world, this requires an installer, rollout plan and help from the software distribution team.
It may be a side benefit of the Java/Linux/OSS route is that you can run multiple versions of the same tool on the same machine worrying that int conflicts with a previous version or that a later installation will overwrite something. You can usually install different versions out of sequence to their original release dates. Microsoft Windows products often require that software products be installed in the order of their release dates because they sometimes overwrite or update systems components.
I worked on a Microsoft project where everyone had to have AppFabric, SQL Server and Visual Studio installed. All of these required an installer to get the software onto the developer machines. They also required custom configuration to get them to work together. I worked on a Java project with Coherence, H2 and Eclipse. All components were distributed, pre-configured, through VCS updates.
The de-installation process in the Microsoft world is even worse. You often find out that you have to install several, or many, packages to uninstall something. This gets very complex by the time you layer on the OS and feature patches. Abandoning a development VM followed by a re installation is sometimes the simpler way to upgrade a product. Recently I had 3 virtual and physical machines with two versions of Visual Studio and/or two versions of SQL server. The uninstall process for the earlier version of SQL server ended up being different on each machine. I tried to uninstall the older versions of SQL Server with up to 10 different un-installer packages. This turned out to be a confusing and error prone process. You just delete the directory in the Mac World or delete the tools from the file system for Java world and delete the .app directory on the mac.
Maybe it all goes back to the desktop productivity roots where everything is optimized for space and a user takes all actions through a GUI. The other tools and platforms seem to take a less intrusive approach that simplifies unattended distribution. I currently find find the Microsoft installer, its implications and its side effects the most annoying thing about this environment
Microsoft and its tooling is installed and managed through GUI installers that bind the installed software/tool to the target machine. Its not like a directory is created and some stuff is registered. Files are copied different places and system libraries can be updated or overwritten. This installer and its implications has turned out to be the most annoying thing about the Microsoft environment. It makes it hard to create and "make available" customized tools across a team. In the Microsoft world this almost always involves software distribution through a centralized team or the work of creating a custom installer to do what you want.
Java requires that you install the JRE/JDK but every Java tool I've used is installed just by unpacking a jar file or by installation as a plugin to an ide. Tools can be distributed via any fileshare for instance checked into a Version Control System (VCS) or dropped onto a shared drive in its runable format. Developers or users then update their VCS workspace or select the shared drive and run the updated tools often without any configuration work. Force updating a new version of Eclipse to 100 users can be done by the dev team without "operations" support. The tool owner can in VCS and then tell everyone to "get latest". In the Microsoft world, this requires an installer, rollout plan and help from the software distribution team.
It may be a side benefit of the Java/Linux/OSS route is that you can run multiple versions of the same tool on the same machine worrying that int conflicts with a previous version or that a later installation will overwrite something. You can usually install different versions out of sequence to their original release dates. Microsoft Windows products often require that software products be installed in the order of their release dates because they sometimes overwrite or update systems components.
I worked on a Microsoft project where everyone had to have AppFabric, SQL Server and Visual Studio installed. All of these required an installer to get the software onto the developer machines. They also required custom configuration to get them to work together. I worked on a Java project with Coherence, H2 and Eclipse. All components were distributed, pre-configured, through VCS updates.
The de-installation process in the Microsoft world is even worse. You often find out that you have to install several, or many, packages to uninstall something. This gets very complex by the time you layer on the OS and feature patches. Abandoning a development VM followed by a re installation is sometimes the simpler way to upgrade a product. Recently I had 3 virtual and physical machines with two versions of Visual Studio and/or two versions of SQL server. The uninstall process for the earlier version of SQL server ended up being different on each machine. I tried to uninstall the older versions of SQL Server with up to 10 different un-installer packages. This turned out to be a confusing and error prone process. You just delete the directory in the Mac World or delete the tools from the file system for Java world and delete the .app directory on the mac.
Maybe it all goes back to the desktop productivity roots where everything is optimized for space and a user takes all actions through a GUI. The other tools and platforms seem to take a less intrusive approach that simplifies unattended distribution. I currently find find the Microsoft installer, its implications and its side effects the most annoying thing about this environment
Comments
Post a Comment