ASP.NET and IIS

ASP.NET remains a strong platform for building business-critical web applications, APIs, portals, internal systems, and enterprise software. When it is paired with IIS (Internet Information Services), teams get a mature Windows hosting stack with deep Microsoft ecosystem integration, proven deployment patterns, and strong operational controls.

However, ASP.NET applications only perform well when the hosting environment, web.config, security settings, application pools, deployment process, and monitoring are designed properly. This guide explains how ASP.NET, web.config, and IIS work together, what businesses should watch for, and how Eight Mile can help build, modernise, host, migrate, and support ASP.NET systems.

What is ASP.NET?

ASP.NET is Microsoft’s web application framework for building dynamic websites, APIs, and web services. It supports multiple application styles, including MVC applications, Razor Pages, Web API services, Blazor applications, and legacy Web Forms systems.

There are two major families businesses commonly encounter:

• ASP.NET Framework: The older Windows-only framework, often used in long-running enterprise applications, Web Forms, MVC 5, and legacy systems hosted on IIS.
• ASP.NET Core: The modern, cross-platform framework for high-performance web applications and APIs. It can run behind IIS on Windows or on Linux using Kestrel, containers, and reverse proxies.

Both can be reliable platforms, but they require different operational approaches. A legacy ASP.NET Framework application may depend heavily on IIS and web.config, while an ASP.NET Core application may use IIS mainly as a reverse proxy in front of the Kestrel web server.

What is IIS?

IIS stands for Internet Information Services. It is Microsoft’s web server for hosting websites, APIs, static assets, application pools, reverse proxy rules, SSL certificates, authentication settings, and request handling pipelines on Windows Server.

In ASP.NET hosting, IIS is responsible for important tasks such as:

• Accepting HTTP and HTTPS requests.
• Managing websites, bindings, hostnames, ports, and SSL certificates.
• Running applications inside isolated application pools.
• Handling authentication, authorisation, compression, caching, logging, and request limits.
• Passing requests to ASP.NET Framework or ASP.NET Core applications.
• Recycling worker processes and controlling runtime behaviour.

For many organisations, IIS is still central to production systems because it fits naturally into Windows Server, Active Directory, Microsoft SQL Server, internal networks, enterprise security policies, and Microsoft-based operations.

How ASP.NET and IIS work together

The relationship between ASP.NET and IIS depends on the application type.

ASP.NET Framework on IIS

Traditional ASP.NET Framework applications run directly through the IIS and ASP.NET pipeline. IIS receives the request, maps it through configured handlers and modules, and executes the application within the selected application pool. Configuration is heavily driven by web.config and IIS settings.

ASP.NET Core on IIS

ASP.NET Core applications usually run using the ASP.NET Core Module in IIS. IIS acts as a front-end web server and reverse proxy, while the application itself runs in Kestrel. This model allows ASP.NET Core to benefit from IIS features such as bindings, certificates, process management, Windows authentication, and request routing.

Understanding web.config

The web.config file is one of the most important configuration files in many ASP.NET and IIS-hosted applications. It is an XML file used to control application behaviour, IIS settings, runtime options, security rules, handlers, modules, connection strings, error handling, redirects, and environment-specific values.

A typical web.config may include:

• Application settings: Feature flags, environment variables, API endpoints, and configuration values.
• Connection strings: Database connection information for SQL Server or other databases.
• System web settings: Compilation, authentication, session state, custom errors, and legacy ASP.NET settings.
• IIS system.webServer settings: Handlers, modules, rewrite rules, compression, request filtering, and static content settings.
• Security controls: Authentication modes, authorisation rules, request limits, headers, and access restrictions.
• Deployment configuration: ASP.NET Core process path, hosting model, environment variables, and logging settings.

Common web.config sections

appSettings

The appSettings section is commonly used for simple key-value settings. It is useful for low-risk configuration values, but sensitive secrets should not be stored in plain text.

connectionStrings

The connectionStrings section defines how the application connects to databases. This area needs careful protection because exposed database credentials can become a major security risk.

system.web

The system.web section controls many ASP.NET Framework behaviours, including authentication, authorisation, compilation, session state, request limits, and error pages.

system.webServer

