I have a setup project that installs my app to the typical program files directly.
My app periodically saves some temporary images to the apps installation folder. It seems on Vista, the permissions are not setup for write permissions. I can change it manually in windows explorer and it works, but I would rather have the setup project do that automatically.
How can I do this?
Is there a better/more normal place to put temp images that won't have permissions issues?
It is not Vista specific, this will happen with any kind of user account that doesn't have admin privileges. Your program just can't write to folders like c:\program files\blah. That UAC disables admin privileges has been publicized for a long time now. Use Environment.GetFolderPath() to get the path to an ApplicationData folder that you can write to.
See http://msdn.microsoft.com/en-us/library/bb756940.aspx for details on UAC issues for vista. These problems can also occur in other versions of windows when running applications from non-admin accounts. You should only write data to app data or temp directories and not program files.
Related
I have a visual studio setup project which installs my files to the program files folder and also writes some stuff into the registry and in addition some of the files are com visible (so there is more confusing stuff written to the registry).
Therefore I have to install it as an administrator - this works fine. And this administrator and every other administrator is able to start the program. But using a standard user I am not able to start the program.
All registry entries are there for the standard user - and it also has enough rights to access the file in the Program Files folder.
Could there be a problem with the ComVisibility? (Which is needed because it's actually a DLL working as a plugin for Solidworks)
You just need to look at the code in your app and see what it does that limited users can't do. Installing it for all users does not mean that it automatically allows limited users to violate security. Just find out what it's doing when it gets the security error (which is what you believe it is).
Limited users have never been able to write to restricted areas such as the ProgramFiles folder, CommonFiles folder, HKLM etc. That's a common reason for limited user issues with apps.
If I install my app to program files, will it always be able to create and write files within its install directory? It seems to work in a lot of different versions of windows, but are there situations where this wouldn't work?
Mainly I'm using this approach for logging. If this is not the correct approach, is there a better place to log?
Note: My installer requires Admin privileges to run and it grants Full Access to all users in the install directory.
Apps don't run as users, users run as users. If you install an app into Program Files, and let's assume you needed elevated permissions to do so, when your standard user then runs that app, that is the user that needs permissions.
App is installed with elevated permissions (user: Admin, for example)
All permissions on the AppName folder might well be "Admin:Full, Users:Read"
User runs app, so cannot change any files
At install-time, your installer will need to know which of it's own files need to be made writable to standard users, and set permissions accordingly. Of course, user-data should not be in Program Files anyway. That's what %appdata% and the user profile are for, usually.
If your app has a globalsettings.ini or whatever, that lives in "Program Files\YourApp", then while you have admin permissions (i.e. at install time) you need to grant write permission to all users to that globalsettings.ini file. Or Power Users. Or a group. Or whatever is correct for your app.
In summary, no, users do not have default write-access to ProgFiles, nor should they.
Yes, there are definitely situations where this won't work, such as when your app is running on Windows 7, or if your user account is a limited user.
We always put our log files in a temp directory or a special folder such as AppData.
I have an app modified to take into account the UAC in VISTA.
So, now, the .mdb (JET or Access file) is located in ProgramData\MyApp\
I realized that when my app reads the database for the first time it is doing it from that location... but when my app is writting to the database... the file is virtualized and goes to Users\MyUser\AppData\Local\VirtualStore\ProgramData\MyApp. From this moment on my app always go to the Virtualized location in disk.
My app is working, but if I continue this way, the database would be in a per-user basis, and we really need sharing the database with all the users in the PC.
I thought that writting under ProgramData folder would't trigger the virtualization mechanism.
What I'm missing?
I need to set the permissions for MyApp folder under ProgramData??
How can I do that on Install time?
Thanks people...
More info:
Developed with VS2003 VB.NET using the VS Setup Project.
Most likely you'll need to set write permissions for all users during installation.
To test, delete the virtualized folder, manually set the permissions on the ProgramData\MyApp folder and files and see if that works.
As for how to do that pragmatically during installation, that really depends on what technology you're using.
I have had trouble here as well, it seems vista once is decides to virtualize the file, the only way to stop it is to delete the virtual file.
The next time you use it, it will use the ProgramData folder.
I have a vb6 application. I am unable to carry out the following on a Windows Vista machine:
Register a .DLL from the Users directory
Start another .EXE
Write to a file in the Users directory.
How can I overcome these issues?
This is by design. Software is supposed to require admin rights for installation (including update/upgrades). You got away with it in XP because so many people ran as administrator. If you're registering a dll after installation, you're doing something wrong.
You should be able to do this without issue, but only with the same rights as the user that the current app is running under. What is this exe trying to do, and would a standard user normally have those permissions?
What specific folder in the user's directory? Again: a user should have write access to most of the their own profile, but not necessarily as much outside of that as you think.
You have access to write to the c:\users\ directory. Going to another users directory is a bit of a security problem that you're not going to work around.
As far as registering an assembly from a users directory... There is a directory under c:\users\\AppData\Local\assembly which you should have access to for temporary assemblies
Starting another exe is trivial... As long as it's installed in the normal \program files.. path.
It really sounds like maybe you need to reevaluate how your application works.
Some suggestions:
Move to Reg-Free COM where it can handle things (i.e. not for ActiveX EXEs, DCOM).
We'd need more information. This should be no problem unless there are permissions issues.
Users are not supposed to be creating files outside of their own profiles, CommonAppData, and application-defined locations (often on non-system drives). More information is required to give any really useful answer.
When creating a setup/MSI with Visual Studio is it possible to make a setup for a simple application that doesn't require administrator permissions to install? If its not possible under Windows XP is it possible under Vista?
For example a simple image manipulation application that allows you to paste photos on top of backgrounds. I believe installing to the Program Files folder requires administrator permissions? Can we install in the \AppData folder instead?
The objective is to create an application which will install for users who are not members of the administrators group on the local machine and will not show the UAC prompt on Vista.
I believe a limitation this method would be that if it installs under the app data folder for the current user other users couldn't run it.
Update:
Can you package a click once install in a normal setup.exe type installer? You may ask why we want this - the reason is we have an installer that does a prereq check and installs anything required (such as .NET) and we then downloads and executes the MSI. We would like to display a normal installer start screen too even if that's the only thing displayed. We don't mind if the app can only be seen by one user (the user it's installed for).
ClickOnce is a good solution to this problem. If you go to Project Properties > Publish, you can setup settings for this. In particular, "Install Mode and Settings" is good to look at:
The application is available online only -- this is effectively a "run once" application
The application is avaiable offline as well (launchable from Start Menu) -- this installs the app on the PC
You don't actually have to use the ClickOnce web deployment stuff. If you do a Build > Publish, and then zip up the contents of the publish\ folder, you can effectively distribute that as an installer. To make it even smoother, create a self-extracting archive from the folder that automatically runs the setup.exe file.
Even if you install this way, if you opt to use it, the online update will still work for the application. All you have to do is put the ClickOnce files online, and put the URL in the project's Publish properties page.
Vista is more restrictive about this kind of thing, so if you can't do it for XP you can bet Vista won't let you either.
You are right that installing to the program files folder using windows installer requires administrative permissions. In fact, all write access to that folder requires admin permsissions, which is why you should no longer store your data in the same folder as your executable.
Fortunately, if you're using .Net you can use ClickOnce deployment instead of an msi, which should allow you to install to a folder in each user's profile without requiring admin permissions.
The only way that I know of to do this is to build a ClickOnce application in .NET 2.0+
If the user of your application has the correct pre-requsits installed then the application can just be "launched".
Check out:
Microsoft Family.Show
IF UAC is enabled, you couldn't write to Program Files. Installing to \AppData will indeed only install the program for one user.
However, you must note that any configuration changes that require changes to the registry probably(I'd have to double check on that) administrator privilege. Off the top of my head modifications to the desktop background are ultimately stored in HKEY_CURRENT_USER.