Installing Winforms for all users

Unless there is some express need to run it on the local machine and if you have RDS (formerly known as terminal services) available it might be better to serve it up as a remote application.

-saige-

You will have to build a .msi of the complete app for it to be installed for all users this  defeats the purpose of the auto updates and things ClickOnce provides. Building a MSI to drop an icon on a machine is simple and just must be installed once. 

How are you doing the install now?

If you are using a GPO or Intune/MEM, then you need to target the device, not the user. When you target the device, the install runs in LocalSystem context and installs for all users.

I'm not using click once.  I'm using an installer project that drops all needed file structure, dependencies, etc onto the pc.  

Not familiar with gpo or intune as a local admin is usually the person installing for all users.

Targeting the system vs the user sounds interesting.  Can I still use all the my.user.settings for separate users under this method?  There are many tweaks I allow users to make that save from session to session using user scoped settings.

Thanks for thoughts

So the question becomes why do you need to target users specifically?  Is it because of ui specific reasons (e.g ui loading data [multiple monitors]) or some other reason?

-saige-

Yes, its an intensive use app.  It connections with 3 different remote dbs, exchanges chat services with another server, grabs maps from cloud servers, builds rdl reports, and more.  I havent tried running only on a server.  It may have as many as 50 people simultaneously working.

Is this something like putting only a link in the user desktop and it hits the program. On the server?   I do have a small simple app that I deploy in that fashion and it runs fine with multiple usrs.  

If you're talking about traditional RDS logging into another box,, then no, not an option. 

Does the software install under %Username%\AppData\*\Software\*.exe ?

"Software" being the name or vendor's name?

What information, on a per-user basis, is required by the software on first-run? Or is it created on first-run?

If you require something on first-run, well, then you have conflicting desires. You have to choose.

I put it in c:/programdata/companyname/appname

Start menu entry
Optional start with windows
Also an icon shortcut on desktop

I use username/appdata/app name. For settings unique to the individual user.


no information needs to be supplied by the user on first install..  There is a bit of information required per user on first run to customize their chat experience if desired.  Otherwise the app grabs their login name from windows.

So how do I make an msi (or whatever) to give to a network admin so they can deploy via GPO?    Do I just get them the same msi I make now?  I dont do the installs I just make the programs. 

Just throwing a guess that if the directory doesn't exist for the user's app settings when the application starts up, it's going to launch the installer to create the directory.

A couple of different ways you can solve this is by using the registry for the application settings or a standard location with default configuration settings.  I'm assuming that you are placing the shortcuts (start menu and desktop) in the public start menu and public desktop locations, respectively.

-saige-

Your MSI should only write to public locations and those owned by TrustedInstaller. If that's already the case, it should already be ready.

I always had permission problems using registry so I abandoned that for appdata.  I also use programdata for log files and other universal settings.  The shortcuts are in the public folders.  

Thats an interesting question on whether the folder structures are created on first run for each user.   I bet they are.  Ill have to explore that

Where do I find whats considered a public location?   I've experienced every client environment to be different.  So far, no probs with %programfiles and %appdata. An admin has to install because its a full trust all user application but then a user can run since it only writes to user appdata.  Writing to system data errors out on some machines when a user is logged on.  

This begs another related question...where do I store connection strings or other sensitive data in a "public place"?  Will the user be able to write to it ?

programdata is a public location. so is C:\USERS\PUBLIC  access to programdata requires elevation. 

So in summary, other than a group policy script (which isn't my area of knowledge) there's nothing I can do with the installer project to negate the need to hit the msi for each user.

1) its probably the userappdata folder and initial settings additions that cause the msi to be needed.

2) maybe try a server based app, running it via shortcut link

With regards to registry settings, in general, the user is *generally* provided unfettered access to the HKEY_CURRENT_USER\Software branch of the registry, meaning you can save your settings in something like; HKEY_CURRENT_USER\Software\YourCompany\YourApplication

With that in mind, you can create a class which will load the values from the branch specified and use default values in place of undefined values (understanding that if the user choses to change these values they can also be saved back to the registry location).

HTH,

-saige-

>So in summary, other than a group policy script (which isn't my area of knowledge) there's nothing I can do with the installer project to negate the need to hit the msi for each user. 

It really depends on how the installation is built. If it's built following recommended standards, then the installation launched by the user determines if the user is local administrator or not, and installs for all users or for this user respectively. If it's installed from the group policy, then it's installed per-user or per-machine depending on whether it's published under Machine Configuration or User Configuration. Also, it's possible to install the product per-machine (i.e. for all users) by a non-admin user, but the installation will ask for admin's credentials.

I just re-read this from your original question:

When a different user of that PC logs on and runs the program it needs to reach the installer .MSI which is stored on a network drive.  This is scary and inconvenient for users.  

If I understand correctly, the new user has so called advertised shortcut on their desktop. When they launch it, the system notices that this program is not yet installed for this user, so it automatically reaches out to the installation source, and finishes the installation. This is completely legitimate process, fully automated, so I wonder why this is "scary and inconvenient". Pretty much the same automatic process can be launched if the installation decides that it needs to self-repair itself. I would try a little training of the users and explained to them that just the opposite, it's a good sign that the system is watching the integrity of the product and keeps it in perfect shape.

Vadim, I've seen other programs be able to do the install so I was wondering how to do it.  I wouldn't have contact with end users to train them since I'm only a contractor.   I only  usually work with IT staff so I wanted to make it as easy for them as possible.   I've heard back that users dislike the mini installing window that comes up with first use and that a few companies had permission issues since their users are very locked down.  IT had to authorize every user individually. 1 client refused to allow the msi to be available so we parted ways.

Think about a warehouse where each workstation will have 20 profiles only occasionally used...or maybe never by any given employee.  Of course there's a variety of ways to build that network but I have no control over that.
Otherwise I agree 100% with you

Most likely, the installation can be modified to avoid this effect. But it's hard to tell more, without knowing exactly what's going on - so far all our considerations are based on the guesswork. If you really want to look further, enable installer logging on the machine where it happens,and upload the log; even better, also the installation itself.
But specifying this installation in the group policy as assigned under "machine configuration" almost certainly will resolve this problem for all users on the machine. The installation will be then installed automatically and fully for all users during the next machine start. Try it out, and let us know if the problem is still not solved (which is possible if the installation does not follow the standards).

when the developer creates the installer. one of the options is for machine or per user or allow choice. 

But if the developer also has registry values under HKCU, and it's installed per-machine, that's probably when it will have to self-repair for every user on first run.

in a windows installer project 2019 one of the first steps is to specify the folder... the default property is %programfiles%