How do I add write and modify permissions to a text file that will be installed in the Application Folder in the File System on Target Machine?
Your post seems to indicate that you are using Visual Studio setup projects, the Installer add-on.
Two basic points:
There is no support for doing this in Visual Studio setup projects, so you would need to write custom action code that alters those permissions. The code to do that is about security APIs, so you probably won't get an explicit answer here.
The most common reason people do this is that the application needs to update the file, and it fails because updating ProgramFiles folder content requires administrator privilege. If this is the case then your application design should be improved by having the file in (say) the User's Application Data folder, which has that name for the obvious reason that's the preferred location for such data.
Related
I have an application written in C# using VisualStudio 2015 and I want to publish it (eg give an exe or installer to somebody to use it on its PC). From VisualStudio there is possibility to click "publish" in solution explorer. The result files are:
-Application files (File folder)
-project.application (Application manifest)
-setup.exe (Application)
As far as I know "manifest" file should be some metadata, but I can execute that file and it gives me an installer (the same as setup.exe). After installing it runs an application (just like setup.exe). It makes me confused - what exactly project.application is? Can I delete it and use only setup.exe? What is the correct way of publishing an app? One last thing: why does the installer run installation on first execution and run an application on any other? I would expect to run installation any time (just like other software).
Thanks
It sounds like a ClickOnce application. See the following link for more information:
ClickOnce security and deployment
In a nutshell:
The installer copies the files to the users AppData and then runs the application.
There are also other options such as checking for updates from a network location or web address. Then when you run the application it checks for updates and uses the manifest to do an incremental update of the application files.
I'm fairly new to windows forms and I was recently tasked with creating a simple software which will be deployed by USB drives to other companies. I made this software so during first run I check for a config.xml file. If it doesn't exist, I will send the user to a form to configure their first time setup. Next time I run the program, it skips this step since the config.xml file is found with its values. The problem is when I debugged this, I found the config.xml file alongside the executable, however when I ran this on a different computer, it stored it into the appdata virtual store. I read up on this and found out it has to do with write permissions.
Is there any way I can get around this without prompting the user to do anything extra on their part such as run as administrator? I also plan on saving the resulting reports generated by the use of this program and was hoping I can have XML files which can be easily found within the application folder.
*Note, I am aware of the built-in settings system but this also stores into appdata and if the executable is moved to another directly, it loses sight of that config and wants to create another.
EDIT : Please be aware I am trying to AVOID writing to the AppData folder. The software is packaged with Visual Studio Installer - Setup Project. A msi file is created which stores the application in C:\Program Files (x86)\\. Inside this directory I have the executable, the exe.config file which is generated, and any DLLs needed. This is the folder I am trying to also store the config.xml file but due to some windows magic, the code thinks its storing it here but in reality it is being stored in the virtualStore folder located in AppData.
Have you thought of using the C:\ most computers have this unlocked. alternitively use Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
the AppData folder is stored in the username space and requires no permission. (just remember to create a folder for your program to avoid conflicts)
It is a known issue due to security concerns that write permissions are limited.
More can be learned here.
Since no one was able to answer this, I will post my solution. Instead of packaging the solution using Visual Studio Installer tools. I install the application by copying the resulting executable from the build. This version of the application has write permissions that would have not existed if the application was installed using the resulting .msi from the Installer tools.
I created a setup project in VS2008. This setup copy some folders/files to the program files folder. Also, it adds some windows environment variables.
During the instalation, I am requested to confirm something in a UAC dialog.
This works fine, and all files are copied.
The problem begins when my program is running and I have to modify the a file´s content.
An exception is thrown, saying that I have no permission. Also, if I try to do the same operation in Windows Explorer => same problem.
My question is:
If I have the permission to install my software in program files folder, shouldn´t I be able to write in this folder as well?
Well, it seems that this is a general permission problem. By default normal users (and applications) cannot write to %PROGRAMFILES%. There are folders specially provided for application data storage such as ApplicationData
The reason the setup does install into program files is because this default behaviour of the Windows Installer. Check this link for more info on the Windows Installer and clickonce setup
I have written a application in C# using visual studio, I have made a project set up file which as created to files for me in my debug.
The Windows Installer and the setup application are both needed, but i would like to merge them into one, like when you download an app the installer its just one file.
Could some one please show me how to do this, or just point me towards a good source.
Thanks in advance.
If you're using Visual Studio's built-in setup project template to generate your installer, then you don't need the setup.exe file at all.
The only thing you need to distribute is the .msi file. That contains everything that a user would need to install your application. The setup.exe file is simply a stub that launches the setup routines from information in the .msi file, which is a database that the Windows Installer uses to install your application. And since these files can be launched by double-clicking on them if the Windows Installer service is installed, you really don't need to distribute the setup.exe bootstrapper if you don't want to.
Some special reasons that you might want to distribute a setup.exe file are:
You expect for some reason that your users might not have the required version of the Windows Installer installed on their computer. This is getting to be pretty rare nowadays, especially considering how widespread broadband Internet connections are and how pushy OS vendors are getting with pushing automatic updates. But if your users are "disconnected" (in many senses of the word), you might want to use a setup executable to verify the presence of the necessary version of the Windows Installer, install it if it isn't there, and then launch your .msi file to perform the install. (You cannot run a .msi file if you do not have Windows Installer installed.)
You need to support multiple languages. In this case, the setup.exe file can perform a language transformation on the .msi file before launching the installer.
You want to manage the installation of several .msi files in sequence. The way that Windows Installer is designed, it's difficult to chain installations of .msi files, which makes it difficult to install dependencies before or after you install your own application's files. A setup.exe file is not subject to the limitations of the Windows Installer, so it can be used to chain these and precisely manage the order of installation.
In general, creating your own setup.exe file (or using one of the many third-party installer software packages to create it for you) gives you significantly greater flexibility. You essentially have complete control over the installation process, rather than having to follow the rules of Windows Installer.
But 83.44% of the time, this isn't necessary and you should follow the much simpler route of using an .msi file. This also allows system administrators to automate installs across machines that they manage (for example, throughout a corporate network), something that is not supported for raw executable files.
So the wizards of IT brilliantly put in to place new GPO that prevent access to the AppData folder structure in Windows for user PC's. However, when you publish an application the application when installed is defaulting to C:\user\roaming\appdata, well the application can no longer access that directory.
How do I create a custom install path for the application to use?
Thanks!
Does this link about changing the InstallLocation attribute help?
Also keep in mind that user settings are stored in an AppData folder so if you use that you may need a workaround for that too.
I would create a Setup and Deployment project to handle installation. It is very easy to add using the Setup Wizard project template. In this project you will be able to specify the default location of the application folder.
My Assumption if you are using ClickOnce Deployment you can't define the installation path.
The idea of ClickOnce is making sure it doesn't require admin privileges to install the update therefore it kept under user app profile. There was discussion here
if there is a reason to put you data and keep it safe from ClickOnce update.
refer to here Keep data safe from ClickOnce deployment
another option as #Kevin mentioned create standalone MSI installer would allow you to specific the application install path however it would be manual intervention.
Personally I don't know why there is a need to prevent access to user AppData folder (perhaps re-define GPO to allow certain app folders access) could resolve that given if you want to continue using ClickOnce deployment