tags:

views:

284

answers:

3

Hey,

I have an C# application that needs to list a directory ( Directory.GetFiles() ) and also to access one of the files returned. If I run the application locally it doesnt have problem access the network location or the local locations, if I run it from a network share then I get a security exception thrown when accessing the shares.

I found out why this is happening: http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx

However the solutions seem... impractical unless I am misunderstanding it.

1) I can not use the code ( hardly an option ) 2) Sign the assemblies and then have whoever is going to use it configure .NET policies to allow it? ( This relies on the person whos going to use it to change one of their policies which I have no say in ??) 3) Change the policy to allow full trust for everything on localintranet ( Not recommended or even possible in my case )

Am I missing something here, none of those choices seem optimal for a stand alone application being pushed onto a network I have no say in. I would have thought doing something as relatively simple as running an application from a network share to list files in a directory wouldnt have required such crazy hoops to jump through to make it work.

Anyone have any thoughts on what I could do in this situation?

+4  A: 

These threads will answer you question, I think:

This behaviour is changed in .NET Framework 3.5 SP1, where it defaults to allowing programs running off network shares.

And yes, it does not feel very practical, but there is unfortunately not much to do about that...

Fredrik Mörk
Duplicate links should be posted as comments/when voted to close.
Noldorin
Good point; will act on it :)
Fredrik Mörk
+3  A: 

I would deploy it as a ClickOnce app ("Publish" in VS2008 etc). ClickOnce can be located on a network share - you just run the .application instead of the .exe; this then works with none of the security issues with running it directly, and it'll work all the way back to .NET 2.0.

Marc Gravell
+1  A: 

This problem should no longer exists when you require your users to upgrade to .NET Framework 3.5 SP1. See the following blog article on that topic:

.NET Framework 3.5 SP1 Allows managed code to be launched from a network share!

0xA3