Yes, our Windows services support (and only support) ASP.NET full trust mode. Full trust is enabled by default; nothing needs to be done on your end or ours. Just create your website, set your ASP.NET version and you are ready to go!

Full trust removes the limitations of Code Access Security (CAS) sandboxes that frequently cause SecurityException errors in medium-trust environments. Applications can freely perform file operations outside their virtual root, access the registry, load assemblies dynamically via reflection, call unmanaged code, and use most third-party controls without modification. This matches the behavior you see when running locally in Visual Studio under full trust.

#Understanding ASP.NET Trust Levels

The .NET Framework uses Code Access Security to grant or deny permissions based on configurable trust levels. These levels are defined in policy files within the Framework installation directory and are enforced by the ASP.NET runtime. Lower trust levels isolate sites on shared servers but also disable functionality required by many production applications. Full trust bypasses these checks entirely, giving your managed code the same rights it would have in a desktop application.

  • Full Trust: No CAS restrictions. Complete access to resources the Windows account itself can reach.
  • Medium Trust: Restricts file I/O to the application directory tree, blocks registry and event log access, prevents most reflection and unmanaged code calls.
  • High, Low, and Minimal Trust: Intermediate permission sets used less frequently; most commercial components assume full trust.

#Our Full Trust Only Policy

We run every site under full trust because the majority of modern ASP.NET applications and libraries are written with unrestricted permissions in mind. Enforcing medium trust would break legitimate scenarios involving reporting engines, PDF libraries, dynamic compilation, COM interop, and custom data providers. By standardizing on full trust we eliminate an entire category of support tickets while giving you a hosting environment that behaves like your local development machine.

#Deploying Your Application

Deployment requires no trust-specific changes. Follow the normal process and the site will automatically run with full permissions. Verify the following steps in the control panel.

  • Create or select the website entry and bind your domain.
  • Set the ASP.NET version to match your compiled target framework (2.0, 4.0, 4.8, etc.).
  • Upload files through FTP, ensuring bin directory contains all referenced assemblies.
xml 
<configuration>
  <system.web>
    <!-- Trust level is Full by default; do not set to Medium -->
    <compilation targetFramework="4.8" />
    <httpRuntime targetFramework="4.8" />
  </system.web>
</configuration>

#Common Use Cases and Pitfalls

Full trust is required for registry reads, writing outside the web root, DirectoryServices queries, certain encryption APIs, and many legacy components. If your code throws permission exceptions locally under medium trust but works on our servers, that confirms the need for full trust. Avoid adding an explicit <trust level="Full" /> element unless your application demands it for local testing consistency; the server policy already enforces it. Should you see unexpected access-denied errors, they almost always stem from NTFS permissions or application pool identity rather than CAS trust level.

With full trust active by default you can focus on application logic instead of permission workarounds. Upload your site, set the correct .NET version, and test. Consult our control panel guide for changing ASP.NET versions if your project targets a specific framework release.