I have a very simple C# console application that copies a specific node from an existing XML file located on my computer to another XML file, also located on my computer. I've hardcoded the paths in an app.config file within the solution.
When I debug my solution (F5) the files get updated appropriately. However, if I run without debugging (Control+F5) or if I build (or publish) to bin/Release or bin/Debug and run the my-console-app.exe the application fails to save any file to disk.
Strangely this app used to work without issue (it was used in conjunction with a .bat file which called it and deployed the updated configuration file to a server). But over the last few weeks I've noticed this console app has seemingly worked less and less over time to the point where to get my update script to run successfully I have to open this console application's solution, press F5, then run my .bat script.
I've used ProcessMonitor by sysinternals to verify that files are being read/written and it says that files are being written to the file paths that I'm specifying, however when I browse to the directory the file doesn't not exist or is not updated.
I'm using VS2010 on a Mac Mini running Windows 7 Ultimate via Bootcamp.
TL;DR; Console app works and updates files appropriately when debugging but not when run without debugging or as a standalone or published .exe from bin/Release, etc.
var devConfig = XDocument.Load(DevConfigPath, LoadOptions.None);
var prodConfig = XDocument.Load(ProductionConfigPath, LoadOptions.None);
var devMethods = devConfig.Descendants("deliveryMethods");
prodConfig.Root.Element("Heg.EA.Delivery").Element("deliveryMethods").ReplaceWith(devMethods);
try
{
Console.WriteLine(String.Format("Dev First Node:{0}", devConfig.Root.Element("ClientDeliveryTest").Element("deliveryMethods").FirstNode.ToString())); // Test Node to ensure file is being read correctly (it is).
Console.WriteLine(String.Format("Production First Node:{0}", prodConfig.Root.Element("Heg.EA.Delivery").Element("deliveryMethods").FirstNode.ToString())); // Test Node to ensure production configuration is updated correctly (it is).
Console.WriteLine("Saving...");
prodConfig.Save(#"C:\ProductionConfig.config"); // FAIL.
prodConfig.Save(#"ProductionConfig.config"); // FAIL.
prodConfig.Save(ProductionConfigPath); // FAIL.
Console.Write("File Saved.");
}
catch (Exception ex) // No exception is ever thrown.
{
Console.Write(String.Format("Error Saving: {0}", ex));
}
Found a solution. I uploaded my solution to my work repository and had my boss check it out. He was able to open it, build it, debug it, and run the exe from bin/Release. However, when he ran the exe, Avast popped up with a friendly message, denying him access, which he remedied and the program execution continued.
I also have Avast. It never prompted me to allow/disallow my app from executing or writing to disk. But I went to the avast options and disabled the AutoSandbox feature and everything worked.
TL;DR; Antivirus settings prevented my console app from writing to disk and didn't prompt me about it.
Related
I'm trying to remote debug an application that I have occasionally in the past without problem. I have a shared directory that I use for output on the remote machine, remote debugging tools are running on the machine and working fine. The folder has "everyone" permissions to be sure.
When I rebuild, all output files are generated, including the one I'm trying to debug. I'm then given an error,
"Error while trying to run project: Unable to start program
'D:\MyShare\MyApp.exe'.
The system cannot find the file specified"
This is particularly odd because the file exists, it just created it, and I can execute it manually just fine, either locally, or on the remote machine. I've checked with Process Monitor and that suggests the file is fine, so Visual Studio seems to be able to see the program just fine, not sure what's causing the error.
I've restarted both sides without luck.
Typical, I resolve it just the second I post this... The solution was to use the full UNC Share path, not the mapped drive path.
so my project 'Output Path' of
d:\myshare\
became
\\somepc\myshare
Now it all works as expected.
So, I have completed a C# console application using Microsoft Visual Studio 2012.
I have a local file within the project folder. Within my code, I have performed a log writing operation by assigning the relative path of this file to a string variable. The file was created during the first build/run and then appended with information during further runs.
string rpath = "..\\LogFile2.txt";
I built this project in debug mode and ran it. During this run the rpath is correctly identified as
c:\project_app_folder\bin\LogFile2.txt
However, while building this project in release mode and then scheduling the .exe file to run at a particular time in the windows task scheduler, I get a run-time error saying
Could not find a part of the path 'C:\local\pic'.
How do I resolve this? I want the temporary folders or text files created during run time to be part of my project folder/package?
Please also note , I cannot put absolute paths as this code will have to be packaged and sent to another user and that user may chose to store the program in a location he/she sees fit.
This issue is not because of release mode, when the scheduler invokes the program the working directory will be different as #Damien_The_Unbeliever said. you can use the "start in" option when you specify your action, as your release directory.
The "start in" is mainly to make sure that if you have relative paths
in the task to run, it understands which directory to use.
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've spent the last two hours Googling on this with no results, so…
I am developing an application which uses XML files to save data. These files are supposed to exist in the same directory as the program executable. I use:
string filePath = System.IO.Path.GetDirectoryName(Application.ExecutablePath) + "\\xml\\filename.xml";
It works.
I've created the installation file in Inno Setup. This works as well, copying my XML files exactly where I want them to go.
I open my application directly from the installation folder, from the Start menu icon, from a desktop shortcut, and it works fine.
I make some changes to my program, then I close it and start it again. Everything is fine: all the saved changes are read back from the XML.
But then I open the specified XML file and there are no changes!
I wouldn't bother as at least it's working, but:
When I uninstall the application then install it again to the same directory, changes made to the previously installed file are still there!
I'm very curious to know what's happening.
This only happens if the program is installed to Program Files. If I install it to My Documents, changes are shown in the XML files and after reinstalling it the default settings are restored as expected.
My questions are:
Where are those XML files being stored, and how can I load it if the specified path points to Program Files and they are not there?
Obviously, how do I fix it?
EDIT
Finally found those files in C:\Users[USERNAME]\AppData\Local\VirtualStore\Program Files[APPNAME]
Check what is saved into your local application data folder (it's \Users[USERNAME]\AppData\Local\ for Windows 7).
It looks as if your app didn't have rights to save things in your ProgramFiles folder and saved it where it could, probably in this location:
String appData =
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
Also you may try running your application as administrator and check if changes to your xml data still doesn't show.
Cant you print out the value of
System.IO.Path.GetDirectoryName(Application.ExecutablePath)
then you should be able to see where your xml files are stored, if it is a console application just use Console to print if it is WPF print it to a label or something
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.