Update README.md

README.md

@@ -0,0 +1,191 @@
+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 <httpProtocol><customHeaders> 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 <requestLimits maxAllowedContentLength> 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:<port>/
+
+WebApi health: https://localhost:<port>/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