.Net Framework 3.5 Killed My Box

This is a non-Lisp related Public Service Message:

The boxes some of my users are running are pretty mediocre– running XP with really old hard drives that just chug along….

Installing .Net Framework 2.0 Service Pack 1 and .Net Framework 3.5 and then trying to reboot, I find that the box is completely hosed. Plugging in the hardrive to another box… the computer no longer even recognizes it as NTFS!

After putting the backup image back onto it and adding some other software, rebooting several times, everything seems fine. But putting 2.0 SP1 and 3.5 on it again hoses it all over again. I don’t know if this is an isolated case or not– I don’t know what will happen if I try to deploy to other old boxes. I’d already deployed to several other machines just fine… but maybe not to any this old.

Maybe I missed some fine print somewhere, but this is not what I expect when doing what I’d otherwise expect to be a trivial installation.

I will follow this post up with additional details if I find anything out. I may be converting my desktop application to a web app if this happens again….

Advertisements

One Response to “.Net Framework 3.5 Killed My Box”

  1. Mark Miller Says:

    Well I tried looking up the info. on MSDN, and found a download for the full package here, and they say that the package includes .Net Framework 2.0 SP 1 and .Net Framework 3.0 SP 1, which I assume means the full 2.0 and 3.0 packages upgraded to the most recent releases. I haven’t tried installing this myself, but I assume it automatically installs the prior packages in the process, so you don’t have to do it yourself.

    The first link it gives you is a “bootstrapper”, which downloads the necessary components from Microsoft as it installs it. This way if you already have some of the necessary components installed it just skips them, and you don’t download as much. There’s another link farther down in the page that allows you to download the full installation package.

    I looked through the readme and it does say that if you have a prior beta of .Net installed you need to uninstall it first. This has always been the case with Microsoft betas. If you try to install the final release over a beta it can damage your system. In the past sometimes it’s been more complicated to uninstall a beta than just running the uninstaller. What I’ve seen suggested is that people run betas in images in Virtual PC rather than their main system. That way you can just throw away the image without worrying about system configuration.

    Have you tried installing the package on a clean Windows install (just Windows, no other software installed) to see if you get the same results?

    Your post here intrigued me, because I’ve never heard of .Net hosing a system like this before. The last time I saw something like this was years ago when I was doing MFC programming (C++), and the software required some IE components to be installed first. If they weren’t already on the system, installing the software made the system unbootable, because it screwed up COM pretty bad. It turned out the installer lacked a check to see if IE was installed first. I insisted they add it.

    It was through that experience that I realized that the installer is like a project unto itself, in addition to the software project. If it doesn’t work right, the rest of the effort doesn’t mean anything as far as the customer is concerned.

    Anyway, I thought .Net was going to FIX problems like this, rather than cause them…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: