We Keep Coding

Wix Install to C:/Users/User/AppData

I'm trying to find a way to install a program to the AppData folder for each user on a computer. We have a computer that a group remotes into and each uses the program on that computer. Currently the application is installed normally in the program files. The reason we need individual installations is that we've updated the application to use AppLife Updater, and if someone runs the program while someone else is also running it, and it needs an update, the update will fail. So we'd like to have each user have their own installation that won't interfere with other users installations when updating.
I've found that you can install to LocalAppDataFolder instead of ProgramFilesFolder, but when you do that, you get several ICE errors (Specifically, ICE38 and ICE64). I found a web article that showed a version of a Wix installer that installs to the LocalAppDataFolder, but it also has ICE38 and ICE64 errors.
AppData Wix Installer code/article
My question is, has anyone made a Wix installer before that installs to the AppData folder that does not have these issues? Is there documentation on how to do this, other than the cited article? I have read the Rob Mensching blog article
How to create an uninstall shortcut (and pass all the ICE validation).
ICE64 documentation
ICE38 documentation

Installed using ClickOnce but want to uninstall so I can use another installer

I have been using ClickOnce to install and update mysoftware for the past few years. I decided to switch installers to NSIS.
It isn't feasible for individual users of the software to uninstall the software and then re-install(with the NSIS installer).
I thought about adding some code in my NSIS script to delete the registry key for the application before installing the software but Microsoft highly recommends to use the Windows Installer service for uninstalls.
My questions are 1.What is the danger of installing without uninstalling the previous version? and 2.is there a way(using NSIS or through another means) to programatically uninstall the previously installed version before installing the current version?

The typical consequence of not removing the per-user click once installation(s) is that the user might be confused by two versions of the program. For example this could be two different office addins active.
I did some searching on the silent uninstall question and I'm not sure if ClickOnce ever supported this or not. I did find some open source projects that reported to being able to do this. Implementing them into an ActiveSetup style pattern to get it to run in each user context would seem to handle getting rid of the old versions.

How to find all the installed programs including 64 bit apps

I know this question was already there. But either the answer is for 32bit(as I used) or suggesting "Access/Modify Registry". I failed in the first option. Second option is not good for me. I myself don't know about the testing machine and registry entries vary for 32 bit and 64 bit. I am trying to list out all the apps installed and uninstall the specified one(ruby). I used wmi class with the query
ManagementObjectSearcher managementObjectSearcher = new ManagementObjectSearcher("SELECT * FROM Win32_Product");
But, it does not returns all the applications. The "ruby" is missing but it shown in the Control Panel\Programs\Programs and Features as below. Can anybody say how to access all the installed programs irrespective of their bit(32/64)?
Note: I am using VS2010, .Net 4.0, C#, Windows 7 Enterprise Edition.

There is not really any such thing as "All the installed programs".
A program could be:
A simple executable file on the desktop.
A collection of executable and DLL files which co-operate together. Usually these will be in Program Files.
A DLL registered as an add-in or shell extension
something else
So "A Program" is not a single thing which can be conclusively identified.
Installation could be:
Installed with Windows Installer. You can get a list of these using the Installer API.
Installed with another setup program which does't use Windows Installer, but just places the files where it wants them. They usually supply an uninstaller of their own. THese are often recorded in the Registry for the Add/Remove programs tool.
Just unzipped into a folder. These may not be recorded anywhere in the registry, they are just files in folders. Maybe they put an "uninstall" shortcut on the desktop or in the start menu, or maybe not.
So "installation" is not a simple thing which can be conclusively identified.

Visual Studio 2010 .net 3.5 and lower messed up on windows 7

In the course of some troubleshooting last week I uninstalled .net 3.5 thinking I could re-install, and did so (tried atleast), but now i can't seem to build anything targeted towards 3.5, I try to reinstall 3.5 but it keeps telling me i have to do it in windows features, so I've tried checking and un-checking that. Any help would be great.
Edit: I should probably add that I used revo uninstaller and completely blew away 3.5.

You have broken the .NET Framework. Congrats been there this is no fun. If you have Googled you surely have found
http://blogs.msdn.com/b/astebner/archive/2007/03/26/how-to-repair-the-net-framework-2-0-and-3-0-on-windows-vista.aspx
There it is mentioned that the .Net Framework on Vista+ is part of the OS you you cannot reinstall it as usual. The mentioned trick to call
sfc.exe /scannow
does not help since it does only repair missing files in locations under MSI and Trusted Installer control.
After searching a lot on my file system I did finally find my assemblies in an unexpected place. They are all installed a second time into C:\Windows\WinSxS... which is normally only used for unmanaged side by side dlls like the C-Runtimes or any other dll. I do not know how they did install it but normal MSI installations which do install into the GAC do not install the managed assemblies a second time into the WinSxS folder.
On a second thought it sounds reasonable since MSI and the installers do only care about files in the WinSxS system32 and other specially protected folders. The GAC is not protected in this way which means that the usual repair mechanisms do not work.
My way out of this mess was to use gacutil to simply install everything into the GAC again which is intallable from the WinSxS assemblies. With the following commands I had success:
1. C:\Windows\winsxs>for /D %i in (*_System.*) do for %j in (%i\*.dll)
do echo %~fj >> %TEMP%\assemblies.txt
2. C:\Windows\winsxs>for /D %i in (*_microsoft.*) do for %j in (%i\*.dll) do echo %~fj >> %TEMP%\assemblies.txt
3. for /F %i in (%TEMP%\assemblies.txt) do gacutil /i %i
I have nowhere found any explanation why the .NET assemblies are installed a second time in the WinSxS folder. MSI does treat managed and unmanaged assemblies nearly the same way but with the normal installers I do not get this behaviour. I do know that MS uses for Windows Components a technology similar to MSI but the underlying engine is quite different.
When you get OS patches they look like regular msi files but they aren´t. If you try to repackage them you will find out that the installation does no longer work. It would be very interesting to get more infos on this dark subject.

I ended up getting my machine re-imaged, as I think when I uninstalled .net 3.5 with revo uninstaller and completely blew away the reg and existing, I put my laptop in a very hard to repair state. I've given up and gone the re-image route, as according this article, this seems to be the best way to fix the registry.
http://blogs.msdn.com/b/astebner/archive/2007/03/26/how-to-repair-the-net-framework-2-0-and-3-0-on-windows-vista.aspx

Find MSI install package for pre-installed application?

Here's what I'm looking to do:
I'd like to perform an application install on a remote machine; as a part of that process, before I install the new version, I want to check that machine's registry for a pre-existing version of the same application.
If that machine has an existing instance of the application already installed, I want to find the MSI used to install it, so I can backup the MSI and perform a 'rollback' if necessary. From what I understand, Windows creates a copy of these MSIs and places them in some temp folder with a random name somewhere so that it can use it for uninstalls.
How might I find this location?
(Also, suggestions on how to check the registry values cross-network would be appreciated.)

As far as I understand, you don't have to find the exact MSI package. In order to uninstall a product, it is enough to know its product code and run msiexec /x {PRODUCT-CODE-GUID-HERE}. And product codes can be found under Uninstall registry key (typically, SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall).