Can't get process.start() to work with UNC path on customer's domain

From a winforms app, I am trying to open a document stored on a shared drive accessed by UNC. It works fine on my network, but fails on my client's network. If I check to make sure the file exists, it says it does, but when I try to open it I get an error message saying

System.ComponentModel.Win32Exception: The system cannot find the file specified at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)

Here's the c开发者_运维百科ode...

// path = "\\server\folder with spaces\"
// fileName = "test.txt"

if (!System.IO.File.Exists(path + fileName)) {
  MessageBox.Show("The file " + fileName + " cannot be found.", "Remove File", MessageBoxButtons.OK, MessageBoxIcon.Warning);
}
else
{
  System.Diagnostics.Process myProcess = new System.Diagnostics.Process();
  myProcess.StartInfo.FileName = path + fileName;
  myProcess.Start();    // FAILS HERE WITH 'SYSTEM CANNOT FIND THE FILE SPECIFIED' ERROR ON CUSTOMER'S NETWORK, WORKS FINE ON MY NETWORK
}

I have tried every combination of StartInfo options I can think of, and can't figure out why it finds the file with the System.IO.File.Exists(), but fails to find it on the process.Start();

Any suggestions?

So, trying to access the file using a UNC path failed. Switching it to use a mapped path worked. I kinda hate doing it that way, but the mapping is part of the corporate environment so I don't think it will be changing any time soon.

I'm not sure if this falls into what you're seeing, but check this out for trusting a share. Relevant information:

Since network shares by default only get LocalIntranet permissions, it's relatively common to want to use CasPol to fully trust some shares that you control and know are safe. However, CasPol syntax being what it is, the command to do this isn't immediately obvious. If I wanted to trust everything on the share \ShawnFa-Srv\Tools, the command:

CasPol.exe -m -ag 1.2 -url file://\ShawnFa-Srv/Tools/* FullTrust

Would setup the policy to do what I needed. Lets break down this command:

-m - modify the machine level of the policy. This is needed, since the machine level is where all of the default policy lives. On NT platforms it's also the default level that CasPol works with, however on Win9x, CasPol will default to the user level, so putting -m in the command line explicitly tells CasPol to use the correct level.

-ag 1.2 - add a code group under group 1.2. In the default policy, group 1.2 is the LocalIntranet group, so the new code group that we're creating will only be checked if the file comes from the intranet.

-url file://\ShawnFa-Srv/Tools/* - The membership condition for the new code group should be a UrlMembershipCondition, and it should match anything with a URL that starts with file://ShawnFa-Srv/Tools, meaning that any file on the \ShawnFa-Srv\Tools share will match this code group.

FullTrust - The permission set to grant assemblies that match the code group. In this case, FullTrust.

Note that .NET 3.5 SP1 fixed this. This is only supposed to be for .NET executables running from a share, but might not hurt seeing if this helps your situation. Vance Morrison states:

So I do encourage you to down load the .NET 3.5 SP1 service pack. It is a very low risk, drop-in update for the runtime. Once you do this, you get network launch for free. Because it is a service pack, you can also simply just wait, and get the update automatically in the next several weeks via windows update. Thus if you are software deployer, pretty soon now, with high probability your customers will have this newer runtime.