Click here to Skip to main content
15,867,594 members
Please Sign up or sign in to vote.
1.00/5 (2 votes)
See more:
If I want to design my application(written in C#) for Standard Users, which folder I shall install my application on customers' machines?

If I install my application on Program Files folder, it needs admin permission....
Posted
Comments
PIEBALDconsult 6-Jul-15 17:48pm    
yes, you are right. I forgot this default option.
Afzaal Ahmad Zeeshan 6-Jul-15 18:31pm    
Great solution; also a good UX. Some users might not have a lot of space in C drive so they can install the software in D or E or F where so ever.

I wonder if I can install an application on my flash drive or removable disks also, can I?
Southmountain 11-Jan-20 20:43pm    
sorry to PIEBALDconsult: I accidentally changed your message. I thought I was replying your update.....

Southmountain wrote:

it is both. I want to understand the process from installation to starting my application by users on Windows Vista. For XP we do not have issue because user has administrative privilege.
All right, both. The installation chooses to request "Run as Administrator" or not, this is one of the options. If it does not request UAC by its initiative, but during the process there is a failure due to permission exception (which may or may not happen when the user voluntary starts it as administrator), this installation is wrong.

With the application itself, there are two options. You can have the application which can be started with elevation of privilege or without it. Such application may or may not throw permission exception, depending on what the user actually does. Normally, you catch all the exceptions on top of stack frame of each thread (or in UI main event cycle). So, you can handle it and advise the user to "Run As Administrator". It's impossible to elevate the permission in already started process. Therefore, I, for example, developed a special technique when the second instance of the application is started by the first on "As Administrator", passing the request to accomplish the action which needs special permissions. Naturally, UAC request will be issued. It is impossible to avoid unless the user switched UAC at all, which I don't recommend and don't even want to discuss.

The second approach is to request UAC from the very beginning. This is done by adding an application manifest to the application and specify it. This is fully explained in this MSDN article: http://msdn.microsoft.com/en-us/library/bb756929.aspx[^].

—SA
 
Share this answer
 
Comments
Southmountain 10-Jul-15 19:33pm    
Thank you very much for your time and sharing.
Sergey Alexandrovich Kryukov 10-Jul-15 19:42pm    
You are very welcome.
Good luck, call again.
—SA
Please see my comment to "Solution 1" for major consideration on installation.

You should not decide if your application goes to certain directory. The installers "know" that, because they negotiate with OS about standard path for installed application. If Windows is targeted to x86, this is "Program files". If Windows is targeted to one of the 64-bit architectures (x86-64, IE-64), this is "Program Files" if the application is targeted to the same architecture, and "Program Files (x86)" otherwise (when the application is targeted to x86 and will be executed by Windows via WoW64.

Please see:
https://en.wikipedia.org/wiki/Instruction_set[^],
https://en.wikipedia.org/wiki/X86[^],
https://en.wikipedia.org/wiki/X86-64[^],
https://en.wikipedia.org/wiki/Itanium[^],
https://en.wikipedia.org/wiki/WoW64[^].

Many application mess up this rule; and it does not present any problems despite the fact that it is, from the aesthetic point of view, it totally disgusting.

I would add another rule: all .NET products targeted to "Any CPU" (the main and the best, purest .NET model) should also go to "Program files", but some installers put them in "Program Files (x86)", and this is not only disgusting but also sounds ridiculous, as such application will run as 64 bit. But the problem here is: Windows Installer is not yet taught to respect "Any CPU", so I guess the only solution is to create two or three installers: x-86 for x-86 OS and separate installers for x86-64 (same as AMD64, even on Inter) and IE-64 (same as Itanium). In other respects, these installers can be identical.

Note that you never ever should hard-code "Program Files" or "Program Files (x86)". These names are taken from OS by the Windows Installer.

Again, any decent installer should provide the option to specify custom directory, and any decent application should be able to work with it. Failure to do so is unacceptable.

Finally, you should think of providing "portable" product, always or optionally; best installation is no installation. Of course, it is not always possible.

—SA
 
Share this answer
 
Comments
Southmountain 6-Jul-15 20:28pm    
what do you mean for 'portable " product? do you mean that I can put all files in a zipped file, so that users just need to unzip them and put it into any folder?

Based on solution 1 description, it is a must that installation process needs administrative privilege?
Sergey Alexandrovich Kryukov 6-Jul-15 21:15pm    
Yes, basically, just unzip or copy. "Portable", in modern jargon and trend, it nothing special: installation which does not require installation, just copy all files to the destination directory and run it. When it is possible (no modification to OS data is required, such as a "file type" registration, hole in a firewall, etc.), it should be considered preferable kind of deployment, at least is should be one of the options suggested for the user. Why having installer if no installation is really required.

Administrative privileges is typical for installation. It depends on what the installation does. Remember the difference: not only account privileges, but also UAC-based privilege elevation in Vista (Vista has practically failed as OS, it wasn't a "real" OS, was never really complete) and up (as in "Run as Administrator"). Of course, the minimal reason for that is writing to "Program Files*". Your installation is really required to be able to write to "Program Files*", but it is also required that you don't require the user to choose this directory. The user finally decides.

What are you using for installation toolkit? I strongly recommend WiX. Strictly speaking, this is probably the only really legitimate toolkit, in contrast to "Setup" project type used to be bundled with Visual Studio (paradoxically). WiX is fully compliant with MSBuild project type standard (it has the layer which makes it compatible) and has very good VS integration. WiX is the first official Microsoft open-source product. It solves all the problems we discussed on this page.

Well you accept my answer formally now? Your follow-up questions will be welcome.

—SA
Southmountain 7-Jul-15 21:41pm    
Thanks for sharing. It really helps me to clearly understand the details.
I use Advanced Installer.

Based on your explanation, installer needs to run to install my program into Program Files folder, so it needs Administrative Priviledge for this, but for my application, for first time use, it needs adminstrative previledge because my application will write some items into registry, from then it does not need adminstrative previledge because it writes data to local user settings.

So what is the requirement/setting for my application? only one time escalation is needed, does it still need to be UAC aware?
I have two questions her
Sergey Alexandrovich Kryukov 7-Jul-15 23:41pm    
Are you talking about installation or the application? What's the purpose of writing to Registry, what is it?
Is is supposed to be compatible with Windows before Vista (no UAC)?
—SA
Southmountain 8-Jul-15 21:42pm    
it is both. I want to understand the process from installation to starting my application by users on Windows Vista. For XP we do not have issue because user has administrative privilege.

I have a licensing logic that needs to write an item into registry.
Also I try to figure out why so many papers on codeproject on Vista UAC too:

such as this one: http://www.codeproject.com/Articles/19165/Vista-UAC-The-Definitive-Guide
Anytime you perform an installation you will need some sort of permissions, typically administrative, and this is especially true if your installer or EXE isn't signed. My recommendation is to to follow the pattern Microsoft has laid out and use the Program Files folder. A user with the rights to install will have access here. If you try to install anywhere else, you will most likely run into even bigger permission issues, like the root drive or the system folder. Locations like the Desktop or the user's Downloads folder opens you up to the user easily deleting your application.
 
Share this answer
 
Comments
Southmountain 6-Jul-15 18:05pm    
what will happen if my application is signed with my certificate?
Thanks for the reply!
Sergey Alexandrovich Kryukov 6-Jul-15 18:33pm    
Nothing unless you want to put it in GAC or want to check up digital signature (to confirm that the application is authentic).
Please see my comment below for further detail and Solution 2. The topic of signing is irrelevant here, but of course you should understand it. Read on the following topics:
GAC, digital signature, digital certificate (not the same thing!), public-key cryptography.
—SA
Sergey Alexandrovich Kryukov 6-Jul-15 18:32pm    
No, it's certainly not "anytime". With too many applications, it's not an issue at all. Besides, all applications should work correctly if a user installs it in one's own directory. It might be not a good practice, but is really up to the user. For a qualified user, there is nothing wrong if the application is installed in any custom directory, but if some application behaves poorly if installed in not a standard way, it's a crime; the authors of such applications should return back the money paid for such a sloppy product.

Also, what you say about signing it totally irrelevant to the "problem". Signing is very important feature, but it affect installations only when GAC is used.

Finally, the developer should first think if the installation is needed at all. Many products with installation really should not use installation. Fortunately, people started to realize it (and Microsoft started to support it). Many products these days come in two deployment options: installation and "portable". "Portable" should be the option #1 to consider. Installation should be used only in special cases, when, say, "file types" are registered, and when clean up by uninstallation could be somewhat tricky. For example, development tools usually needs installations, and some utilities don't.

—SA
Southmountain 6-Jul-15 20:22pm    
got it. thank you for your time.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900