The system.webServer section controls IIS-level behaviour such as handlers, modules, URL rewrite rules, custom headers, compression, static content, default documents, and request filtering.

aspNetCore

For ASP.NET Core hosted behind IIS, the aspNetCore element tells IIS how to start and manage the application process. It may define the process path, arguments, hosting model, environment variables, and stdout logging.

Why correct configuration matters

Poor configuration can create performance, security, reliability, and deployment problems. A small mistake in web.config can cause downtime, expose sensitive information, disable important headers, break routing, or produce confusing server errors.

Common configuration problems include:

• Plain-text secrets in configuration files.
• Incorrect database connection strings between staging and production.
• Misconfigured authentication and authorisation rules.
• Missing HTTPS redirects or weak TLS settings.
• Overly permissive request filtering.
• Application pool identity permissions that are too broad or too limited.
• Incorrect ASP.NET Core hosting model settings.
• Enabled debug settings in production.
• Unclear custom error handling that leaks technical details.
• URL rewrite rules that create loops or break API routes.

IIS application pools

An IIS application pool isolates one or more applications into a worker process. Application pools help separate workloads, improve security boundaries, control runtime versions, and manage process recycling.

Important application pool settings include:

• .NET CLR version: Required for ASP.NET Framework applications; ASP.NET Core often uses “No Managed Code”.
• Identity: The Windows identity used by the application to access files, network resources, and databases.
• Recycling: Rules for restarting the worker process to manage memory, stability, and deployments.
• Idle timeout: Controls whether the app shuts down after inactivity, which can affect first-request performance.
• Start mode: AlwaysRunning can help reduce cold-start behaviour for important applications.
• Rapid-fail protection: Protects the server when an application repeatedly crashes.

Security best practices for ASP.NET, web.config, and IIS

Security should be designed into the application and the hosting environment together. A secure ASP.NET deployment needs safe code, protected configuration, hardened IIS settings, and controlled access.

• Do not store secrets in plain text: Use secure secret storage, environment variables, encrypted configuration sections, or a managed vault where possible.
• Use least privilege: Application pool identities should only have the permissions they need.
• Force HTTPS: Configure SSL certificates, HTTPS bindings, HSTS, and redirects correctly.
• Protect error pages: Production systems should not expose stack traces, internal paths, or database errors to users.
• Harden headers: Add appropriate security headers such as Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and Strict-Transport-Security.
• Limit request size: Configure request filtering to reduce abuse and protect upload endpoints.
• Patch regularly: Keep Windows Server, IIS, .NET runtimes, dependencies, and application packages updated.
• Separate environments: Development, staging, and production should use separate settings, credentials, databases, and deployment controls.
• Audit access: Review who can edit IIS settings, deploy application files, change certificates, and access production configuration.

Performance and reliability considerations

ASP.NET and IIS can perform extremely well when tuned correctly. Performance problems often come from database bottlenecks, blocking code, poor caching, oversized static assets, slow external APIs, session-state design, memory pressure, or misconfigured application pools.

Useful improvements include:

• Enabling compression for suitable responses.
• Configuring static file caching for images, JavaScript, CSS, and fonts.
• Using asynchronous code for I/O-heavy operations.
• Monitoring database query performance and connection pooling.
• Reviewing application pool recycling to avoid unnecessary interruptions.
• Using health checks and warm-up behaviour for important services.
• Placing load balancers or reverse proxies in front of multiple IIS servers when high availability is required.
• Using structured logging and application performance monitoring.

Deployment and DevOps for ASP.NET on IIS

Manual deployments are risky, especially when configuration files, database migrations, certificates, and IIS settings must stay consistent. Modern ASP.NET delivery should use repeatable deployment pipelines and environment-specific configuration.

A robust deployment approach may include:

• Source control for application code and infrastructure scripts.
• Build pipelines that compile, test, package, and scan the application.
• Release pipelines for staging and production deployments.
• Configuration transforms or environment-specific settings.
• Automated database migration checks.
• Rollback plans for failed releases.
• Blue-green, slot-based, or load-balanced deployments where suitable.
• Infrastructure as code for repeatable IIS, Windows Server, cloud, or hybrid environments.

Monitoring and troubleshooting

