Just in case you were thinking I’d forgotten my promise to bring out some of the WTF? moments in the 2010 upgrade, here’s one for you:
If you’re installing stand-alone seats, but not creating a deployment, Support path customization will not be available to you during the installer process. For those CMs that still run around doing the installation, this means you’ll need to launch the app as each user, customizing as you go, instead of creating defaults for all the users on the machine. You could alternately create a reg file and push that out to users to configure themselves with a little help.
Yeah, I know, pretty trivial, but whenever I see functionality removed from the application, I get irked. Now, on with the cool stuff!
I learned to stay away from messing with those install paths anyway. The issue I have is if I modify them and point them towards a network share that the user has read/write access to, and then at some point uninstall the application, it’ll remove resource files (i.e. Fonts, etc.). That’s not good for all the other user’s that still rely on the same common support locations. Your REG solution is good (insert standard Microsoft warning disclaimer here). I prefer to add a switch in the Desktop icon for my profile (ex. “C:\Program Files\AutoCAD Civil 3D 2008\acad.exe” /p “C:\Dwgs\Civil3D2008.arg”). Then, copy my custom ARG before first launch. It also helps if I need to restore a user’s setting back to my initial deployment state.
Actually, Civil 3D at least got a bit more clever this year, including an option on many thing to include “Shared” paths. These paths so designated are NOT cleaned out during an uninstall. In either case, I’m playing with our deployment docs, so we’ll see what comes of it!
James – glad to hear that its a little better with the shared paths. Todd – I’ve been there done that…