# IIS

> Host an ASP.NET Core app with TX Text Control in IIS: Hosting Bundle, win-x64 publish, a 64-bit application pool and settings for the Document Editor backend.

- **Product:** TX Text Control .NET Server
- **Section:** Documentation
- **Kind:** Topic
- **Path:** TX Text Control .NET Server > Deployment Guide > Windows > IIS
- **2638 words**
- **Web URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/windows/iis/
- **LLMs URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/windows/iis/llms.txt
- **LLMs-Full URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/windows/iis/llms-full.txt

---

Internet Information Services (IIS) hosts an ASP.NET Core application through the ASP.NET Core Module: by default, the application runs inside the worker process of its application pool. With TX Text Control .NET Server, that worker process also starts the Document Editor backend, so the settings of the application pool decide whether the backend runs, how long editing sessions last and whether two processes compete for the same port.

The steps below publish an application with document processing, the Document Editor and the Document Viewer to IIS on Windows Server, following Microsoft's guide [Host ASP.NET Core on Windows with IIS](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/) and adding what TX Text Control needs.

### Prerequisites

- **Windows Server 2019, 2022 or 2025.** These are the Windows Server versions the requirements documentation lists for deployment.
- **An ASP.NET Core application with TX Text Control**, for example the application of [Document Editor: ASP.NET Core](https://docs.textcontrol.com/tx-text-control-dotnet-server/getting-started/document-editor/aspnet-core/llms-full.txt). The commands use a .NET 10 project named *MyApp*.
- **A runtime license** for the server. See [Runtime Licenses](https://docs.textcontrol.com/tx-text-control-dotnet-server/installation/licensing/runtime/llms-full.txt).

### What Runs in IIS

```text
Browser
    |  HTTP and WebSocket
    v
IIS with the ASP.NET Core Module
    |
    v
w3wp.exe, the worker process of the application pool, running your application
    |  TCP, port 4283
    v
dotnet.exe TXTextControl.Web.Server.Core.dll, started by DocumentEditorWorkerManager
    |
    v
One worker process for each open editor
```

With the default in-process hosting, your application runs in *w3wp.exe*. The hosted service `DocumentEditorWorkerManager` locates the 64-bit `dotnet` runtime on the machine and starts the backend with it, as a child process under the identity of the application pool. When the worker process ends, for example after an idle timeout or a recycle, the backend and all open editing sessions end with it.

### Prepare the Server

1. **Install IIS with the WebSocket Protocol.** In Server Manager, open the **Add Roles and Features** wizard and select the **Web Server (IIS)** role. In the **Role services** step, expand **Web Server** and **Application Development** and select **WebSocket Protocol**. Without it, the Document Editor can't connect. [Host the Connection](https://docs.textcontrol.com/tx-text-control-dotnet-server/integration/websockets/#host-the-connection) describes the same feature on Windows desktop systems.
2. **Install the .NET Hosting Bundle** after IIS. It installs the .NET Runtime and the ASP.NET Core Module. If the bundle was installed before IIS, run its installer again to repair it. Don't install it with the option `OPT_NO_RUNTIME=1`: the Document Editor backend needs the shared 64-bit .NET runtime, even when your application is published self-contained.
3. **Install the Microsoft Visual C++ Redistributable for Visual Studio 2017, 2019 and 2022** in its x64 version, which TX Text Control requires.
4. **Restart IIS** from an elevated command prompt, so that the worker processes find the `dotnet` command:

    ```powershell
    net stop was /y
    net start w3svc
    ```

### Publish the Application

Publish the application for 64-bit Windows on your development machine:

```powershell
dotnet publish -c Release -r win-x64 --self-contained false
```

The output in *bin\\Release\\net10.0\\win-x64\\publish* contains your application, a generated *web.config* for the ASP.NET Core Module, the TX Text Control assemblies with their native Windows libraries, the *Fonts* folder of the Core engine and the files of the Document Editor backend. Keep the *web.config* file: without it, IIS may serve files such as *MyApp.runtimeconfig.json* to the public.

#### Publish From Visual Studio

Visual Studio creates the same output with a folder publish profile. The NuGet packages copy the TX Text Control files into it:

1. In Solution Explorer, right-click the project and choose **Publish**.
2. Select **Folder** as the target and click **Next**.

    ![The Publish dialog of Visual Studio asking where to publish, with the targets Azure, ClickOnce, Docker Container Registry, Folder and Import Profile, and Folder selected.](https://docs.textcontrol.com/assets/img/tx-text-control-dotnet-server/vs-publish-target-folder.9450845c.webp)
3. Select **Folder** again as the specific target, confirm with **Next**, choose the folder location and click **Finish**. Visual Studio creates the profile *FolderProfile.pubxml*.
4. In the summary of the profile, click **Show all settings**.

    ![The publish profile summary in Visual Studio with the target location bin\Release\net8.0\publish, the Target Runtime Portable and the link Show all settings circled.](https://docs.textcontrol.com/assets/img/tx-text-control-dotnet-server/vs-publish-all-settings.a44aa618.webp)
5. Set **Target Runtime** to **win-x64**, keep **Deployment Mode** at **Framework-dependent** and click **Save**.

    ![The profile settings of a folder publish profile with the Target Runtime drop-down open and win-x64 selected.](https://docs.textcontrol.com/assets/img/tx-text-control-dotnet-server/vs-publish-runtime-win-x64.c0c72c12.webp)
6. Click **Publish**. The selected folder then contains the published application with all TX Text Control files.

A web project copies *.config* files from its folder into the output. Don't keep a *nuget.config* with the credentials of the Text Control Private NuGet Feed in the project folder; keep it in the folder above.

### Create the Site and the Application Pool

1. **Copy the output** to a folder on the server, for example *C:\\sites\\MyApp*.
2. **Add the site.** In IIS Manager, right-click **Sites**, select **Add Website**, enter *MyApp* as **Site name**, set **Physical path** to *C:\\sites\\MyApp* and enter the **Binding** with the host name of the site. Don't use top-level wildcard bindings such as `http://*:80/`. IIS creates an application pool with the name of the site.

    ![The Add Website dialog of IIS Manager with the fields Site name, Physical path, the binding type, IP address, port and Host name.](https://docs.textcontrol.com/assets/img/tx-text-control-dotnet-server/iis-add-website.55d7870e.webp)
3. **Set the .NET CLR version.** Under **Application Pools**, right-click *MyApp*, select **Basic Settings** and set **.NET CLR version** to **No Managed Code**.
4. **Keep the application pool 64-bit.** In the **Advanced Settings** of the pool, **Enable 32-Bit Applications** must be `False`, which is the default. The Core engine contains native libraries for 64-bit Windows only, and the Document Editor backend refuses to start in a 32-bit process.
5. **Grant access to the folder.** The application pool runs as `IIS AppPool\MyApp` and needs read and execute permissions:

    ```powershell
    ICACLS C:\sites\MyApp /grant "IIS AppPool\MyApp:(OI)(CI)RX"
    ```

### Keep the Document Editor Backend Running

The default settings of an application pool end its worker process when nobody uses the site and start a new one at regular intervals. For an application with the Document Editor, each end also ends the backend and all open editing sessions. Change these settings in the **Advanced Settings** of the application pool, which IIS Manager opens from the **Actions** pane when the pool is selected under **Application Pools**:

![The Advanced Settings dialog of an application pool with .NET CLR Version set to No Managed Code, Enable 32-Bit Applications, Start Mode OnDemand and Idle Time-out (minutes) 20.](https://docs.textcontrol.com/assets/img/tx-text-control-dotnet-server/iis-pool-advanced-settings.eb9cbc53.webp)

| Setting | Default | For the Document Editor |
|---|---|---|
| **Idle Time-out (minutes)** | 20 | `0`, so that the worker process doesn't end during periods without requests. The setting applies to in-process hosting. |
| **Start Mode** | `OnDemand` | `AlwaysRunning`, together with **Preload Enabled** set to `True` in the **Advanced Settings** of the site. The application and its backend then start with the pool instead of with the first request. This requires the IIS role service **Application Initialization**. |

#### Avoid Overlapping Worker Processes

When IIS recycles an application pool, it starts the new worker process while the old one is still shutting down. Both run your application, and both start a backend on the same port. The backend of the new process can't listen on the port that the old one still uses, and it ends. Until the old process exits, the editors of the new process are served by the old backend; afterward, no backend is left, and the editors fail with "Could not connect to TextControl TCP server".

Set the attribute `disallowOverlappingRotation` of the pool's recycling settings to `true`. Microsoft recommends this value for worker processes that load application code that doesn't support multiple worker processes. For the same reason, keep the number of worker processes of the pool, the attribute `maxProcesses`, at its default value of 1.

#### Run Several Applications on One Server

Each application with the Document Editor starts its own backend, and without configuration all of them use port 4283. Give each application its own port with `DocumentEditorWorkerOptions` in *appsettings.json* and pass the same port to `UseTXWebSocketMiddleware`, as [Configure the Backend Process](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-editor/architecture/#configure-the-backend-process) shows.

### Host the Application as a Sub-Application

IIS virtual directories aren't supported for ASP.NET Core applications; host the application as a sub-application instead. Create a separate application pool with **No Managed Code** for it, add the folder under the root site, select **Convert to Application** and assign the pool. In-process hosting requires the separate pool.

In a sub-application, the address of the WebSocket handler includes the folder of the application. Set `APIRoute` in the view as described in [Host the Application in a Subfolder](https://docs.textcontrol.com/tx-text-control-dotnet-server/integration/websockets/#how-the-websocket-url-is-built).

### Fonts With the Classic Engine

The Core engine takes its fonts from the published *Fonts* folder, so IIS servers need no fonts for it. The Classic engine in `TXTextControl.TextControl.ASP.SDK` uses the fonts installed on Windows, and newer systems such as Windows Server 2025 often don't come with a full set of fonts. Install the fonts your documents use on the server.

### Verify the Deployment

1. Browse to the site. The page with the Document Editor shows the editor with its ribbon.
2. If the site answers with the error 500.30, the application ended during startup. Turn on the stdout log of the ASP.NET Core Module to read the reason, as [Read the Log of the Application](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/iis/#read-the-log-of-the-application) describes; [The Site Answers With Error 500.30](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/iis/#the-site-answers-with-error-500-30) explains the messages of a 32-bit application pool and a missing .NET runtime.
3. If the page loads but the editor doesn't, open the console of the browser's developer tools. A WebSocket connection to */api/TXWebSocket* that fails points to a missing WebSocket Protocol feature.

[Troubleshooting IIS](https://docs.textcontrol.com/tx-text-control-dotnet-server/troubleshooting/iis/llms-full.txt) collects further problems.

### Applications on the .NET Framework

ASP.NET applications on the .NET Framework use the Classic engine from the Windows setup. The requirements list IIS 7.0 or later, and for the Document Editor IIS 8.0 or later with the WebSocket Protocol. Their Document Editor backend is still the TX TextControl Service, a Windows service that you install on the server with *txregwebsvr.exe*, not a process that the application starts. [.NET Framework Applications](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/windows/dotnet-framework/llms-full.txt) describes how to deploy them, and [ASP.NET on .NET Framework](https://docs.textcontrol.com/tx-text-control-dotnet-server/integration/dotnet-framework/llms-full.txt) how to build them.

### Next Steps

- [Windows Service](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/windows/windows-service/llms-full.txt): run an application without IIS.
- [WebSocket Architecture](https://docs.textcontrol.com/tx-text-control-dotnet-server/integration/websockets/llms-full.txt): the connection of the Document Editor in detail.
- [Document Editor Architecture](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-editor/architecture/llms-full.txt): the backend process and its configuration.
- [Azure App Service Windows](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/azure/app-service-windows/llms-full.txt): host the application in Azure instead.

---

## Nearby

- **Previous:** [Windows](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/windows/llms-full.txt)
- **Next:** [Windows Service](https://docs.textcontrol.com/tx-text-control-dotnet-server/deployment/windows/windows-service/llms-full.txt)