Restrictions for ASP.NET Applications

For Windows Web Hosting packages

To guarantee maximum availability for all our customers and to protect our systems from overload, it is necessary to define a trust level for ASP.NET applications. This limits certain features of the .NET Framework.

For example, no ASP.NET application may access the registry or access files outside its own application directory. The execution of unmanaged code (code that is not managed by the.NET framework and, for example, performs its own memory management) is also not permitted.
By using your own trust level, it is not possible to open an Access database via ODBC or OLEDB because these procedures still contain the aforementioned unmanaged code. If you want to run ASP.NET applications with a database, use the SQL Server from Microsoft. Additionally, it is necessary to use the corresponding classes of the .NET framework (System.Data.SqlClient). We provide in IONOS the possibility of importing Access databases into the SQL server,
The further limitations of the trust level used play a minor role for the majority of all ASP.NET applications. This includes the unavailability of IsolatedStorage and the locking of environment variables of the system. Tracing or server-side debugging of ASP.NET applications is also not permitted for security and performance reasons. Backend services such as MessageQueues, DirectoryServices, Printing or PerformanceCounter, which do not exist anyway or cannot be accessed, are also not accessible via ASP.NET applications.

Here is a list of the restrictions for a better overview:

IsolatedStorage: Use of the.NET Isolated Storage.
Printing: Using a local printer.
Security.RemotingConfiguration: Use of.NET Remoting for communication with other services.
Registry: Using the Registry.
Environment: Read environment variables.
Socket: Opening network sockets.
EventLog: Write/read the system event log.
ODBC/OleDB/Oracle: Use of corresponding databases.
PerformanceCounter: Read/write system performance counters.