Hello all,

I have a Visual Studio 2008 setup and deployment project that installs a Windows service. During the Commit stage of the setup process, I utilizea "custom action" torun a configuration utility to allow the user to modify all sorts of information on the database connection, output folders, etc. This configuration utility is the primary output of a second project in this solution. This utility project does notcontain an installer class and the InstallerClassproperty for this project is set to false. Additionally, I have the installer copy this config utility exe to the application install folder so the user can come back later and change these settings, as the .config file for the project contains no sensitive info at install-time and the config utility encrypts the entire contents before saving it. So far so good, right...? (The code for this entire project can be found at this blog. In fact, it works great for customizing an installation routine, other than this one little bug I'm trying to fix here, so feel free to use all or part of the project code if you like it or find it helpful.)

The problem I'm having is in creating a shortcut in the user's start menu to point to the config utility exe. The client needs the installation to run for All Users, so I've specified that in the setup project. And, I've created the shortcut to the utility in the File System for the setup project. Now for the weird part... If you're logged inwith the useraccount used when installing, then the shortcut to the config utility works fine. However, if you log in as anyone else and click this shortcut (which does show up in everyone's start menu), it tries to install the service again, which inevitably fails since the service is already installed. So, it's not a case of something being fundamentally wrong with the shortcut since it works for the installing user profile. Further, it's not a problem with the config utility, as it runs fine under any user profileif you simply navigate to the exe and double-click, andsimilarly works fineif you manually create a shortcut.

I've looked at the properties for the shortcuts that are created by the installation routine, and they're weird. The target field is greyed-out and seems to be pointing at the wrong thing, and other information is either missing or not quite right. Nevertheless, it works for the user who originally ran the install.

I can imagine that this is hard to visualize (and probably hard to believe...) so I encourage anyone who is willing to try to help to check out the code and try the install if they want to. (Here is the link again.)

As always, any help is greatly appreciated!


regards,
Patrick

Hi Patrick Sch,

I am moving this thread from Base ".NET FrameworkSetup" forum to the "ClickOnce and Setup & Deployment Projects" forum, since the issue is related to deployment. There are more deployment experts in the "ClickOnce and Setup & Deployment Projects" forum.

Thanks

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

These shortcuts are normal. People don't notice them until they start poking around inside them, but (for example) every Office 2007 shortcut is like that. They're just special Windows Installer shortcuts.
What you've done is to create some data (a file by the looks of it) which is associated with a particular user (the installing user) and when another user logs on and uses your shortcut. then it installs the file for that user. Although this surprises people, it makes sense. Installing a file to a user-specific folder means that any user that logs on is supposed to have a copy of that file, so how does each user get one? So it tries to install it for that new user and you see a progress bar etc.

The other thing that's happening is that you're installing a service without a check that it's not already installed. I believe you would see the same kind of error if a user went to Add/Remove Programs and did a repair of your product, or right-clicked your MSI file and did a repair. So you need a condition of Not Installed on any custom action that you want to run only once (such as creating a service at install time). Alternatively, a really thorough implementation would contain code that checks the service is still installed properly, and if not it would install it again. Then if the service was deleted for some reason the user could do a Repair and it would be installed again. Most fully-featured installs (.NET Framework, Office, Visual Studio etc) have a Repair option to correct a broken installed product without uninstalling/reinstalling.

---

Phil Wilson

You know, I'd posted and responded in here a couple times, and Ithought the forum title didn't look quite right... :)

Thanks.

Hey Phil,

I appreciate the feedback. Although I'd love for this project to be as fully-featured as the .Net Framework, Office, etc. (no sarcasm intended...), the reality is that the client decides how fully-featured they want their product to be (read - how much they want to pay for it) and we give them what they ask for. This project is essentially a genericized version of a client project I implemented, and I haven't had the time to flesh it out any more than I have at this point. Nevertheless, thanks for the tip on adding the NotInstalled condition to the service - though it doesn't really address the problem I'm posting here, it's good info.

All that being said, I'm still not really sure why the shortcut is doing what it's doing, or, more importantly, how to fix it...

(I'll number my questions/points to make it easier to refer to them...)

1)The config utility project doesn't have an installer class and its InstallerClass property is set to false. My understanding on these matters is by no means comprehensive, but I thought this meant it wasn't really, technically being installed. My understanding is that the exe is just packaged into the msi file, run as a custom action, and copied to the application folder. The difference between this and actual installation may be small, or even nonexistent, but I guess I don't understand... Any additional info on this would be great.


2)Also, in regards to your point about the file being installed to the user-specific folder, I know that Vista has changed some aspects of system folders in terms of virtualization, etc., but the installation routine simply copies this config utility exe to the application folder under the Program Files folder. Is this user-specific in Vista? I'm pretty sure it's not user-specific in Server 2003, which is where we originally saw this problem exhibit the exact same behavior it's showing on Vista.


3)The shortcut to the config utility exe is the item that *is* being installed to a user-specific folder (their Start menu). However, that shortcut is simply pointing to the exe in the app folder under Program Files. So, definitely, each user is getting a copy of the shortcut, but there should only be one copy of the config utility exe (as far as I understand...). So, again, I don't understand why clicking the shortcut to the exe results in an attempt to reinstall the service. Furthermore, it's possible to manually create a shortcut to theconfig utility exe and put that manually-created shortcut in everyone'sStart menu, and this shortcut works fine and definitely does *not* try to install the service. So, as above, any additional info on this would be great.


4) One thing I tried to do to resolve this is to compile config utility exe outside of the solution, and just add it as a file to be copied during the installation process and run as a custom action at the commit stage. So, basically I just used the exe from the project separately, rather than using the "primary output..." from the project within the solution. Nevertheless, I got exactly the same results.



As I said a couple times, any additional explanation is greatly appreciated, and any specific suggestions on how to make it work would be even better... :) Maybe install these things to non-user-specific folders? Or, some way of telling the system not to try to reinstall every time?



thanks again,
Patrick

Any ideas or explanations out there? :)

thanks,
Patrick

I know this is months old, but I just went through a similar problem and solved it, so I thought I should post for anyone else who has a similar issue.