Release configuration

Release builds apply XML transforms from Web.Release.config to produce production-safe settings: HTTPS flags off until SSL is ready, compilation debug disabled, and friendly error pages for remote users.

Introduction

ASP.NET Web Projects merge transform files at publish time. Damsy ERP's Release transform encodes lessons from VPS deployments — especially HTTP-only sites that broke when ForceHttps or cookie requireSSL were enabled prematurely.

Purpose

Ensure published Web.config on the server is optimized, secure enough for production, and does not redirect or drop cookies until TLS is properly configured.

When to use

• Reviewing settings before first VPS go-live
• Debugging redirect loops or session loss after deploy
• Enabling HTTPS after certificate installation
• Understanding why local Debug behaves differently from IIS Release

Pair with Publish the application and Deploy to IIS.

How it works

At application start and on each request, Global.asax.cs reads appSettings["ForceHttps"]. When true, HTTP requests receive a permanent redirect to HTTPS. Cookie settings in system.web/httpCookies must align — requireSSL=true without HTTPS causes browsers to reject session cookies.

Transform file location

DamsyERP.UI/Web.Release.config

Settings applied on Release publish

Setting	Release value	Role
ForceHttps	false	No HTTP→HTTPS redirect until cert ready
compilation debug	false	Performance; no debug symbols in views
customErrors mode	RemoteOnly	Friendly page for users; details on server
customErrors defaultRedirect	~/ManageError/Index	Central error handler
httpCookies requireSSL	false	Session cookie works over HTTP
httpCookies httpOnlyCookies	true	Mitigate XSS cookie theft
httpRuntime executionTimeout	7200	Long reports / uploads

Step-by-step — Release checklist

Step 1 — Publish with Release configuration

Use profile MVC_PUBLISH with Configuration: Release. The transform merges automatically — you do not manually edit transforms on the server for standard deploys.

Step 2 — Verify published Web.config

Open the publish folder Web.config (not source) and confirm:

<add key="ForceHttps" value="false"/>

<compilation debug="false" targetFramework="4.5.2" />
<customErrors mode="RemoteOnly" defaultRedirect="~/ManageError/Index">

<httpCookies httpOnlyCookies="true" requireSSL="false"/>

Step 3 — Set connection strings on the server

warning

Keep production connection strings in the server's deployed Web.config. Do not rely on machine-specific values in Git or assume transforms will inject VPS credentials.

Primary application connection name:

<connectionStrings>
  <add name="MyConnectionString"
       connectionString="Data Source=localhost\SQLEXPRESS;Initial Catalog=DB_DAMSYERP;Integrated Security=True;TrustServerCertificate=True"
       providerName="System.Data.SqlClient" />
</connectionStrings>

Legacy names (ZDBERP_ZPILOTConnectionString, ZDBERP_PANZERConnectionString) may remain for Crystal or historical tools; DAL uses MyConnectionString via BaseHelper.ResolveConnectionString().

After editing connection strings on IIS:

1. Save Web.config.
2. Recycle the application pool.

Step 4 — Enable HTTPS (when ready)

After SSL certificate is bound in IIS:

1. Edit deployed Web.config on the server (or update source transform and republish):

<add key="ForceHttps" value="true"/>

<httpCookies httpOnlyCookies="true" requireSSL="true"/>

2. Recycle app pool.
3. Test login and module navigation over https:// only.

Both flags must move together — see Common mistakes.

Examples

Example — customErrors behavior

Viewer	RemoteOnly behavior
User on another PC	Redirect to /ManageError/Index
Browser on server localhost	Yellow ASP.NET error page (details)
Failed login	Application message, not transform

Example — ForceHttps interaction

// Global.asax.cs — simplified
if (ConfigurationManager.AppSettings["ForceHttps"] == "true"
    && !Request.IsSecureConnection)
{
    Response.Redirect("https://" + Request.Url.Host + Request.RawUrl, true);
}

With ForceHttps=false, this block never redirects.

Example — Server-only connection string patch

After copying publish to C:\inetpub\wwwroot\damsy_erp, edit:

C:\inetpub\wwwroot\damsy_erp\Web.config

Point Initial Catalog at DB_DAMSYERP on the VPS SQL instance.

Related pages

• Deploy to IIS
• Publish the application
• Connection strings
• Troubleshooting — HTTPS loop

Important notes

• Source vs deployed config: Developers often run Debug locally with Web.config directly; IIS runs the merged Release output.
• ManageError: customErrors and Application_Error in Global.asax.cs route to ManageErrorController — investigate underlying exceptions in Event Viewer or failed request tracing, not only the friendly page.
• Do not commit VPS secrets: Password-based SQL auth strings belong in server config or secure vaults, not shared repo history.
• TrustServerCertificate: Common on Express/local VPS; tighten for hardened production if policy requires.

Common mistakes

Mistake	Symptom
ForceHttps=true without SSL binding	Redirect loop or connection reset
requireSSL=true on HTTP site	Login succeeds then session lost; modules redirect to login
Editing source Web.config but not republishing	IIS still runs old published config
customErrors=On during initial VPS debug	Hides real exception; use RemoteOnly and browse from server
Wrong catalog in MyConnectionString	Login or dashboard SP failures

Next steps

1. Publish and deploy to IIS.
2. Configure database and seed data.
3. Keep Troubleshooting handy for first login tests.