none
Running an x86 app written in C# 2008 from a network drive fails RRS feed

  • Question

  • I have written a program in C# and compiled it for x86 because it uses Access 2007 drivers.  It uses the .Net Framework 3.5.  It installs fine on the network drive, but when we double-click it, we get a wait cursor for several seconds, then nothing.  No error message, no crash, nothing.  When I install it on a local drive on the same machine, it runs fine.  To the best of our knowledge, the user has full rights to run programs from the network drive.  All the appropriate DLLs are in the folder into which we installed it, and all files are present.  I have run Caspol to give full trust to this drive/directory.  This is not a click-once install; obviously I had to create a deployment package.
    Alpha Geek
    Wednesday, May 20, 2009 6:12 PM

Answers

All replies

  • That should IMO just work. Try to run your application from network under debugger and see what is happening. It will be probably something specific to your application.

    -Karel
    Wednesday, May 20, 2009 9:13 PM
    Moderator
  • I am confused when you say: "I install it on the same machine and run it locally"....

    Can you remote into the box and run the application locally from the other code?
    William Wegerson (www.OmegaCoder.Com )
    Wednesday, May 20, 2009 10:07 PM
    Moderator
  • Karel, I figured it would just work too.  The DLLs and such are in the directory on the network volume.  I'm not allowed to install development tools on a user's machine, so I can't do as you suggest.  I get no error message, nothing.

    OmegaMan, I'm running the app on the same machine.  What matters is whether I try to run it from a network drive/directory or a local one.  It doesn't work in the former case, and does work in the latter.  Even with the program installed on the C: drive, it still will not run from the O: drive.  It must be a permissions issue, but I cannot figure out what.

    Thanks.  John
    Alpha Geek
    Thursday, May 21, 2009 1:39 AM
  • Use windbg debugger - it can run without installation, e.g. from a network. Or try to reproduce the same error on your testing machine(s). Hyper-V or other virtual machine manager might help you here.
    Without debugging there's not much to advice ... you can guess or you can hope that someone who faced this problem before will read your post.

    -Karel

    Thursday, May 21, 2009 1:43 AM
    Moderator
  • Have you got exception handling and logging code in your app? That should help identify where the problem is. e.g. putting a try / catch around your Main() method and adding an Application.ThreadException event handler, and on exception show a message / write to a file or the windows event log or similar.

    - Rory
    Friday, May 22, 2009 6:45 PM
  • You mentioned a dependency on Access 2007, so the first thing to check is if the user actually has MS Office.

    Other things to try/check:
    1) Sometimes, for top-level CLR exceptions, an event is written to the Application Event Log.
    2) Run the Assembly Binding Log Viewer (the managed equivalent of Depends; this is also self-contined, you can just copy it to the user's machine):
      http://msdn.microsoft.com/en-us/e74a18c4(vs.80).aspx

            -Steve

    P.S. I am looking forward to this day:
      http://blogs.msdn.com/shawnfa/archive/2009/05/21/security-policy-in-the-v4-clr.aspx
    Programming blog: http://nitoprograms.blogspot.com/
    I will be in Chicago for the WPF training: http://blogs.msdn.com/jaimer/archive/2009/04/01/announcing-the-using-wpf-to-build-lob-applications-training-tour.aspx
    • Marked as answer by Zhi-Xin Ye Wednesday, May 27, 2009 12:12 PM
    Friday, May 22, 2009 8:04 PM