Doctor Deploys Blog

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

In my original dissection of Google Chrome’s setup I noted that the Google Updater was left running after I uninstalled. After a pretty smooth installation experience, that partial uninstall left a bad impression on me. Well, it turns out that my observation was only half correct. A comment was left on my blog and a friend of mine at Google noted that the Updater is left behind but does remove itself a number of hours after the uninstall of Chrome.

I missed this fact because after uninstalling Chrome and noting that the Google Updater was still running I immediately went about removing it manually. After hearing that I just had to wait, I again installed then uninstalled Chrome and waited. About eight hours after my uinstall the Updater unregistered itself and shutdown. In the end, I was just left with some user data (good) and a couple directories in the LocalAppDataFolder\Google directory (less than ideal but no big deal).

So Google Chrome does get cleaned up and that makes me feel much better about the install (I’ve posted an update to my original blog post).

Now I’m just puzzling over the decision to not uninstall Google Updater right away. I can’t come up with a good reason for the Google developers to risk upsetting geeks (like me).  Geeks are the most likely to adopt the new browser in the first place. But geeks are the most likely to notice the “bad uninstall”.  And geeks are also the most likely to get upset by junk left over after uninstall.

Anyone out there want to random a guess why Google chose to have the Updater uninstall behave this way?

 

Original post by Rob Mensching

Last time I took apart the Google Chrome setup experience and came away disappointed that the Google Updater got left behind. This morning the Google Updater had another surprise. Well, it isn’t so much a surprise as it is a departure from the norm and I’m curious what you all think about it.

 

The background.

The story actually starts a few days ago when there was a discussion on some mailing lists about the easiest way to crash Google Chrome. All you had to do was type “:%” into the address bar and the whole thing would blow up. However, this morning someone noted that the crash no longer happened but was baffled since nothing had changed. It turned out that Google Chrome had been updated silently.

The details.

It turned out that ZDNet Australia had already run down the story that included a couple nice quotes from a Google representative:

Google knows best

Without a manual check, Chrome will update itself automatically, Google said. “Google Chrome will automatically checks for updates approximately every five hours. If an update is available, it will be downloaded and applied at the next browser restart,” Google said.

Google believes it’s best if Chrome applies security updates not only without a description of what’s changing, but also without an opportunity for users to decide whether to accept the patch.

“Users do not get a notification when they are updated … When there are security fixes, it’s crucial that we update our users as quickly as possible in order to keep them safe. Thus, it’s important for us to not require user intervention,” the company said in a statement.

My reflection.

Clearly fixing any security issues in the browser is paramount. But does the need for distributing security updates and bug fixes trump the user control over the software? The Google Chrome EULA grants Google the right to do just that. In fact, the update clause has its own top level number.  Number 12:

12. Software updates

12.1 The Software which you use may automatically download and install updates from time to time from Google. These updates are designed to improve, enhance and further develop the Services and may take the form of bug fixes, enhanced functions, new software modules and completely new versions. You agree to receive such updates (and permit Google to deliver these to you) as part of your use of the Services.

But just because Google says, in an electronic document that most users never read, that they may push new software to your computer does that mean they should do so without informing the user?

I can tell you that no Microsoft legal representative I’ve talked with has ever allowed such a clause in a Microsoft product. By default, the user must always be notified that an update is available and/or required. The user must also accept the update before it can be applied. If the user chooses not to accept a required update then the product may choose not start but a silent update is never an option.

But I’ve argued (unsuccessfully) that updates should be automatic and silent by default. Of course, users should be provided the option to opt-out and require notification/approval of updates. And, of course, group policy should be respected so that businesses can manage their desktops.

Personally, I think that Google has gone a bit too far requiring silent and automatic updates. I think their current outlook will slow their adoption in enterprises (if that was even a goal for Google Chrome). Time will tell if anyone really complains about the updates. My prediction is there won’t be unless Google silently updates to a bad/broken behavior.

My question.

So, what do you think about this automatic and silent update behavior?

 

Original post by Rob Mensching

I thought the next installation package I would evaluate from the inside out would be the Windows Live Writer Tech Preview. However, before I got around to that, lots of noise was made about Google Chrome’s release so I thought I’d pile on and dig in. As usual, I found a few interesting things.

Initiating the download.

