I have an application in Visual Studio C# which includes saving into a text file, how can I have a .exe sent to another computer and not have an exception in saving?
I need to send a .exe file by email (Yes it's possible) and this application includes saving the state of the game. How can I send this .exe file and let the user be able to save in his computer please?
The problem is that when I send my application's executable file on another computer, I'm getting an exception in saving. Because on the other computer I don't have the text file which I'm saving the game.
I am saving here :
StreamWriter myFile = File.CreateText(Directory.GetCurrentDirectory()+"//ConnectFour.txt");
in the obj/Debug/ of the project..
Thanks for your help :)
Sending an executable should work just fine.
Make sure the other computer has the appropriate Microsoft .NET Framework installed.
Latest framework installer: MSDN
Also, make sure the path inwhich you're saving the file to exists on the remote computer. For example, if you're trying to save to the D:\ drive and it doesn't exist. You will get an exception.
Most likely current location is not writable by current user.
Using "current directory" is dangerous as you have no control over where application is launched from. It is very useful for command line utilities, but not so much for regular windowed applications. Use location that you know you can save files to - i.e. "My Documents".
var filePath = Path.Combine(
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments) + "\\",
ConnectFour.txt");
using(var myFile = File.CreateText(filePAth))
{
// save data here.
}
The problem when sending executables by email are the anti-virus-scanners. Some of them refuse e-mails containing executables. Others accept the mails but delete the attachment.
The solution consists in hiding the executable. This can be done by zipping the executable and sending the zip-file.
Often this is enough to solve the problem but some anti-virus-scanners are very smart and even recognize executables within the zip-attachment. The solution here is to encrypt the zip-file with a password. I often just use the password "pwd" and mention it in the e-mail text. The anti-viruses are not (yet) smart enough to understand this text.
UPDATE
Now I understand your problem. It has nothing to do with sending the executable.
An application can determine from which directory it has been started like this
string dir = System.IO.Path.GetDirectoryName(
System.Windows.Forms.Application.ExecutablePath
);
An alternative is (if you don't have a reference to WinForms):
string dir = System.IO.Path.GetDirectoryName(
System.Reflection.Assembly.GetEntryAssembly().Location
);
You probably do not have sufficient privileges to save the file on the remote machine. If you give us more information on the exact exception that is being thrown (type of exception, message, stack trace, etc) you will get a more accurate answer.
Related
I'm working on a program in C#, a part of which is to create a directory in the Application.StartupPath folder and then write a text file inside it using System.IO.File.WriteAllText(). My issue is that my program crashes, throwing an UnauthorizedAccessException and telling me that "Access to the path is denied", which is, well, odd, considering that it crashes regardless of the directory from which I am running the program, whether it be running from my cloud folders, Desktop, My Documents, etc, and even despite running it as Administrator in any of those directories.
The path from which I'm debugging it is C:\Users\Jeff\Google Drive\Documents\Visual Studio 2013\Projects\Palobo\Palobo\bin\Debug. It is using System.IO;, and the code I'm using includes:
Directory.CreateDirectory(Application.StartupPath);
File.WriteAllText(Application.StartupPath, "Password=" + x);
where x is some String data entered by the user.
The error I get is:
Access to the path 'C:\Users\Jeff\Google Drive\Documents\Visual Studio 2013\Projects\Palobo\mzdon29 is denied.
(mzdon29 being an encrypted result of jwalk96).
Does anyone have any ideas as to why I'm encountering this problem? Thanks!
Application.StartupPath is a folder (where your application is started from). Try to specify an exact filename inside that folder:
File.WriteAllText(Application.StartupPath + "\\MyFile.txt", "Password=" + x);
Let's look at this code:
Directory.CreateDirectory(Application.StartupPath);
File.WriteAllText(Application.StartupPath, "Password=" + x);
You're trying to create a directory that already exists, and then you're trying use the directory as a file name! You need to add something to end of the path, so that you're working with a new folder and file.
Also, using the StartupPath for this is poor practice in the first place. You can create a shortcut that sets the startup path to anywhere. But specifically, it's common for the default StartupPath to be somewhere under the Program Files folder. Items under this folder are read only to standard users by default. Instead, you should look at using the Application Data folder, like so:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Finally, this sure looks like it's saving a password in plain-text. Do I really need to go over how bad that is? You shouldn't even save passwords encrypted (hashing is different than encryption), and this is one of those things that's so important you shouldn't even do it for testing/learning/proof of concept code.
I am developing a Windows Phone 8 application but am having a lot of issues with file access permission exceptions hindering the approval of my application when ever I try accessing files in the "local" folder (this only happens after the application has been signed by the WP store, not when deployed from Visual Studio). To solve this I have moved all file operations to IsolatedStorage and this seems to have fixed the problems.
I only have one problem left though. My application needs to make use of the file extension system to open external files and this seems to involve the file first being copied to the local folder where after I can then manually copy it into IsolatedStorage. I have no problem in implementing this but it seems that a file access permission exception also occurs once the system tries to copy the external file into the local folder.
The only way I think this can be solved is if I can direct the system to directly copy into IsolatedStorage but I cannot figure how to do this or if it is even possible. It seems as if though the SharedStorageAccessManager can only copy into a StorageFolder instance but I have no idea how to create one that is directed into IsolatedStorage, any ideas?
PS. Do you think that the Microsoft system might be signing my application with some incompetent certificate or something because there is not a hint of trouble when I deploy the application from Visual Studio, it only happens when Microsoft tests it or when I install it from the store using the Beta submission method.
Below is a screenshot of the catched exception being displayed in a messagebox upon trying to open a file from an email:
EDIT:
Just to make it even clearer, I do NOT need assistance in figuring out the normal practice of using a deep link uri to copy an external file into my application directory. I need help in either copying it directly into isolatedstorage or resolving the file access exception.
Listening for a file launch
When your app is launched to handle a particular file type, a deep link URI is used to take the user to your app. Within the URI, the FileTypeAssociation string designates that the source of the URI is a file association and the fileToken parameter contains the file token.
For example, the following code shows a deep link URI from a file association.
/FileTypeAssociation?fileToken=89819279-4fe0-4531-9f57-d633f0949a19
Upon launch, map the incoming deep link URI to an app page that can handle the file
// Get the file token from the URI
// (This is easiest done from a UriMapper that you implement based on UriMapperBase)
// ...
// Get the file name.
string incomingFileName = SharedStorageAccessManager.GetSharedFileName(fileID);
// You will then use the file name you got to copy it into your local folder with
// See: http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.storage.sharedaccess.sharedstorageaccessmanager.copysharedfileasync(v=vs.105).aspx
SharedStorageAccessManager.CopySharedFileAsync(...)
I've inline the information on how to do this from MSDN http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206987(v=vs.105).aspx
Read that documentation and it should be clear how to use the APIs as well as how to setup your URI mapper.
Good luck :)
Ok I figured it out. The "install" directory is actually restricted access but for some reason the Visual Studio signing process leaves the app with enough permissions to access this folder. The correct procedure of determining a relative directory is not to use "Directory.GetCurrentDirectory()" but rather to use "ApplicationData.Current.LocalFolder". Hope this helps!
I have created a .msi by using VS2008 setup project. My application frequently writes some value in a .txt file in the application directory (C:\Program Files\MyApp\MyFile.txt). After insalling it in Win7, it raises an exception "Access to the path .... is denied."
But whenever I run it as administrator, no such exception occurs. Here is my sscce
string FilePath=Application.StartupPath + #"\AppSettings\CurrentUserName.inf";
using (StreamWriter writer=new StreamWriter(FilePath,false))
{
writer.Write(txtLoginName.Text.Trim());
}
MainForm.ProcessLogIn();
this.DialogResult = DialogResult.OK;
I don't know how to solve this problem. Any suggestion?
Move your file out of Program Files directory. In Win7 is readonly for normal users.
You could move the file in the ProgramData directory.
Your installer should create a directory for your application there.
Then inside your code you could retrieve the correct full pathname using these lines of code
string dataPath = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData));
string appFile = Path.Combine(dataPath, "MyAppDir", "MyFile.txt");
usually (on Win7) this result in a path like this
c:\programdata\MyAppDir\MyFile.txt
but using the SpecialFolder enum you are guaranteed to use a folder available in readwrite to your application not depending on the current operating system.
The only way to solve this problem is to not write to that folder. You are not allowed to write to that folder by convention, unfortunately, older versions of Windows did not hold you to this.
Instead, you can use Environment.SpecialFolder to help you find where you need to go:
// your application data for just that User running the app
var perUserAppData = Environment.GetFolderPath(
Environment.SpecialFolder.ApplicationData);
// your application data for ALL users running the app
var allUsersAppData = Environment.GetFolderPath(
Environment.SpecialFolder.CommonApplicationData);
// better!
var path = Path.Combine(perUserAppData, #"MyApp\MyFile.txt");
Basically, Windows 7 is telling you that you're going to have to stop driving on the sidewalks and use the street as was intended.
As a short-term fix, you can use ICACLS to grant write access to the file. Note: NOT the whole directory.
As a longer term fix, you should NOT write to the program directory if you are running as unprivileged users, but instead somewhere like %LOCALAPPDATA% or %APPDATA%.
I've written a Windows Service in C#/VS2008/.NET3.5 that monitors some FTP directories with FileSystemWatchers and moves the files out to another location for processing. I noticed today that it throws errors stating "The parameter is incorrect" soon after the service has started up, but if we wait a few minutes the file gets copied without incident. I saw that the error message is often related to incorrect permissions, but I verified permissions on the directories (target and source) were correct and as I said the file move works just a few minutes later.
Here's a snippet of the code that gets called when the file is finished copying into the FTP directory being monitored:
//found the correct source path
string targetDir = dir.TargetDirectory;
string fileName = Path.GetFileName(e.FullPath);
errorlocation = "move file";
string targetFilePath = Path.Combine(targetDir, fileName);
if (File.Exists(targetFilePath))
{
File.Delete(targetFilePath);
}
File.Move(e.FullPath, Path.Combine(targetDir, fileName));
dir refers to and object with information about the directory the file was being loaded into. e is the FileSystemEventArgs. Targetdir is grabbed from the directory's settings in a custom configuration block in the app.config that tells the service where to copy the new files to.
I didn't include the code here, but I know it's failing on the File.Move (last line above) due to some EventLog entries I made to trace the steps.
Any idea as to why the move fails soon after the service startup, but works fine later?
Basic overview of the process in case it sheds some light: external vendors FTP us a number of files each day. When the file comes in, my code identifies who the file is coming from based off the FTP directory and then loads settings to pass on to SSIS jobs that will parse and save the files. There are maybe a dozen or so directories being monitored right now each of which has its own configuration setting for the SSIS job. Is it possible that the system gets confused as startup and just need some time to populate all the settings? Each source directory does have its own FileSystemWatcher on it.
Thanks for your help.
The first question I'd answer is, what are the values of these when it fails:
e.FullPath
targetDir
fileName
chances are one of those values isn't what you expect
I'm marking this answered because the problem went away. We haven't changed anything in the code, but it now works immediately after restart. The best theory we have is: since I posted this, the client I was working for moved offices and as part of the migration a lot of system and network policies were updated and server setting tweaked for the new environment. It's likely one (or more) of those changes fixed this issue.
Further support for this theory: prior to the move my development VM could not run web browsers. (I'd click to load the browser and it wouldn't work, sometimes it would appear briefly in Task Manager and then disappear.) After the office move, this problem no longer occurs.
So it was likely some network setting somewhere that caused issues. Sorry I can't be more specific.
How can I get the path of a file on my computer or on the local area network.
I would to show a window that allows me to browse the file system when I click a button, and I want to select a file and get the path to the file. How can I do this?
P.S. I'm not looking to upload the file; I just want to get the path.
The web application is running on the server, and you don't have access to the client file system at all. Can you imagine how much of a vulnerability that would be? I know I don't want the sites I visit inspecting my file system...
EDIT: Question is for a WinForms application
For a WinForms application, you can use the OpenFileDialog, and extract the path with something like this:
If you're looking for the file path:
string path = OpenFileDialog1.FileName; //output = c:\folder\file.txt
If you're looking for the directory path:
string path = Path.GetDirectoryName(OpenFileDialog1.FileName); //output = c:\folder
In general, the System.IO.Path class has a lot of useful features for retrieving and manipulating path information.
To do this in VB.NET use the FolderBrowserDialog.
Due to security restrictions browsers include for user safety, you can't manipulate the client file system directly. You can only use to let them pick a file, and even then it only sends the filename, not the whole path.
The FileSystem API in HTML5 allows for file manipulation, but only within a sandbox for your site specifically, not browsing across the network or other files on the client system.
Instead, provide your users easy steps on how they should use My Computer (or whatever equivalent on other OS's) to navigate to the file and copy & paste the path into a simple text input box.
Have you taken a look at the Path class from System.IO ?