tags:

views:

95

answers:

8

I have an application that writes to a folder on the C:\ drive. The program works fine on my computer, but on another laptop when running the .exe (The other laptop has no visual studio etc.), i get a filenotfoundexception and i cannot pinpoint the line of code where this happens from the error report.

Here is the code for creating the directory (assuming this is the issue)

        try
        {
            WriteDirectory = new DirectoryInfo(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) + @"\SMS Notifier\");
            if (!WriteDirectory.Exists)
                WriteDirectory.Create();
        }
        catch (Exception e)
        {
            throw e;
        }

Any ideas what the problem could be? Should i check for write permission ?!

Help greatly appreciated!

+1  A: 

Does this path exists on the Laptop?

Environment.SpecialFolder.ApplicationData

Do a debug.writeline on this line like a messagebox.show and see what the path is? Also if the path exists it may be a permissions issue..most likely

chugh97
Don't think it would matter whether or not Special Folder exists as the check for it would "WriteDirectory.Exists" would cover that. The problem is a permission issue trying to write to the C drive.
James
Yes, agreed there is a permissions problem but this could well be due to trying to create the folder in the wrong place, so it is worth checking that the path is the intended one
Calanus
+1  A: 

First thing I might do (for debugging purposes) is to insert a

MessageBox.Show(WriteDirectory.FullName);

before you try and create the directory just to see if that "Special" path is what you think it is!

Calanus
+1  A: 

Using throw; rather than throw e; will preserve the original stack trace in the exception.

Putting a Console.WriteLine(e.ToString()); (or a MessageBox equivalent) in the catch block will output the stack trace then and there (you will want a debug build for most information).

If all else fails, the old standard of trace statements Console.WriteLine("about to do x"); will help -- with the app launched from a command line.

Steve Gilham
+5  A: 

If you deploy the .pdb files along with your .dlls, you will get line numbers in the exception messages!

Your try..catch block isn't doing anything useful, all it is doing is swallowing the stack trace so you cannot see what is going on! I'd suggest removing the try..catch block entirely.

throw e; causes the stack trace to be lost, use throw; to preserve it.

Also you should use System.IO.Path.Combine() to append the directory root and the sub-directory name, that way you don't have to worry about doing the \'s yourself and possibly making a mistake.

Matt Howells
A: 

You should probably check the user has permissions firstly before attempting to write to the C drive. Or within your catch on attempting to write, try to retrieve permissions and re-try then throw the exception if it fails again.

James
A: 

Is .Net framework installed on the laptop ?

other possibility : the plateform doesn't support this directory. Check compatible plateforms on msdn

rockeye
.net framework is installed and it creates the directory folder successfully. It then seems to be unable to write to it....but ive unchecked the read only box on the folder!?
Goober
+2  A: 

My guess is that this isn't the real issue; neither DirectoryInfo.Create nor Directory.CreateDirectory throw a FileNotFoundException.

Best bet is to build the app for debug, then copy the file along with all it's .pdb files; hopefully this'll give you the methods and line numbers in your error message.

You might also consider adding a handler for any unhandled exception; the AppDomain.UnhandledException can be handled so that you can add your own event handler for any unhandled exception running anywhere in the app;

Add something like this to your Main function;

 System.AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);

And then write your own handler for the error;

static void MyHandler(object sender, UnhandledExceptionEventArgs args) {
   Exception e = (Exception) args.ExceptionObject;
   Console.WriteLine("MyHandler caught : " + e.Message);
}
Steve Cooper
A: 

Turned out to be something different.........

Goober
what was it then?
chugh97