First, the installation experience starts by downloading a pretty small bootstrap (474 KB) executable. A bootstrap executable like this is basically required for any distribution over the Internet so the only thing interesting here is that they did not to ship the product embedded in the initial bootstrap executable. Instead, the bootstrap executable contains the Google Updater and the applications to have the Google Updater download then install. Don’t forget about the Updater, we’ll come back to it at the end.

One important thing to note here is that the bootstrapper is specifically marked for no elevation (<requestedExecutionLevel level=”asInvoker” />). That’s good because it’d be less than ideal to be downloading from the Internet from an elevated process. What’s more interesting though is that there is never an elevation prompt. This means that the Google Updater, Google Chrome and Google Gears are per-user installations. I am always interested in applications that choose to go per-user since there is always a reason behind the choice (usually to avoid a UAC prompt on Vista).  ClickThrough installations are per-user and more spectacularly Live Mesh is per-user. I’ll cover the details of per-user installations, why they are interesting and how they differ from per-machine installs in a future blog post.

Before going forward, going back to the very beginning, the EULA dialog is very tricky. I don’t know if Google did this on purpose but notice the checkbox in the location where most installs say you must check to “Accept”. It actually is the option to opt-in to sending all your usage data to Google. If a user wasn’t paying close attention and was just clicking to get to the download they might opt-in to accidentally. Sneaky, if intentional.

Also, I kept looking for some place that explained that we were going to be getting the Google Updater and Google Gears with Google Chrome. Haven’t found it.

Actually downloading and installing Google Chrome.

Next, the Google Updater installs itself and starts downloading Google Chrome and Google Gears. After downloading, Google Updater launches the installs for Google Chrome and Google Gears. The progress bar behavior is interesting to watch during this process. During the first initialization the progress bar enters “endless loop” mode (or “confused Cylon mode” for you BSG fans). When the download starts the progress bar fills the bar normally. Then the progress bar goes back to “endless loop” mode during the installation. That means there is no real progress during install itself.

At this point, Google Updater will have installed itself in the LocalAppDataFolder under Google\Update and pointed a HKCU\Software\Microsoft\Windows\CurrentVersion\Run key to start it on every boot. Google Chrome was installed by some opaque (presumably custom) engine using a 7-Zip package as for its data. Google Gears, however, was installed by an MSI. The MSI was created with the WiX toolset (older build) and tailored for the Chrome install location and marked to not show up in Add/Remove Programs itself. That means the Chrome uninstall is responsible for kicking off the package uninstall.  The only real problem here is that the original source MSI is deleted after the installation is complete. That means should the Windows Installer require the original source for any reason, it’ll be impossible for typical users to satisfy the source prompt. I am curious why Google chose to use MSI for installing Google Gears but used some other installation mechanism to setup the rest of Google Chrome.

While all of this custom stuff provides a very hands off installation experience for consumers, it doesn’t play well with serious enterprise deployments. However, the fact that this is a per-user install means that individuals can probably get Google Chrome installed on their desktops without the Google Gears MSI install since even administrators may block it (the Windows Installer respects global Group Policy settings that can prevent all installations). Of course, it’s possible (I’d dare say likely) that Google wouldn’t rate enterprise deployment high on their list of priorities for Google Chrome.

First boot experience.

When the install is complete, Google Chrome launches and goes into a “first boot” experience to do let the user configure their settings and migrate any existing bookmarks. This is exactly the right thing to do. I see so many applications make the mistake of trying to do this type of work in setup its refreshing to see someone get it right. I’ll go into more details about settings management in the future.

Google Chrome Uninstall FAIL.

To dissect the Google Chrome setup, I had to uninstall several times. On the first uninstall, I saw that Google Chrome’s “User Data” directory was left behind. This is fine and, in many cases, desirable. If there is data in there that the user may want later, leaving the data around is the best choice. An option to clean up all the data during uninstall is also a good idea especially since this is a per-user app and it can correctly clean up the appropriate user data. No big deal but that did lead me to the beginning of the badness for Google Chrome’s uninstall.

First, the prompt to uninstall is a bit goofy when it asks, “Are you sure you want to uninstall Google Chrome? (Was it something we said?)”. Maybe the rhetorical question fits in with the comic book introduction and the cutesy Mac-like fail screens but it certainly doesn’t feel very professional. Clicking OK causes the prompt to disappear but there is no indication that Google Chrome is being uninstalled until a short bit later a web browser window pops up navigated to a Google page asking why I uninstalled. The experience is disconnected even though the uninstall is pretty quick. The extra browser launch is also a bit annoying. I wonder what type of feedback they’ll get there.

