Program runs fine on my computer, won't run on end user computers

[Guest]

I've got an application that I've written in C# that reads and writes to the
filesystem. On the computer I developed the application on, everything works
properly. If I try to run it on another computer that has the .NET 2.0
framework installed but not the SDK, it throws a
system.io.filenotfoundexception the moment it tries to access the filesystem,
even though it does a File.Exists() check before every access.

I've talked to some friends who are professional .NET developers, and they
suspect it's related to Code Access Permissions, but I can't figure out how
I'm supposed to get this assembly trusted on a user's computer when I don't
have mscorcfg.msc or caspol.exe. I'm not going to install the SDK on every
computer that uses the application, and the application is useless without
filesystem access. What should I do?

 

[Chris R. Timmons]

"=?Utf-8?B?RG91ZyBTdHJlaWZlbA==?=" <Doug
(e-mail address removed)> wrote in

I've got an application that I've written in C# that reads and
writes to the filesystem. On the computer I developed the
application on, everything works properly. If I try to run it
on another computer that has the .NET 2.0 framework installed
but not the SDK, it throws a system.io.filenotfoundexception the
moment it tries to access the filesystem, even though it does a
File.Exists() check before every access.

I've talked to some friends who are professional .NET
developers, and they suspect it's related to Code Access
Permissions, but I can't figure out how I'm supposed to get this
assembly trusted on a user's computer when I don't have
mscorcfg.msc or caspol.exe. I'm not going to install the SDK on
every computer that uses the application, and the application is
useless without filesystem access. What should I do?

Doug,

From what you've described, I would agree with those other .Net developers.

Code Access Security (CAS) is one of the seemingly mysterious aspects of
..Net. In reality, it's not that hard once you get the hang of it.

This MSDN TV video gives a very good grounding in what CAS is and how it
works. It's only about 13 minutes long, and the examples in the program
use file system permissions to explain CAS:

http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20040212securityml/manifest.xml

 

[Nicole Calinoiu]

I've got an application that I've written in C# that reads and writes to
the
filesystem. On the computer I developed the application on, everything
works
properly. If I try to run it on another computer that has the .NET 2.0
framework installed but not the SDK, it throws a
system.io.filenotfoundexception the moment it tries to access the
filesystem,
even though it does a File.Exists() check before every access.

File.Exists should return false your application lacks CAS permissions to
access the file location, so the problem seems may not be purely
CAS-related. Might you be able to post a code extract (incl. the
File.Exists call) that shows how you are attempt to access the files? Also,
could you please post the full exception details (incl. call stack listing),
as returned from its ToString method?

I've talked to some friends who are professional .NET developers, and they
suspect it's related to Code Access Permissions, but I can't figure out
how
I'm supposed to get this assembly trusted on a user's computer when I
don't
have mscorcfg.msc or caspol.exe.

Caspol.exe is installed with the core framework, and it should be present on
all the client machines. It's only the mscorcfg.msc UI that comes only in
the SDK.

I'm not going to install the SDK on every
computer that uses the application, and the application is useless without
filesystem access. What should I do?

First, let's make sure that the problem really is related to CAS. If it is,
you might want to consider deploying it as a ClickOnce application, if
appropriate. If not, it is quite possible to modify CAS policy on machines
that do not have the SDK installed, but you might want to hold off on
worrying about that for now since it might not be necessary.