Resolving 'The Project Location Is Not Trusted' in Visual Studio for Network Shares

When you open a Visual Studio solution or project that resides on a network share (UNC path like \\server\share\MyProject), you may encounter a dialog box that says:

The Project Location is Not Trusted

Running the project may harm your computer. The location the project is being run from is not trusted. Running from this location may put your computer at risk.

This dialog appears because of the .NET Framework’s Code Access Seguridad (CAS) system, which restricts what code is allowed to do based on where it was loaded from. This article explains why it happens, how to resolve it, and what has changed in modern versions of .NET.

Understanding Code Access Seguridad (CAS)

The .NET Framework (versions 1.0 through 3.5) uses CAS to control the permissions granted to managed code based on evidence such as the code’s origin. The runtime defines several built-in code groups and zones:

Zone	Description	Default Permission Set
MyComputer	Code on the local machine	FullTrust
LocalIntranet	Code from network shares (UNC paths)	LocalIntranet (restricted)
Internet	Code downloaded from the internet	Internet (very restricted)
Trusted	Explicitly trusted sites	Internet
Untrusted	Explicitly untrusted sites	Nothing

Code loaded from a local drive (C:\Projects\MyApp) falls into the MyComputer zone and runs with FullTrust, meaning it can do anything. Code loaded from a UNC path (\\server\Projects\MyApp) falls into the LocalIntranet zone, which restricts operations like:

• File I/O outside the share itself
• Registry access
• Reflection on private members
• Unmanaged code interop (P/Invoke)
• Network connections to hosts other than the origin server

Visual Studio detects that the project is in the LocalIntranet zone and shows the warning because your code, designer-generated code, and build outputs may not function correctly under restricted permissions.

Solución 1: Grant FullTrust Using caspol.exe

The caspol.exe (Code Access Seguridad Policy) tool lets you modify the CAS policy to grant FullTrust to a specific UNC path. This is the most targeted and recommended approach for .NET 2.0/3.5 projects.

Trusting a Specific Share

Open a Visual Studio Command Prompt (run as Administrator) and execute:

caspol -m -ag 1.2 -url "file://\\server/share/*" FullTrust -n "MyTrustedShare"

Breaking down the arguments:

• -m — modify the machine-level policy (affects all users on this computer)
• -ag 1.2 — add a code group under the LocalIntranet zone (code group 1.2)
• -url "file://\\server/share/*" — membership condition: any code from this UNC path
• FullTrust — the permission set to grant
• -n "MyTrustedShare" — a friendly name for the code group

To trust an entire server:

caspol -m -ag 1.2 -url "file://\\server/*" FullTrust -n "TrustedFileServer"

Verifying the Policy Change

List the current machine-level code groups to confirm your change:

caspol -m -lg

You should see your new code group nested under the LocalIntranet group:

1.2.  Zone - LocalIntranet: LocalIntranet
  1.2.1.  All code: Same site Web
  1.2.2.  All code: Same directory FileIO
  1.2.3.  Url - file://\\server/share/*: FullTrust  (MyTrustedShare)

Removing the Policy Later

If you need to undo the change:

caspol -m -rg "MyTrustedShare"

Framework Version Matters

Each .NET Framework version has its own caspol.exe. Make sure you run the one that matches your project’s target framework:

# .NET 2.0/3.0/3.5 (all share the 2.0 runtime)
C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe

# .NET 4.0+
C:\Windows\Microsoft.NET\Framework\v4.0.30319\caspol.exe

On 64-bit systems, there are separate copies under Framework64 as well. Modify both if you build for both architectures.

Solución 2: Use the .NET Framework Configuración Tool

For those who prefer a graphical interface, the .NET Framework Configuración tool (mscorcfg.msc) provides a way to manage CAS policy:

1. Open Control Panel > Administrative Tools > Microsoft .NET Framework Configuración
2. Expand Runtime Seguridad Policy > Machine > Code Groups > All_Code > LocalIntranet_Zone
3. Right-click and select New to create a new child code group
4. Give it a name like “Trusted File Server”
5. Choose URL as the membership condition type
6. Enter file://\\server/share/*
7. Select FullTrust as the permission set
8. Finish the wizard