However, this next issue is huge. Uninstalling Google Chrome does not uninstall the Google Updater. That means that Google Updater will start up on every login (because it’s still in the Run key) even though you don’t have any Google stuff to update. Unless you manually run “%LOCALAPPDATA%\Google\Update\GoogleUpdate.exe –uninstall” before deleting everything in the Google directory, you’ll be left with COM goo on the machine.  The real problem is that there is no visible indication that the Google Updater is still on you machine.

Maybe this uninstall problem is just an oversight on Google’s part but there is so much registration around the Google Updater that it is surprising it could be forgotten. It is especially important to clean it up because it wasn’t really clear that you were getting the Google Updater when you just wanted the Google Chrome.

Conclusion

The initial installation experience didn’t really impress me with its vague progress bars but overlooking the uninstall of the Google Updater really ruined my opinion of the overall Google Chrome setup experience. The clean per-user installation and appropriately timed migration experience doesn’t outweigh the uninstall problem. If the uninstall just left some dormant files in a directory that’d be one thing but the Google Updater is left active on my machine after I uninstalled everything.

 

Original post by Rob Mensching

Recently Robert Scoble posted a blog entry about how Windows engineers feel Win7 is being managed differently than previous Windows releases. As I read through the list, I immediately thought, “Hey, that’s just like Office.” It also reminded me of an analogy I came up with when I first joined Microsoft.

Before I continue, I should note that I consider myself to heavily influenced by the “Office-way of software engineering”. When discussing software development philosophies with other Microsoft employees I often say that “I grew up in Office”. I believe that foundation in large scale software engineering tempered by my exposure to the “Open Source-way of software development” has been invaluable to my development as a software engineer. There was many a day when I was in Windows where I longed for the “Office-way”. However, as a disclaimer, do know that I was young when I was in Office and it was a long time ago so nostalgia may have seeped into some of my memories. Also, as always, these are my feelings and views alone… others may see things very differently.

Now, back to my story.

When first at Microsoft I was trying to describe to my Mom the differences between Office and Windows. Not that one was suite of productivity applications and the other was an operating system. Instead, I was trying to explain the cultural differences across the two organizations. It amazed me how incredibly different the culture of two parts of the same company could be. I described it to my Mom back then as the “Office family” and the “Windows division”.

In Office, everyone felt like a part of the extended family. I always worked on a “Core” team so the build team and UI team felt like siblings while the “Word” and “Excel” teams felt like cousins and the “Powerpoint” team felt like distant cousins (since they were down in Silicon Valley). Development managers and directors felt like “heads of the household” and the “head of the family” (Steven Sinofsky, during my tenure) all provided direction, discipline and support at their various levels. You were expected to work out issues at your level and not “go crying to daddy”. In fact, escalating usually had negative consequences for all of the people involved. Overall, it felt like everyone was working together to ship a very complex and large product on time.

In Windows, it felt like there were all of these small kingdoms vying for attention and resources. Everyone felt very compartmentalized on their particular feature. The development manager and directors were necessary to exert your requirements on other team. Escalation was the norm and sometimes you’d have to go through 6 layers to get the leverage desired. Also, rigorous process seemed to be valued over developer productivity. I think the term “death march” was invented in Windows. Overall, it felt like constant battle to test the mettle of teams and the features to be delivered into the operating system.

Now, to be fair to the culture that developed in Windows, there is a serious amount of pressure to be all things to all people. Not only do you have to build features that capture the imagination of the future but you have to make sure everything that worked in the past continues to work today.  And the OS is always on. If you want to see someone take the responsibility seriously check out Raymond Chen’s blog. He’s one of the true Microsoft heroes.

Anyway, after I heard Sinofsky would be moving from Office to Windows I hoped that many of the changes Scoble described would occur. When I later heard that Jon Devaan was moving in to lead another part of Windows, I expected a culture change was inevitable. Why? Because the guy that led Office before Sinofsky was Devaan. I believe culture comes from the top and the Windows division got a huge injection of “family values” when Devaan and Sinofsky moved in.

Now I just hope the (IMHO) improved culture creates an incredible product.

 

PS: The Live Mesh team has a different feel than any other team I’ve been on. I expect that is due to Ray Ozzie’s influence (remember, culture from the top). Maybe I’ll write more about my feelings on the Live Mesh culture when I understand it better.

 

Original post by Rob Mensching