Sunday, June 11, 2006

.Net project location is not trusted

this just goes to show how quickly things change in software development - or maybe... how long I've been working on halo books.

I was working on a C# WinForm project and I started to get a strange error when I opened the solution. the error is: "The project location is not trusted. Running the application may result in security exceptions when it attempts to perform actions which require full trust."

it is possible to ignore the error and go about your business, but I was curious so I did some googling. it turns out that this issue is commonly associated with web apps or projects that are run from network drives. my project is a WinForm app on the C: drive, so this didn't help me.

only after searching numerous pages did I find that there is a 'new' feature that applies security permissions downloaded zip files. this triggered some alarm bells because my app does use a sample project that I downloaded.

anyway, the solution is easy. you must unblock the sample code before unzipping. to do this, right-click the Zip files, choose Properties, click UnBlock, click Apply and then unzip.

this is probably common knowledge to those who work with sample code so it's sort of ironic. after all, I used to do that for a living.

15 comments:

Anonymous said...

thanks, that helped me a great deal.

Anonymous said...

This is not common knowledge. When I tried to google "project location is not trusted", and I got lots of hits regarding network drives, trusted sites, using caspool, etc. Microsoft's MDSN suggestion solution to this problem doesn't even mention unblocking zip files. It's such a simple solution, but how are we supposed to know the true cause of the underlying error and what to do about it? Thank you so much for posting this message, it saved me a lot of trouble.

Stephen Cawood said...

thanks for the comments. I am trying to post more messages like this one.

Anonymous said...

I found the problem to be nothing to do with trust issues whatsoever.

The problem for me is that my machine had been rebuilt and I was using solution files that had been created on my old machine when this error occurred.

To resolve the issue, just create new solution files and add your web projects into them. That simple!

I think it's a visual studio bug somewhere.

Anonymous said...

Thanks for the succinct & helpful post. Best and most direct post I could find on Google.

Stephen Cawood said...

de nada.
glad to help.

Anonymous said...

Thanks Stephen Cawood!. Your Tip really helped me. Thanks a lot.

-Clyde Rozario

Anonymous said...

Well, as many others have said before: thank you! To the point clue, helped save a lot of hours!

Anonymous said...

Thank you SO much! I'm with Mike on this one. Everything I found was about UNCs. Again, thanks!

Anonymous said...

Thanks for the tip.
that helped me

Anonymous said...

Yes this tip saved me a lot of google search time as well. Thx

Anonymous said...

Thank you very much. Such a great help to an annoying issue.

Anonymous said...

nice one, this information should be on the MSDN page about this message.

thanks!

Anonymous said...

If you've already opened the zip file and don't want to lose any changes you've made to files that came from it, you can go to the individual files and unblock them. Of course, if that's a ton of files, it might be easier to simply save your changes and delete the directory, then unblock the zip file, and restore your changes.

ken said...

Holy heck, you rock. I felt like I was going crazy. This "feature" really is annoying. I guess it's suppoed to save us from the crazy "coders" that download a bunch of code, spaghetti it together, and create a pile of junk.