I have a strange phenomen
I have .Net 4.0 app.
When the myapp.exe.config is under the normal programfiles folder it is ignored. Even if I delete it or write nonsense in it the myapp.exe works and it seems to me that values are taken from a previous installation.
When I copy the folder to e.g. to Desktop it works correct.
Edit: when I copy form c:programfiles\myapp\ to c:\programfiles\copy of myapp\ it works
It seems to be only a problem in the progamfile folder where a previous installation has benn made. (I guess)
Any ideas?
Best regards
Could you share your operating system with us? I have had similar problems in the past with an application (Win 2008). One simple work arround if you are not the system administrator, is to edit the .config file on another location, and then place it back.
Sometimes the content of a file is not really editted, however a copy is created with your changed on the back, which is confusing.
Most probably you are dealing with a case of "compatibility files" - in your Program Files folder you have a file saved in the Compatibility files view that is being read instead of your actual file.
Delete the compatibility files and everything should work correctly.
In this article, in the "how about the ugly part?" you will find described exactly your scenario.
Best regards
There is a folder
C:\Users\myuser\AppData\Local\VirtualStore\Program Files\myapp
Where there was the config which was taken.
This "feature" comes that my app runs not as admin.
Read the comments to UAC.
This happens only to Win7 and Vista. Not on XP.
regards
Related
I have a question which will probably be quite vague.
I'm developing a Windows Forms application in C# that can read and write games to an Access database. Every game has an attribute that links to an Image in the resource folder.
While debugging I was able to just read and write my screenshots to the following path:
"..\\..\\Resources\\Screenshots\\";
I tried publishing my application earlier today to test if it would still work and if not, to locate the path where the Resource folder would be when published.
So far I have the feeling that the resources just get burned into the exe file or one of the other files it generates.
Is it in any way possible to have a real folder in the published version of an application from which I can keep reading and writing my images like I did while debugging?
Thanks in advance.
Yes your screenshots will be compiled into the assembly as resources when publising.
As for the real folder, you can absolutely do that. Make sure you give your app the right path to that folder.
I write a small application, that I don't need store anything in config files. So the file App.config in my source is exactly what ever Visual Studio has created.
So I want to delete this file from source code (before compiling). But I noticed that it also contains the .NET version information. I wonder if I delete App.config file, then copy my application to other pc, is it have any strange behavior?
I wonder if I delete App.config file, then copy my application to other pc, is it have any strange behavior?
Nope, it should be fine. There are various (somewhat tortuous) rules about exactly what version of the CLR etc gets used in what situations, but for the most part you're fine to just rely on the default behaviour.
You really don't need an app.config file unless you need to give specific settings.
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.
I've built a winforms app (C#) that will take a list of file paths, and copy those files (from a different VS solution) to a new location (In a folder the user specifies) in the same directory structure they currently exist on local file system.
I use the Path class, Directory class etc and everything works wonderfully...except when it reaches a file path that points to a DLL.
The DLLs I am trying to copy are a part of the other solution, and that solution is not currently open.
I have tried restarting computer to make sure visual studio isn't somehow hooking into that DLL even after the solution is closed.
The DLL in question can be copied by regular manual means (i.e. copy and paste shortcut).
So short of creating a batch file in the program, and running xcopy on that DLL path, I don't know of a way to get this to work.
From what I have found from google searches (which isn't much on this particular situation), File.Copy() should work..
Any help would be wonderful, even if it is a link to a duplicate question I may have over looked.
Thanks!
-The error message is: The process cannot access the file [insert file path] because it is being used by another process (The path is definitely correct also)
-Just downloaded and tried to search for the DLL name with Process Explorer.. I also ran a similar exe from command prompt to no avail. It claims nothing is using it. That's why I am utterly baffled by this. Also, I just checked the permissions and everything looks great (i.e. Full Control, owner effective permissions)
-It does not handle open files. It basically build the correct src and dest paths and does a File.Copy() on those. How would I go about handling open files? I'm sure I could figure out if it was open, but what would I do it it were open?
It is not complaining about the file you're trying to copy, it is complaining about the file that you're trying to overwrite with the copy. Lots of candidates for that, virus scanners always get very excited about new DLLs, for example. Or it is loaded into a process, the typical failure mode for trying to implement your own auto-updater.
You can rename the target file to make your copy succeed.
Are you in vista or win7? If so, Check your 'User Account Control Settings'. Sometimes this can interfere with .NET security options and prevent file operations that would otherwise work.
As well as Process Explorer, I would use Process Monitor also from Microsoft so you can see what is happening at the point of failure and allows you to see if anything else is accessing the dll.
Possible culprits are
the program you are running,
your antivirus package
a virus.
If the path it is complaining about is the destination path, then is is possible that the path is too long?
Also, when using Process Explorer, make sure you have enabled the option to show details for all processes and not just your own.
I just ran into this issue as well. I tried copying a .DLL from an FTP server to a local directory (replacing the existing one) and for the life of me I could not get it to work. Keeps giving me an 'Access Denied code: 5' Error.
I then realized that the .DLL on the FTP server was not marked as hidden while the .DLL I was trying to replace was marked as hidden.
Once I changed the local one to also be visible. I had no more issues.
So my solution is:
Make sure both files are visible.
Hope this helps someone
I have c# program which writes an xml file to "C:" disk. I published my program as one click package because it's for test purpose only. But the problem is the one click package doesn't have "run as admin" option. So how can I solve this problem ? Any idea ?
The correct solution is not to force administrator elevation to bypass the built-in operating system security.
The correct solution is to fix the broken program. Even though it's just a test program, it should be written correctly.
See this SO question and the answers for more details. Even though it deals with the Program Files folder instead of the root, the underlying problem and solutions are identical.
I don't know if this works with One Click Deployment, but you could try to include an Manifest with your executable to request that the application is run with higher privileges.
See Create and Embed an Application Manifest (UAC).