This tool is available in .NET 2.0 and 3.5 but was removed in .NET 4.0 since CAS policy enforcement was deprecated.

Solución 3: Map the Network Share to a Drive Letter

A simpler workaround is to map the UNC path to a drive letter. Windows treats mapped drives as part of the MyComputer zone, so the code runs with FullTrust automatically.

net use Z: \\server\share /persistent:yes

Then open the project from Z:\MyProject\MyProject.sln instead of \\server\share\MyProject\MyProject.sln.

Caveats:

• Drive mappings are per-user and per-session (though /persistent:yes restores them at logon)
• Some build tools and MSBuild resolve paths differently when a mapped drive is involved
• If you commit the .sln or .csproj files with the drive letter path, other developers who use a different drive letter will have issues

Solución 4: Configure Internet Explorer Seguridad Zones

The .NET Framework uses the same zone classification as Internet Explorer. You can add your server to the Local Intranet or Trusted Sites zone to influence how CAS classifies code from that location.

1. Open Internet Options (from Control Panel or IE)
2. Go to the Seguridad tab
3. Select Local Intranet and click Sites
4. Click Advanced
5. Add file://server (replace “server” with your file server name)
6. Click Close, then OK

While this does not directly grant FullTrust, it ensures the .NET runtime correctly identifies the share as intranet rather than internet, which provides a less restrictive base permission set.

Solución 5: Group Policy Deployment for Teams

For organizations with many developers, manually configuring each machine is not practical. You can deploy CAS policy via Group Policy:

Option A: Logon Script

Create a batch file and assign it as a Group Policy logon script:

@echo off
REM Grant FullTrust to the development file server
"%WINDIR%\Microsoft.NET\Framework\v2.0.50727\caspol.exe" -q -m -ag 1.2 -url "file://\\devserver/*" FullTrust -n "DevServer"
"%WINDIR%\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -q -m -ag 1.2 -url "file://\\devserver/*" FullTrust -n "DevServer"

The -q flag suppresses the confirmation prompt.

Option B: Distribute security.config

The CAS policy is stored in XML files at:

%WINDIR%\Microsoft.NET\Framework\v2.0.50727\CONFIG\security.config
%WINDIR%\Microsoft.NET\Framework64\v2.0.50727\CONFIG\security.config

You can configure one machine correctly, then copy its security.config to other machines via Group Policy file distribution.

Modern .NET: Why This Is No Longer an Issue

Starting with .NET Framework 4.0, CAS policy is no longer enforced by default. The <NetFx40_LegacySeguridadPolicy> runtime setting exists to re-enable it, but by default all managed code runs with FullTrust regardless of its origin.

This means:

• Visual Studio 2010+ targeting .NET 4.0+ will not show the “Project Location is Not Trusted” warning
• Visual Studio 2010+ targeting .NET 2.0/3.5 may still show the warning, because the v2.0 runtime is used
• .NET Core and .NET 5+ do not have CAS at all

If you are still encountering this issue, the most permanent solution is to update your project to target .NET 4.0 or later, if your dependencies allow it.

<!-- In your .csproj file, change the target framework -->
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>

Recommended Modern Approach

Rather than fighting CAS policy, consider these modern alternatives for shared development:

• Use Git with a remote repository (GitHub, Azure DevOps, GitLab) instead of sharing project files on a network drive. Each developer clones locally, and code always runs from the MyComputer zone.
• Use a CI/CD server for builds rather than building from a network share. This is faster and eliminates trust issues.
• If you must use a network share, map it to a drive letter or upgrade to .NET 4.0+ to avoid CAS restrictions entirely.

Resumen

The “Project Location is Not Trusted” dialog is caused by .NET Code Access Seguridad treating network shares as less trustworthy than local drives. For legacy projects targeting .NET 2.0/3.5, you can resolve it by using caspol.exe to grant FullTrust to specific UNC paths, mapping the share to a drive letter, or configuring security zones. For new development, targeting .NET 4.0+ eliminates the issue entirely since CAS policy enforcement is disabled by default.