All of our Windows shared servers support various versions of the .NET Framework and .NET Core. The lists below detail every installed runtime, from legacy .NET Framework 2.0 required by older line-of-business applications to the newest .NET 9 and 10 Preview builds that deliver substantial gains in throughput, lower memory consumption, and modern language features.

Keeping multiple versions available lets you host both greenfield projects and long-lived maintenance applications on the same server without forcing framework upgrades that could break existing code. It also ensures you can stay current with security patches Microsoft releases for each supported branch.

#.NET Framework Versions

The following versions of the .NET Framework are installed and available on all Windows shared servers. These are the full CLR-based releases that power traditional ASP.NET Web Forms, MVC, and Web API applications running under classic IIS application pools.

  • 2.0 3.0 3.5 4.0 4.5 4.5.1 4.5.2 4.6 4.6.1 4.6.2 4.7 4.7.1 4.7.2 4.8

#.NET Core and Successor Versions

Support for the modern .NET stack (formerly called .NET Core and now simply .NET) includes these runtimes. Applications targeting these versions are typically published as framework-dependent deployments so they can use the pre-installed shared frameworks on the server, reducing deployment size and improving patching.

  • 1.0.16 1.1.13 2.0.9 2.1.30 2.2.8 3.0.3 3.1.32 5.0.17 6.0.36 7.020 8.0.14 9.0.3 10.0 (Preview 1)

#Why These Versions Matter

Choosing the right runtime directly affects application security, performance, and long-term maintainability. Older .NET Framework releases such as 2.0 or 3.5 remain necessary for certain third-party enterprise libraries that have not been ported forward. Meanwhile, .NET 6.0 and later deliver compiled AOT options, improved garbage collection, and HTTP/3 support that can cut latency and hosting costs for high-traffic sites.

Running on an unpatched or mismatched version exposes you to known vulnerabilities that Microsoft has already addressed in newer releases. Conversely, jumping to a brand-new preview build without testing can introduce breaking changes in dependency resolution or behavior. Aligning your local development target framework with the hosting environment eliminates the majority of deployment surprises.

#Configuring the Target Framework

For ASP.NET applications using the .NET Framework, declare the required version inside web.config so IIS loads the correct CLR. This setting must match one of the installed frameworks listed above or the application will fail to start.

xml 
<system.web>
  <compilation targetFramework="4.8" />
  <httpRuntime targetFramework="4.8" />
</system.web>

For .NET 5+ applications the target is declared at build time in the project file. When publishing, prefer framework-dependent mode so the application references the exact runtime version already present on the server rather than bundling a full runtime copy.

#Common Pitfalls

  • Developing locally against a newer SDK than what is installed on the shared server, causing runtime errors on first request
  • Forgetting to update binding redirects or package versions after changing the target framework
  • Using APIs marked obsolete in newer releases without conditional compilation or replacement code paths
  • Deploying self-contained applications that conflict with the server's pre-installed shared frameworks

Test every deployment end-to-end. Review application event logs and enable detailed error pages during initial rollout. Verify the loaded runtime by calling System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription from a test page. If you need clarification on which version best suits a specific library or migration path, our support team can review your project configuration.