How to Host an ASP.NET Website on Windows Hosting

What ASP.NET Needs From a Host

Five steps, once you have Windows hosting provisioned:

1. Prepare — switch the project from Debug to Release, publish to a folder, and have the MSSQL database ready.
2. Publish — Visual Studio's Publish dialog with Web Deploy (enter the server URL, site name and panel credentials), or FTP/FTPS the published folder's contents into httpdocs/wwwroot.
3. Configure IIS — on Plesk, open the site's settings: set the .NET runtime version, and ensure the web.config generated at publish travels with the files.
4. Connect MSSQL — create the database and user in the panel, wire the production connection string, run migrations.
5. Test — load data-driven pages, exercise a write path, and check error logs for first-chance exceptions.

Always publish the project, never copy the raw source directory.

Windows vs Linux Hosting for .NET

Windows and Linux Hosting for .NET are not the same product. Windows is the option with less for you to operate. Linux Hosting for .NET is the option with more control, and more that you have to look after. Choose by what happens when it breaks at night, and by the INR figure on this page. Email support@webji.services if you want that choice made against your actual site.

Step 1: Prepare the Project and Database

How this plays out with Windows hosting with Plesk/IIS: settings that look cosmetic usually decide page speed and uptime under real traffic. The defaults WebJi® ships are tuned for Indian network conditions, and support can review your setup on request.

Step 2: Publish via Visual Studio or FTP

How this plays out with Visual Studio publish (MSDeploy, FTP): settings that look cosmetic usually decide page speed and uptime under real traffic. The defaults WebJi® ships are tuned for Indian network conditions, and support can review your setup on request.

Step 3: Configure IIS, web.config and Runtime

Configure IIS, web.config and Runtime. Do this on one site or a staging copy first, then check the public URL in a private window so cache does not hide the result. Stop if the page errors, and email support@webji.services with the step name and the exact error before you repeat it on every account. WebJi® support mail is staffed 24/7 in Hindi and English; the phone line +91 141 4941811 is business hours only.

Step 4: Connect MSSQL and Test

Create the MSSQL database and user in your hosting panel, then wire the connection string. In appsettings.json (Core) or web.config (Framework), set the production connection string to the panel-provided server, database and credentials — Server=mssql.yourhost.com;Database=yourdb;User Id=youruser;Password=... — replacing any LocalDB or localhost development values.

Run your schema script or Entity Framework migrations against the remote database through the panel's query tool or a local SSMS connection. Then test end to end: load pages that read the database, exercise a write path — registration, form submit — and check error logs for first-chance exceptions. A site that serves static pages but fails on data access is almost always a wrong connection string or a database user missing db_datawriter rights; the Windows hosting stack covers the platform prerequisites.

Common Deployment Errors and Fixes

Five errors dominate first deployments:

• Runtime error mentioning a missing framework — the host's .NET version does not match your target; pick the matching version in the panel or redeploy self-contained.

• 403.14 Forbidden — no default document and browsing disabled; set the default document or land users on a valid route.

• 500.19 config error — malformed web.config, usually a section invalid on shared IIS; validate the XML and remove sections the host disallows.

• Database login failed — connection string points to localhost or credentials mismatch; verify against the panel's exact server name.

• Files upload but nothing changes — Debug output went to the wrong folder or the app pool needs a recycle; confirm the target path (httpdocs root, not a subfolder) and restart.

Turn customErrors off while debugging, and back on the moment it works.