Creating folders inside LocalLow through Installer - c#

I am developing deployment project for Vista. In Vista inside AppData folder there are Local, LocalLow and Roaming folders. What I want from installer is to create folder 'Data' inside LocalLow folder and put there file data.xml (AppData\LocalLow\Data\data.xml). Installer should make this operation for all existing user accounts.
How can I achieve this?
This is a screenshot of setup project('Data' folder configuration) which is not working:
Attached example creates the following path: \AppData\Roaming\LocalLow\Data\data.xml

I think a much better approach is to store the xml file in the application's install directory, then, when the application starts up, copy the file to the appropriate directory.
The primary issue is this: what if a user that wasn't on the machine when it was installed launches the application?
Since your installer didn't copy the file to their directory (because it didn't exist), your application would either have to do something or fail anyway.

Related

How to access permission to files after installation?

Today I finally ended creating my app.
To install app I used "setup project" from Visual Studio 2019 (image of project type). App is written in C# .NET 4.7.2 Framework.
So I added some folders and files (image of files and folders here). So I gave my friend *.msi file, he istalled that and something happened - path access denied.
I was surprised because when I installed, everything worked, but on my friend's PC when app is trying to write something in file, it gives result that it cannot open it (just doesn't have permission).
My friend went to properties of those files and he didn't have writing permissions (image here in polish language). In that picture in Polish, zapis
mean "writing", so here is my question: how to make setup project in Visual Studio which gives permission to folders/files to modify them?
In general apps don't have permission to write files to the program folders without elevated permissions. Most apps should write data to the users %appdata% folder you can access that path in c# using:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Every work on files and folders must be in Users\user folders, in Documents\folder or in the registry. You shouldn't give permissions to the user to modify files on the system or Program Files.
Although windows installer is able to set file permissions, you should not write anything in Program Files. And you should not grant write permissions there due to security considerations and best practices. So, you need to inspect your code and change all places where you are trying to write in a Program Files (or in the folder where your application is placed) to write somewhere else. For example, in the %temp% folder, in the Program Data or in specific folder inside a user's Documents folder or even ask user to specify write location explicitly.

Deployed VS 2010 WPF Application Cannot Update Log Files Unless in Administrator Mode

I have a WPF Application that uses nLog to write out log files. On my machine it writes out the log file successfully.
I have created a deployment project, and generate an install, which installs it into program files . The install works successfully, but when the application is run, the log file generated by nLog is not created. No exception is thrown.
I am running Windows 7.
The log file is being created in the same directory as the executable.
If I run the deployed application in Administrator mode, the log file is created successfully.
How can I get past this? Would signing the executable help? Do I really need this to run in admin mode?
The problem is that you need to log to a different location. You should not write to C:\Program Files from your application. Instead, move your log files to something like %APPDATA%\Your Company\Your Application\Logs.
By using %APPDATA%, your application can run on different versions of Windows, and if they change the structure of the standard directories (like between XP and Vista), your application will log to the correct location still.
The Program Files directory is properly locked down. Change the application to write the log file to an unrestricted location. (I prefer the all users' application data directory.)
What others have said: the program files directory is locked down. You need to use another folder location to log towards.
I have had great success logging to the UserProfile special folder so that my logs wind up in this folder structure:
C:\Users\CurrentUser\My Docuements\Company Name\ApplicationName\
See this link for some useful information on special folderes: http://en.wikipedia.org/wiki/Special_Folders
%USERPROFILE%\Documents

Permissions on Application Folder

I have a default application setup created using Visual Studio 2005. When my application is installed, it's only work running as administrator, because some files are written in the Application Folder.
I have found that on Visual Studio 2010 there is a property for change this permission on some folders inside application folder.
How can I allow to my application create and edit specific files inside the application folder without run it as admin?
Here are your options, assuming that you cannot change where the application itself attempts to read/write files:
Change the default installation directory of the installer of the application, to not go inside C:\ProgramFiles, but instead to a folder just off the C:\ drive that has more lax access permissions. This was standard practice in Windows 3.1 and even Windows 95, but these days you can't get a program "certified" by Microsoft as compatible with any supported Windows version unless it installs into the proper Program Files directory. These modern OSes also have the root of the C:\ drive locked down pretty tight so you'd need administrative permissions to install the app (but not to run it).
Create a custom action for the installer which increases the access rights of the program subfolder during installation. Again, Microsoft is unlikely to certify the app if you do this, and this also requires admin permissions to install the app, meaning the average user on your network can't just pull it down and run it.
Install the files that must be altered in the "proper" places (Application Data for user-specific files, Program Data for files pertaining to the software as a whole), and then create shortcuts within the main application folder that point to the files in their accessible locations. The legacy app shouldn't know the difference.
EDIT: Here's a method straight out of the custom actions of the installer for an app I wrote that has a similar "legacy" app, which has to read/write data from config files in a subfolder of the app's "home" directory. The IDictionary passed in is the one you get from the various custom action methods (OnBeforeInstall, OnAfterInstall, OnCommit, etc), so you simply drop this into an Installer class, call it from the handler for the install event of your choice (which must be after the installer has made the file system changes), and call it:
private void SetEditablePermissionOnConfigFilesFolder(IDictionary savedState)
{
if (!Context.Parameters.ContainsKey("installpath")) return;
//Get the "home" directory of the application
var path = Path.GetFullPath(Context.Parameters["installpath"]);
//in my case the necessary files are under a ConfigFiles folder;
//you can do something similar with individual files
path = Path.Combine(path, "ConfigFiles");
var dirInfo = new DirectoryInfo(path);
var accessControl = dirInfo.GetAccessControl();
//Give every user of the local machine rights to modify all files
//and subfolders in the directory
var userGroup = new NTAccount("BUILTIN\\Users");
var userIdentityReference = userGroup.Translate(typeof(SecurityIdentifier));
accessControl.SetAccessRule(
new FileSystemAccessRule(userIdentityReference,
FileSystemRights.Modify,
InheritanceFlags.ObjectInherit
| InheritanceFlags.ContainerInherit,
PropagationFlags.None,
AccessControlType.Allow));
//Commit the changes.
dirInfo.SetAccessControl(accessControl);
}
You could manually change the NTFS folder permissions using Windows Explorer to the Application Folder. However, it would be best practice to read/write to a different folder.
Don't write anything to the application folder (under program files). Instead use the user's home folder, or, if you want to write something that's relevant to all users on the machine - ProgramData.
EDIT:
If you can't change your application code, you should still avoid placing program data files under ProgramFiles if you can. There's one other thing you can do. You can create a folder under c:\ProgramData, and just create a symbolic link to it from C:\Program Files... . That way, your legacy application still finds the data where it expects to find it.

How do I configure VS installer to put files in LocalApplicationData

Everything in Visual Studio seems to lead one to putting data files with the application.The app.config goes there, when I create an .XML data file, there is a Copy to Output property that will automatically copy that file to the exe folder. Howerver, it seems that under Vista and Win7 UAC doesn't want the application to be able to write data to any file in the application directory. So I'm changing my evil ways so that I use the LocalApplicationData folder for files I want to read and write. (I just read the app.config so I'm leaving it alone)
I'm using a VS2010 Visual Studio Installer project to create the installer for this app and I can't seem to find a way to target the folder for my .xml file to the LocalApplicationData folder. I can click on the file and see a Folder property but the dialog only has options for Application Folder, User's Desktop and User's Program Menu. Is there some way to do this in the installer or do I have to write code that checks for the file and copies it over from the .exe folder when it doesn't exist? I figure I'm late to this particular party and there must be a canonical way of handling this.
Also, I'm wondering about debugging, is there something similar to the copy if newer functionality in the build process that will now copy this .xml file automatically over to the LocalApplicationData folder whenever I update it?
The Setup project doesn't expose LocalApplicationData in the Special Folders list. You can use it anyway by doing this:
Add a Custom Folder and set the DefaultLocation property to [LocalAppDataFolder]

C# vista does not giving access to create folder

In my project I have to create some files and directories into my app folder which is into program files. But in vista it is giving me error that I dont have access to create file.
What should I do now for giving access ? Also it not let me access the registry !!
The program folder is not the place to store application data. There is an %APPDATA% folder for that - you are supposed to store your data there.
Use System.Environment.SpecialFolder and System.Environment.GetFolderPath to obtain the path leading to the correct directory.
Also, you need to differentiate between just creating a folder and putting some files in there (for example during installation) or writing to the program folder at runtime, while typically running under a limited account.
The reason for this difference is simply that installation routines and setups run with elevated privileges under Vista / Windows 7, thus those are allowed to create folders and files there. Still, those files are not supposed to be written to at runtime of your application.
So, what is it you want to do? Write data at runtime, or put some files (i.e. dependencies) in your application folder at a single time? If it's the first, comply with the rules and use the %APPDATA% folder. If it's the second, create an installer / setup routine.
Vista and Win 7 have the Program Files folder locked down so you can't write to it with a basic user account. If you need to create folders there, then you should do it in the installer. Otherwise you can use the user's Application Data folder in their profile.
The only other way is to modify the permissions on the installation folder at install time.
Can you turn the UAC off? Or Login as administrator? The chances are that you are creating the folder in the wrong place.

Categories

Resources