Targeting the AppData/Local folder
I was recently forced into a downgrade from VS2010 to VS2012 so that I could target .NET 4.5. So far I haven't found a single thing I think is better in this version. The most annoying result of the transition is that Microsoft removed support for the Visual Studio Deployment Projects (.vdproj files). Luckily InstallShield provides a Limited Edition of their installer as an add-in. You can download it from within Visual Studio 2012 just like in VS2010.
InstallShield provides an import wizard for .vdproj files. The wizard is only available from the InstallShield LE menu. The import wizard didn't work correctly for my rather simple installer but it did save me some time. The problem occurred because I install ContentFiles under the AppData folder like I'm supposed to. The Wizard created a path for these files but it didn't work. I was further led astray by the predefined [AppDataFolder]. I foolishly assumed from its name that it was referring to the AppData folder. Silly of me I know. I never proved what folder it actually refers to but I suspect it is the Roaming folder under the AppData folder. How wonderfully misleading of them. I came to this conclusion because eventually I kept looking down the list of predefined folders and saw the [LocalAppDataFolder]. I didn't see a [RoamingAppDataFolder] so draw your own conclusions.
Creating my folder hierarchy under [LocalAppDataFolder] as shown at left was the first step to success. The second step was to set the ALLUSERS property on the General Information tab to 1 to indicate this installation was for all users of the machine.
Where's Waldo? – Allowing Upgrades without uninstalling
When I run my installer I want it to just upgrade the existing application. I don't want to force my users to uninstall the current version and then run the installer. Reading the help files and the web helped me to understand that for minor upgrades I should NOT change the GUIDs for Product Code or Upgrade Code. The help file did point out that I SHOULD change the Package Code GUID and it stressed how important it was to update the package GUID. OK great, armed with this information I thought I could easily achieve my goal. Or so I thought until I tried to find the Package Code GUID. I know it's not good form to complain about software you get for free, but sometimes I wish major manufacturers of widely distributed software would read at least an article or two on good design and the concept of discoverability. In particular purveyors of software tools seem to think we all enjoy playing Where's Waldo all the time.
Turns out the setting does indeed exist, but it's nowhere near where I would have expected it. In fact, in the limited edition you can't change it, it is automatically generated anew each time. This is a fact the help file might have found time to mention. A nod's not always as good as a wink.
It also made me wonder if it really would have been so difficult to just put the Package Code on the General tab under Product Code and Upgrade Code and just disable it? What purpose was served by burying it under The Prepare for Release->Releases->Builds=>Express->General submenu? Another victory for the antithesis of discoverability.