I want to update my website by extracting a zip file which contains whole files of the website itself. Apparently the system does not allow me to do this as such folders are protected:
Error while extrating: Access to the path
'C:\WebsiteFolder\Website\bin\' is denied.
I also think that changing the dlls will restart the server while extracting. Is there a way to do this? To extract all files then restarts the server after it finishes. Also the web.config might be overwritten while extracting the zip file.
Does putting offline.htm help?
This is because IIS is using files within the bin directory, and the AppPool is likely running as system, or an administrator account.
Stopping IIS (or the app pool) will enable you to replace the files.
I also think that changing the dlls will restart the server while extracting
Yes, it will restart the app pool when you change these files
Related
Is it possible to attach a flat file to windows-service?
My windows-service uses few flat file (for data purposes). Usually, if it's a normal executable I would place those files in the same directory as exe. How can I achieve that with windows-service?
I've done some research on this, but all I found was:
1. Pass a path to those files as a parameter to windows-service.
2. Make a fixed path and just require those files there
But I don't like those solutions. I was wondering if it's possible to attach those files to the windows service while installing it?
How about adding these files inside the project as Embedded Resources? They won't show up on the disk, but you could still properly read them from inside the assembly itself.
Here's some reference: https://support.microsoft.com/en-ie/kb/319292
You can look up the directory that your application is installed in at runtime, using the Application.StartupPath property from System.Windows.Forms. This works for both applications and services. You should avoid hard-coding the path that you think your application is installed in, because the end user may have installed it somewhere else. You should also avoid using the current directory (i.e., opening the file by name only, without a specific path) because the user may be running your application with a different current directory.
Note that installutil does not make a copy of your service executable. So the service runs from the same directory that it was in when you installed it, and any files you place in that directory should still be there when the service is running.
After using the free version of InstallShield and installing my app on my machine I noticed that my data file (a sqlite .db file) is being saved in a different location than when I run it under Visual Studio. Basically instead of being saved in the directory with the .exe file it is being saved here:
C:\Users\blaaah\AppData\Local\VirtualStore\Program Files (x86)\MyAppA\MyAppA
My .exe file with its .dll files is being saved here:
C:\Program Files (x86)\MyAppA\MyAppA
I am curious as to why that is happening?
I am also curious on how to get that directory that contains my data file with code.
The VirtualStore folder is caused by file system redirection done by UAC. By doing this, Microsoft was able to lock down the Program Files directory without sacrificing too much backward compatibility. Any time an application tries to write to the program files location, the write will be redirected to the Virtual Store.
A decent writeup on this on MSDN can be found in the User Account Control For Game Developers article.
To quote that article:
Virtualization affects the file system and registry by redirecting system-sensitive writes (and subsequent file or registry operations) to a per-user location within the current user's profile. For example, if an application attempts to write to the following file:
C:\Program Files\Company Name\Title\config.ini
the write is automatically redirected to:
C:\Users\user name\AppData\Local\VirtualStore\Program Files\Company Name\Title\config.ini
Likewise, if an application attempts to write a registry value like the following:
HKEY_LOCAL_MACHINE\Software\Company Name\Title
it will be redirected instead to:
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Company Name\Title
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
I am using C# with .net 3.5
I am saving my program data in a file under: C:\Program Data\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data")
and then I reinstall the application, and ran it.
The strange thig is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\Program Data\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin priviliges instead of getting: "C:\Program Data\MyProgramName\fileName.xml" I get "C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml"
and indeed there was a file that existed from the previous installation (that I obviously didn't delete ,because I didn't know it existed).
So apparentlly there is some virtual path to the file under program data.
EDIT :
I found out that after deleting the old file in the virtual store, my application is suddenly able to find the correct file. (I didn't make any changes in the file under Program Data.
My question is:
why is it happen.
How can I prevent it from happening
Thanks in advance
Do you actually have to write to the per-system Program Data folder instead of the per-user Application Data folder(s)?
You might want to take a look at Environment.GetFolderPath and the following Environment.SpecialFolders:
Environment.SpecialFolder.ApplicationData - data folder for application data, synchronized onto domain controller if the user profile is roaming
Environment.SpecialFolder.LocalApplicationData - data folder for application data, local and not synchronized (useful for, for instance, caches)
EDIT:
Tested on Windows 7 x64, non-administrator user.
var appData = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
var myFolder = Path.Combine(appData, "MyApp");
if(!Directory.Exists(myFolder)) Directory.CreateDirectory(myFolder);
File.WriteAllText(Path.Combine(myFolder, "Test.txt"), "Test.");
This does what is expected, ie. writes into C:\ProgramData\MyApp\Test.txt. As far as I can tell (Administrator mode Command Prompt), there's no UAC virtualization going on either.
Double edit:
I guess what's happened is that at some point an Administrator user has written the files into your ProgramData folder, and as such, UAC file system virtualization kicks in and redirects the non-administrator writes into the VirtualStore.
Does your uninstaller run as Administrator? If it does, you might have to check both the VirtualStore path for the user who initiates the uninstall, and the actual file system path for program data to remove. I'm not sure if there's an official way to do this, though...
I found the reason for the bug.
the application is trying to take ownership on the file and then the other file is created.
I removed that line and now everything works just fine.
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.