I've recently been picking up various utilities to integrate with Team Foundation Server when I downloaded TfsDeployerSetup.msi.
I dropped the package in my COTS_ARCHIVE area and went to my integration machine to install the package. After executing the double click pattern the MSI initialization dialog appeared and then it exited. The product was installed. Oh my, good thing this is my test machine and it's a simple package!
Now unfortunatly this is not the first time I've seen setup developers create a UI-less installer. In fact, I've seen it so many times that I didn't really need to examine the MSI to know what toolset it was written in. Sure enough, there it was:
Windows Installer XML v3.0.1821.0 (candle/light)
Now I know WiX is all about not letting setup developers author `Bad` MSI's and I suppose if you only go by one persons definition of bad, they have succeeded. I'm going to go old school for a moment... before Windows Installer there was Bullet Proof Installs. One of the patterns that I've ALWAYS believed in was the User Interview and Confirmation pattern ( aka the Next, Next, Install, Finished pattern).
Every, I repeat EVERY stand alone installer should have a UI Sequence that greets the user, gets all needed information, checks for failure conditions and prompts the user one final point of no return before making any changes to the machine.
But it seems that because WiX is too primitive of a toolset to possibly assist the developer in authoring a decent UI experience then UI must simply not be important these days. The result is many converted WiX developers seem to think it's enough to throw together a few xml elements and build it. After all.... Setup is easy, right?
Now I'm sure TFSDeployer will probably be a really cool tool, but if your going to treat setup like a UI-less Xcopy, I'm not sure why you'd even bother with WiX/MSI. I personally don't think a properly behaving install just automatically installs it self without any confirmation simply by clicking the msi.
Christopher,
ReplyDeleteWhy do you have to go off and be so snarky? It's hard to respect someone that spreads this type of fear/uncertainty/doubt about tools you chose not to use.
For example, you know that there are several standard UI dialogs provided by the WiX toolset, some of them even follow the Interview/Confirmation pattern. Personally, for really simple installs , I prefer the "Ready/Go” pattern like the default one provided by the WiX Advanced UI.
Also, you've been doing install long enough to know that MSI provides a nice transacted change mechanism that an XCopy-type install won't provide. Why are you suggesting that simple installs shouldn't do the right thing and package up their bits in a nice clean MSI file?
IMHO, we should be encouraging everyone to do the right thing and help them improve their installation experience. There is certainly no need to belittle the developers trying to do the right thing.
I'm somewhat surprised by your first `snarky` comment because from my point of view you have been every bit as guilty when it comes to attacking InstallShield. On many occasions I have read you attack InstallShield, InstallShield Built Packages and InstallShield Users. You have also admitted to not being an IDE guy and that you have never actually used InstallShield. This is the pot calling the kettle black IMHO.
ReplyDeleteYou mention the `Ready/Go` pattern. MSI does support this pattern, it's called /QB. This should be the user’s decision though and the full experience should always be the default.
Finally you talk about transacted installs. What is the point of a transacted install if you don't provide a FilesInUse dialog or a SetupProgress/Cancel dialog? If one of those files had happened to be locked, the `Ready/Go` pattern would have simply rebooted my machine because there were no UI elements present to get my permission. Or perhaps the reboot would have been suppressed or perhaps the install would have rolled back. The point is, without a UI sequence the user has no idea as to whether the install succeeded or failed. Transacted installs are great, but they aren't complete without UI elements to mark beginning, progress, completion, success, failure, and action items. UI elements are also needed to publish messages to indicate the user’s preference to abort and rollback the transaction. Simply double clicking an MSI shouldn't give a package complete authority to do anything the package wants without getting the users consent. If this is how an MSI behaves, then I think it has less value then a ZIP file containing the bits of a product.
I agree with you. I am trying to encourage everyone to do the right thing but instead of trying to convince one setup developer at a time that a Full UI experience is vital to a properly behaving install, I’m trying to convince you because you’ve created a toolset that allows developers to build a package without defining this vital experience. If you or someone else at Microsoft saw a flaw in `ISHNMET`, you wouldn’t hesitate in taking them to task on it.
Regarding defining `the right thing`, you and I clearly disagree and I think this is because your opinions are too heavily influenced by the `eat your own dog food` pattern. From what I can see, Microsoft has mostly gone the external UI handler route and in that context a WiX package like this one would work just fine. Unfortunately IMHO this leads to the attitude of thinking that the story is complete since it works for Microsoft.
The next problem comes when a new or part time setup developer comes by, reads a little bit about WiX and throws together a package like this one. It (mostly) passes validation and WiXCop so they think they are done. But the developer hasn't really done the right thing (again the definition is varied) and because WiX doesn't think it's important, the toolset doesn't do anything to alert the user of the importance of a UI sequence, or give him any kind of useful tool to author the UI sequence.
You may think I'm being hard on WiX, but keep this in mind.... I push these issues because I'd really like to use WiX one day in real production installs. While WiX might meet your use cases, they don't meet mine yet. Unfortunately every time I've mentioned this to any Microsoftie associated to WiX the answer seems to be along the lines of `we are Microsoft and it works for us`. I'm sorry but I've been doing this a long time at a lot of different companies both big and small, and I can tell you there is more to the world out there in terms of requirements and servicing stories then the way things are practiced at Microsoft.
Christopher,
ReplyDeleteI do not attack InstallShield. There are a couple instances where I have derided InstallShield on wix-users but those comments were focused on InstallScript (which was a horrible, horrible thing for the Windows Installer IMHO). I also don't criticize InstallShield users (if you find a place where I have, I will go back and publicly apologize to them). I really do believe you have me confused with someone else.
That said, I do have issues with the price tags on the packaging tools (pretty much all of them seem really high) which is where I can get snarky. However, that's just me being quirky since the market is apparently supporting that price (or someone would have released something for less and made a lot of money, right?).
Ultimately though I believe that you and I just have a few very different outlooks on how the installation packaging tools should approach the problem. I believe the tools should be built in layers so that developers can get to the level of detail they find appropriate. Next we build layers on top to make it easier to do common tasks (like providing install UI or adding many files to the project). At some layer, GUIs/IDEs are often desirable. As I’ve stated many times (and you like to remind me), I have very little interest in going into the rich GUI thing. Fortunately for users that want GUIs there are companies out there building businesses around IDEs on top the WiX toolset.
So, I expect you and I will often just have to agree to disagree. <grin/>
Frankly I've never understood your objection to the cost of setup development tools. Is there a price point where you would not object?
ReplyDeleteI ask because when you published your WiXAware commentary I believe the cost of the toolset was somewhere around $300. I don't want to get into bill rates, but at $300 if takes almost no time at all to make a return on the investment.
I'm particularly confused because I would think an attitude of `don't pay for setup tools` would come from a penny pinching pointy haired boss who doesn't understand the importance of setup. I certainly wouldn't expect .NET developers to code in notepad and compile with CSC.
FYI InstallShield doesn't `hide` you from MSI. It has a direct editor, nor does it force you to use an IDE, it exposes its project structure in binary (MSI database) and XML formats and provides an automation interface if that’s the way you prefer to develop.
FWIW, you and I probably agree 95% or more. I'd love to use WiX and I do like the approach it's taking in many areas.
Unfortunately there are use cases where you either haven’t had the time and resources to complete or your personal viewpoint has deemed not valid. In the case of the former, I understand. In the case of the latter, I can only say that you are driving developers away who would otherwise like to leverage your toolset.
I recently completed a project for a customer who specifically asked for WiX. I actually looked at doing the work in WiXAware on top of WiX 2.0 but there were several servicing stories that were crucial to his project that InstallShield supported out of the box that WiX would have required rolling my own. I explained the LOE to the customer of doing both and he chose InstallShield. Hopefully one day I'll be able to choose WiX/WiXAware and crank the project out as quickly as I could in InstallShield.
So keep in mind, I do mostly agree with you, and I am watching your progress because I do hope to one day use WiX. The only reason I have not contributed to the project yet is 1) I'm not the best C# coder in the world.... I can do it, but I'm really a setup developer and 2) I've not felt that suggestions that I've made in the past were taken seriously.
Here's my two cents on the importance of the right UI in the installation project.
ReplyDeleteI am an installer developer working for a small company who sells its software to big OEM names (like HP, LG, Philips, Samsung, Sony, you get the picture). Those guys are very picky when it comes to corporate identity. They require us to style our applications not only with their logos, but also with their color schemes, and exact locations of certain elements in the UI. Many of them (not all, to be fair) require the Installer UI to be styled same as the application. Like it or nor but we are glad to oblige, cause this is where our income comes from.
So, as much as we 'love' InstallShield's pricing policies, we HAVE to stick with it, until there will be tools on the market comparable with IS's flexibility and feature set.
Side note: we do use IS's automation interface in production to modify installer 'on-the-fly' for each manufacturer.