One cool side effect of the fact that so many people at Microsoft use RSS Bandit is that sometimes I get to have some of the folks who invented the technology it is built on helping me track down issues. For example, many of our users have complained about issue mentioned in the following post entitled Problems running from non-administrator account.

There's a slight problem if you run RSS Bandit from an account that isn't member of the Administrators security group.

When you run RSS Bandit (at least the first time after installing), it writes to a file called "rssbandit feed installer.InstallState" in "%ProgramFiles%\RssBandit". If you run as administrator that isn't a problem, but non-administrator accounts won't have write access to anything under %ProgramFiles%, which will prevent RSS Bandit from starting.

A workaround is to add write permission for "everyone" for that specific file.

It turns out that someone actually filed a bug against the Windows Installer team because they had problems installing RSS Bandit on their computer. Not only did the developer assigned the bug track me down to tell me what I was doing wrong in our installer but  Rob Mensching has also promised to swing by my office next week to give me some tips on writing installers.

Below is a description of what I was doing wrong from Carolyn Napier of the Windows Installer team.

If the file you’re manipulating for the feed information is in the ALLUSERS profile, then you will need to be an admin to access it. The current type specification for the custom action is 1025, which means the custom actions runs with the same privileges as the user that invoked the installation.

You can designate a custom action to run elevated (meaning at a higher privilege level) by adjusting its type. Visual Studio Installer doesn’t expose this, but you can use Orca, the MSI Table Editor, included in the Windows Installer SDK to tweak the type. (Other full-feature authoring tools make this available, like Wix, InstallShield, Wise, etc.).

Instead of 1025, make it 3073. Then your custom action will run with elevated privileges.

I installed Orca, the MSI Table Editor, and found the field she was talking about. It looks like this issue will finally fixed in the next version of RSS Bandit. Torsten has suggested that I use a full-featured installer tool instead of what ships with Visual Studio. I suspect this may be the straw that breaks the camel's back and gets me to start exploring Wix. I'll see what Rob advises next week.

I hope this post helps any other people who've had similar problems with installer projects built using Visual Studio.NET 2003.


Saturday, February 4, 2006 8:04:43 PM (GMT Standard Time, UTC+00:00)
You might try using NSIS ( It's free, easy to use (I used it once to crate an installer for my software), quite powerful and creates installers that I never seen fail (based on installing quite a few programs that used nsis; this contrasts to e.g. InstallShield that I've seen fail or take ungodly amounts of time to finish installation).
Saturday, February 4, 2006 10:29:41 PM (GMT Standard Time, UTC+00:00)
At first I was a little intimidated by all the Wix stuff (mostly the sheer size of the XML file that goes into a typical installer) but the best way to get your feet wet is to just take your current installer, decompile it using the provided decompiler and mess around with that.
Sunday, February 5, 2006 4:50:46 AM (GMT Standard Time, UTC+00:00)
It will be nice to see this fixed...I run w/o Administrator rights, using RUNAS and MakeMeAdmin
Sunday, February 5, 2006 8:50:20 AM (GMT Standard Time, UTC+00:00)
That is great. I'm glad it got tracked down. I have to say that understanding MSI is hard (at least for me - but I try to spend very little time on it). Especially confusing to me are the per-user install actions that run.

Jeroen is right. An easy place to start is get Rob to show you how to decompile the installer into a huge XML file. Get him to help you seperate the GUI portions out into seperate XML files (they are, by far, the largest parts of the XML file) and you'll be left just with the actions that actually install your files. You can then edit that one action and alter the field in the text. You'll never have to do it by hand again.

The down side to all this is that when you add new files that have to be installed you'll have to do it explicitly. MSVC automatically keeps track of those, which is great. Using Virtual PC really comes in handy here -- get a fresh version of XP installed and copy the installer in, double click and make sure you can browse a news group and some blogs. That will make sure all the required files came in as part of the distribution.

If I did this sort of thign for a living, I'd take time out to write something that would generate common file dependencies for WiX and integrate it into MSVC2005. But hand art is good for now for my (small) projects.
Sunday, February 5, 2006 10:36:48 AM (GMT Standard Time, UTC+00:00)
Isn't the whole point that non-admin users shouldn't be installing software or making changes within the Program Files directory and its children to begin with?

By using what seems to be an undocumented feature to allow your installer to perform certain actions at a higher privelege than that if the user who's trying to install the software, you're defeating the point of having a iser-level permissons system in the first place.

Sunday, February 5, 2006 10:37:24 AM (GMT Standard Time, UTC+00:00)
iser = user
Sunday, February 5, 2006 10:38:28 AM (GMT Standard Time, UTC+00:00)
than that if the user = than that of the user

[Yeah, I need to spell check before pressing the button.]
Sunday, February 5, 2006 6:41:34 PM (GMT Standard Time, UTC+00:00)
The administrator still needs to install the program. The question is if the installation process has a step that occurs after the first time the application is run, then it should do so with the rights of the person who installed the program (i.e. the admin).
Comments are closed.