6.8 KiB
EICHER Web Application
One-line: Enterprise .NET Framework 4.8 web application (ASP.NET MVC) with a co-hosted Web API on the same IIS server.
Table of contents
Overview
Technology stack
What I used from web.config
Prerequisites
Solution structure
Configuration notes (important)
Development setup (local)
Deploying to IIS (server)
Security & secrets
Logging & diagnostics
Common issues & troubleshooting
Contacts
Overview
This repository contains the EICHER web application built on .NET Framework 4.8 (ASP.NET MVC) and a Web API hosted together on the same IIS server. The Web API endpoints used by the app are configured under relative paths such as Api/... so the recommended deployment pattern is the web site as root and the API as an IIS application (e.g. /api).
Technology stack
.NET Framework 4.8 (targetFramework in httpRuntime)
ASP.NET MVC (System.Web.Mvc referenced, v4)
ASP.NET Web API (consumed by the UI via relative Api/... routes)
Enterprise Library Logging (Microsoft.Practices.EnterpriseLibrary.Logging v5)
IIS (Integrated pipeline recommended)
SQL Server Express is used in local config (.\SQLEXPRESS with an attach DB example)
What I used from web.config
compilation targetFramework="4.8" debug="true" — confirms .NET 4.8 target.
httpRuntime settings: large maxRequestLength and long executionTimeout (good for large uploads/long-running requests).
Machine key defined (AES) — used for forms auth / view state / machineKey scenarios.
Logging configured via Enterprise Library (Email and Flat File listeners, ErrorLog/trace.log).
appSettings keys for environment-specific endpoints and API routes:
RestfulApiUrl → Here need to keep web API path
hostAddress → This is where web allication host
Application uses many Api/* relative paths (e.g. Api/report?type=..., Api/Tracking?...).
CORS-ish headers added under with Access-Control-Allow-Origin: * and Access-Control-Allow-Headers: *.
handlers were extended to allow verbs including PUT, DELETE, PATCH and OPTIONS and a high maxAllowedContentLength was set.
Prerequisites
Windows Server with IIS (8.5 / 10 recommended)
.NET Framework 4.8 installed on server
Visual Studio 2019 / 2022
SQL Server (local dev uses SQL Express with attach DB)
Required service accounts (app pool identities) and access to the database Configuration notes (important)
Web.config transforms: keep environment-specific endpoints and secrets out of the base web.config and use Web.Release.config / Web.Debug.config to inject environment values at publish time.
ConnectionStrings: current sample uses an attachable .mdf on SQLEXPRESS. For production switch to a real SQL Server instance and secure credentials.
API pathing: The application uses relative API paths such as Api/report?... and Api/Tracking?.... When deploying API as an IIS application under the web site, ensure the physical folder is converted to an Application and that routes are working.
Max request sizes: httpRuntime and are already set to very large values to allow big uploads. Confirm these values with your ops policy.
Handlers: Custom handlers in system.webServer allow many HTTP verbs. Keep these if the API needs them.
Development setup (local)
Clone the repo.
Open solution in Visual Studio.
Restore NuGet packages.
Update Web.config (or use transform) to set local DB, RestfulApiUrl, hostAddress, and other environment keys:
RestfulApiUrl = http://localhost:3117/ (example in repo)
hostAddress = http://localhost:3118 (example)
Build and run WebApi (IIS Express) and WebApp. Confirm endpoints:
WebApp: https://localhost:/
WebApi health: https://localhost:/Api/health (or the API endpoints listed in settings)
Deploying to IIS (server)
Recommended pattern: Root site + API as an IIS Application (single hostname)
Steps (summary):
Publish WebApp to a folder (MSBuild / Visual Studio Publish / CI pipeline).
Create an IIS Site (or use existing root site) and point physical path to published WebApp.
Publish WebApi to a separate folder and under the root site create a new Application called api (or /Api) and point to the WebApi publish folder. Right-click -> Convert to Application.
Configure application pools:
Use .NET CLR v4.0 (this targets .NET Framework 4.x)
Use Integrated pipeline mode.
For isolation, give WebApi its own app pool; otherwise use same app pool if you want shared memory/cache, but that reduces fault isolation.
Update the Web.config connection strings and appSettings to point to production DB and API hostnames/ports (use transforms).
Ensure firewall rules and host headers are set.
Recycle app pools or restart IIS after deploy.
Notes about IIS settings derived from web.config:
directoryBrowse is enabled="true" in the config — disable in production.
customHeaders currently allow * for origin and headers. Consider locking down to specific origins.
maxAllowedContentLength and maxRequestLength are large; review to avoid DOS via oversized uploads.
Security & secrets
MachineKey present in web.config — do not store this in plain text in source control for public repos. Keep it behind secure storage for production.
Many SMTP and other sensitive values are blank or set in appSettings. Move credentials to a secure store (Azure Key Vault, environment variables, or encrypted config sections).
customErrors is Off in this config — set to On (or RemoteOnly) in production and log exception details instead of showing them to users.
Logging & diagnostics
Enterprise Library Logging is configured with:
Flat file listener: ErrorLog/trace.log
Email Trace Listener configured (smtp config present in listener but also separate SMTP keys exist in appSettings)
For production, consider centralizing logs (Seq, ELK, Application Insights) and ensure log rotation and disk monitoring (config includes DeleteLogFile and Day keys).
Failed Request Tracing (IIS) and Event Viewer are helpful for 500 errors.
Common issues & troubleshooting
404 on /Api/*: make sure /Api is an IIS application (Convert to Application) and that WebApi routes are registered.
CORS or blocked requests: Access-Control-Allow-* headers are present but if you host API on a different hostname/port you will need proper CORS middleware or headers specific to allowed origins.
Large file uploads failing: check httpRuntime maxRequestLength, requestLimits maxAllowedContentLength, and IIS request filtering.
Forms auth / machineKey mismatches: if you run multiple app pools or web farms, ensure the same machineKey is used across instances for consistent forms auth and viewstate.
Contacts
Dev lead: Name — email@example.com
Ops: Name — ops@example.com Windows Server with IIS (8.5 / 10 recommended)
.NET Framework 4.8 installed on server
Visual Studio 2019 / 2022
SQL Server (local dev uses SQL Express with attach DB)
Required service accounts (app pool identities) and access to the database