My musings about .NET and what not

The Project Location Is Not Trusted (When It Really Is)

This warning ("The project location is not trusted") may crop up in Visual Studio when attempting to add an existing project to a solution. Normally, this happens when the project is on a UNC path. But what if the project isn't on a UNC path or in a mapped network folder, and you're still getting this error? Here's the most likely cause, and how to fix it.

In the process of tech-editing the upcoming ASP.NET 3.5 Website Programming: Problem - Design - Solution, I have been downloading code versions from .zip files located on the author's website. For various reasons, he has been developing this as a web application. This means I need to create the solution on my end, extract the projects from his .zip files, and add those projects to my solution.

As I've been doing so, I kept getting the following error dialog:

The project location is not trusted. Running the application may result in security exceptions when it attempts to perform actions which require full trust.

According to MSDN, this error appears when the project is located on a UNC share or in a mapped network folder, neither of which are trusted locations of course. But as you can clearly see in this case, the project is located in a local folder on my C:\ drive, which obviously should have FullTrust permission. What gives?

Of course I happily ignored these little warnings at first and went on my merry way, until I faintly remembered about reading something years ago about zone blocking in Windows XP. I wouldn't say a light bulb went off over my head -- it was really more like a dimly-flickering neon tube with a noisy ballast -- but upon checking the downloaded .zip files, there it was:

It was then I remembered that Windows XP sometimes places downloaded .zip files in partial trust. Isn't it nice to know that Microsoft is looking out for us like this? ;)

Clicking the "Unblock" button places the contents of the .zip file in full trust. After doing this, I deleted the files I had previously unzipped and extracted them once again from the unblocked .zip files. I was then able to add the downloaded projects to my solution without any issues.

Hopefully, this will save some of you from wondering how your C:\ drive ended up on a UNC share. ;)

Subscribe to this blog for more cool content like this!

kick it on DotNetKicks.com

shout it on DotNetShoutOut.com

vote it on WebDevVote.com

Bookmark / Share

    » Similar Posts

    1. Integrating Exception Handling Into the Development Cycle
    2. Defensive Programming, or Why Exception Handling Is Like Car Insurance
    3. Books I Wish Would Just Come Out Already

    » Trackbacks & Pingbacks

    1. You've been kicked (a good thing) - Trackback from DotNetKicks.com

      The Project Location is Not Trusted (When It Really Is) — December 7, 2008 7:35 PM
    2. Installing BlogEngine.Net

      Installing BlogEngine.Net — March 29, 2010 3:09 PM
    3. Installing BlogEngine.Net

      Installing BlogEngine.Net — April 23, 2010 10:24 AM
    Trackback link for this post:
    http://leedumond.com/trackback.ashx?id=30

    » Comments

    1. Bruce Williamson avatar

      Simply brilliant. Well done.

      Bruce Williamson — February 11, 2009 2:05 PM
    2. Andy avatar

      Thanks! I've been trying to work out what causes this.

      Andy — March 26, 2009 8:39 AM
    3. Tom avatar

      Thanks for posting this solution. This was driving me nuts.

      Tom — April 5, 2009 4:58 PM
    4. Brian Keller avatar

      Nice! This fixed a problem I was having, too. Thanks Lee.

      Brian Keller — May 3, 2009 9:51 AM
    5. José Oviedo avatar

      Thank you!!!

      José Oviedo — July 25, 2009 12:24 PM
    6. B7 avatar

      Thanks! I discovered that you just need to unblock the sln and proj files.

      B7 — August 27, 2010 3:45 PM
    7. ColonelFazackerley avatar

      Thanks, that saved me a lot of frustration. Marvelous anti-feature from MS.

      ColonelFazackerley — November 2, 2010 3:29 PM

    » Leave a Comment