When ASP.NET applications fail on IIS, the root cause may sit in application code, IIS configuration, file permissions, certificates, application pool identity, database access, runtime versions, or external dependencies. Good observability reduces diagnosis time.

Useful troubleshooting sources include:

• IIS logs for request status, response codes, timing, and client details.
• Windows Event Viewer for application pool crashes and runtime errors.
• ASP.NET application logs for business and exception details.
• Failed Request Tracing for deep request pipeline diagnostics.
• Performance counters and metrics for CPU, memory, disk, and request queues.
• Database monitoring for slow queries, locks, and connection issues.
• APM tools for distributed tracing and dependency timing.

Modernising legacy ASP.NET applications

Many organisations still run valuable ASP.NET Framework systems that support daily operations. Replacing them outright may be risky, but leaving them untouched can increase security, maintenance, and hiring challenges.

Modernisation can be gradual:

1. Stabilise: Document the current application, dependencies, IIS settings, databases, and deployment process.
2. Secure: Remove exposed secrets, harden IIS, update runtimes, and improve access control.
3. Automate: Replace manual deployments with build and release pipelines.
4. Observe: Add structured logging, metrics, alerts, and error tracking.
5. Refactor: Improve high-risk modules, performance bottlenecks, and brittle integrations.
6. Extract: Move suitable features into APIs, services, background workers, or cloud-native components.
7. Migrate: Where valuable, move from ASP.NET Framework to ASP.NET Core in phases.

Cloud and hybrid hosting options

ASP.NET and IIS workloads can run in several ways depending on requirements, budget, compliance, and architecture.

• On-premises IIS: Suitable for internal systems, legacy dependencies, or tightly controlled environments.
• Windows Server virtual machines: Useful for lift-and-shift migrations, custom IIS setups, and applications not ready for platform services.
• Azure App Service: A managed platform for many ASP.NET and ASP.NET Core applications with simpler scaling and deployment.
• Containers: Useful for standardised deployments, microservices, and cloud portability.
• Hybrid architecture: Combines on-premises systems with cloud APIs, databases, queues, identity, and monitoring.

The right choice depends on the application’s dependencies, traffic, security model, deployment maturity, budget, and long-term roadmap.

How Eight Mile can help

Eight Mile can help organisations with custom software development, web applications, backend APIs, cloud infrastructure, CI/CD, system architecture, technical consultancy, and legacy modernisation. ASP.NET, web.config, and IIS work often sits directly across those service areas.

For ASP.NET and IIS projects, Eight Mile can support:

• ASP.NET application development: Build new web applications, APIs, portals, and internal business tools.
• IIS hosting and configuration: Set up sites, bindings, SSL certificates, application pools, permissions, logging, and operational settings.
• web.config review and hardening: Improve configuration structure, security, environment separation, error handling, redirects, and deployment safety.
• Legacy ASP.NET modernisation: Stabilise older systems, reduce technical debt, improve maintainability, and plan phased migration to ASP.NET Core where appropriate.
• Cloud migration: Move suitable ASP.NET workloads to cloud platforms, Windows Server virtual machines, Azure App Service, containers, or hybrid architectures.
• CI/CD implementation: Automate builds, tests, deployments, configuration transforms, and release approvals.
• Performance optimisation: Investigate slow pages, API latency, memory usage, application pool behaviour, database bottlenecks, and caching opportunities.
• Security improvement: Review secrets, permissions, HTTPS, headers, authentication, authorisation, patching, and production exposure.
• Monitoring and support: Add logging, dashboards, alerts, runbooks, and production troubleshooting processes.

Whether you need a new ASP.NET application, a safer IIS setup, a cleaned-up web.config, a cloud migration, or help rescuing a legacy system, Eight Mile can provide practical technical guidance and delivery support.

Conclusion

ASP.NET, web.config, and IIS form a powerful stack for Microsoft-based web applications, but the quality of configuration and operations matters. Secure settings, well-managed application pools, reliable deployments, clear monitoring, and careful modernisation can turn an aging or fragile system into a dependable platform for business growth.

Need help with ASP.NET, web.config or IIS? Contact Eight Mile: https://eightmile.co.uk/contact