with one click
containerize-aspnet-framework
Containerize an ASP.NET .NET Framework project by creating Dockerfile and .dockerfile files customized for the project.
Menu
Containerize an ASP.NET .NET Framework project by creating Dockerfile and .dockerfile files customized for the project.
| name | containerize-aspnet-framework |
| description | Containerize an ASP.NET .NET Framework project by creating Dockerfile and .dockerfile files customized for the project. |
Containerize the ASP.NET (.NET Framework) project specified in the containerization settings below, focusing exclusively on changes required for the application to run in a Windows Docker container. Containerization should consider all settings specified here.
REMEMBER: This is a .NET Framework application, not .NET Core. The containerization process will be different from that of a .NET Core application.
This section of the prompt contains the specific settings and configurations required for containerizing the ASP.NET (.NET Framework) application. Prior to running this prompt, ensure that the settings are filled out with the necessary information. Note that in many cases, only the first few settings are required. Later settings can be left as defaults if they do not apply to the project being containerized.
Any settings that are not specified will be set to default values. The default values are provided in [square brackets].
Project to containerize:
[ProjectName (provide path to .csproj file)]Windows Server SKU to use:
[Windows Server Core (Default) or Windows Server Full]Windows Server version to use:
[2022, 2019, or 2016 (Default 2022)]Custom base image for the build stage of the Docker image ("None" to use standard Microsoft base image):
[Specify base image to use for build stage (Default None)]Custom base image for the run stage of the Docker image ("None" to use standard Microsoft base image):
[Specify base image to use for run stage (Default None)]Ports that must be exposed in the container image:
[e.g., 80][List any additional ports, or "None"]User account the container should run as:
[User account, or default to "ContainerUser"]IIS settings that must be configured in the container image:
[List any specific IIS settings, or "None"]Custom build steps that must be performed before building the container image:
[List any specific build steps, or "None"]Custom build steps that must be performed after building the container image:
[List any specific build steps, or "None"].NET assemblies that should be registered in the GAC in the container image:
[Assembly name and version, or "None"]MSIs that must be copied to the container image and installed:
[MSI names and versions, or "None"]COM components that must be registered in the container image:
[COM component names, or "None"]Registry keys and values that must be added to the container image:
[Registry paths and values, or "None"]Environment variables that must be set in the container image:
[Variable names and values, or "Use defaults"]Windows Server roles and features that must be installed in the container image:
[Role/feature names, or "None"]Files/directories that need to be copied to the container image:
[Paths relative to project root, or "None"][Container paths, or "Not applicable"]Files/directories to exclude from containerization:
[Paths to exclude, or "None"].dockerignore file (.dockerignore will already have common defaults; these are additional patterns):
[List any additional patterns, or "None"]Health check endpoint:
[Health check URL path, or "None"]Health check interval and timeout:
[Interval and timeout values, or "Use defaults"]Other instructions that must be followed to containerize the project:
[Specific requirements, or "None"]Known issues to address:
[Describe any known issues, or "None"]progress.md file to track changes with check marksTargetFrameworkVersion elementMicrosoft.Configuration.ConfigurationBuilders.Environmentweb.config file to add configuration builders section and settings to read app settings and connection strings from environment variables:
<configSections>
<section name="configBuilders" type="System.Configuration.ConfigurationBuildersSection, System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" restartOnExternalChanges="false" requirePermission="false" />
</configSections>
<configBuilders>
<builders>
<add name="Environment" type="Microsoft.Configuration.ConfigurationBuilders.EnvironmentConfigBuilder, Microsoft.Configuration.ConfigurationBuilders.Environment" />
</builders>
</configBuilders>
<appSettings configBuilders="Environment">
<!-- existing app settings -->
</appSettings>
<connectionStrings configBuilders="Environment">
<!-- existing connection strings -->
</connectionStrings>
LogMonitorConfig.json file in the folder where the Dockerfile will be created by copying the reference LogMonitorConfig.json file at the end of this prompt. The file's contents MUST NOT not be modified and should match the reference content exactly unless instructions in containerization settings specify otherwise.
Information level for EventLog sources will cause unnecessary noise.mcr.microsoft.com/dotnet/framework/sdk base image unless a custom base image is specified in the settings filemcr.microsoft.com/dotnet/framework/aspnet base image unless a custom base image is specified in the settings fileLogMonitorConfig.json file to a directory in the container (e.g., C:\LogMonitor)ENTRYPOINT [ "C:\\LogMonitor\\LogMonitor.exe", "C:\\ServiceMonitor.exe", "w3svc" ].dockerignore file in the root of the project directory to exclude unnecessary files from the Docker image. The .dockerignore file MUST include at least the following elements as well as additional patterns as specified in the containerization settings:
<None Include="Dockerfile" />confirm that Docker build succeeds once the Dockerfile is completed. Use the following command to build the Docker image:
docker build -t aspnet-app:latest .
If the build fails, review the error messages and make necessary adjustments to the Dockerfile or project configuration. Report success/failure.
Maintain a progress.md file with the following structure:
# Containerization Progress
## Environment Detection
- [ ] .NET Framework version detection (version: ___)
- [ ] Windows Server SKU selection (SKU: ___)
- [ ] Windows Server version selection (Version: ___)
## Configuration Changes
- [ ] Web.config modifications for configuration builders
- [ ] NuGet package source configuration (if applicable)
- [ ] Copy LogMonitorConfig.json and adjust if required by settings
## Containerization
- [ ] Dockerfile creation
- [ ] .dockerignore file creation
- [ ] Build stage created with SDK image
- [ ] sln, csproj, packages.config, and (if applicable) NuGet.config copied for package restore
- [ ] Runtime stage created with runtime image
- [ ] Non-root user configuration
- [ ] Dependency handling (GAC, MSI, COM, registry, additional files, etc.)
- [ ] Health check configuration (if applicable)
- [ ] Special requirements implementation
## Verification
- [ ] Review containerization settings and make sure that all requirements are met
- [ ] Docker build success
Do not pause for confirmation between steps. Continue methodically until the application has been containerized and Docker build succeeds.
YOU ARE NOT DONE UNTIL ALL CHECKBOXES ARE MARKED! This includes building the Docker image successfully and addressing any issues that arise during the build process.
An example Dockerfile for an ASP.NET (.NET Framework) application using a Windows Server Core base image.
# escape=`
# The escape directive changes the escape character from \ to `
# This is especially useful in Windows Dockerfiles where \ is the path separator
# ============================================================
# Stage 1: Build and publish the application
# ============================================================
# Base Image - Select the appropriate .NET Framework version and Windows Server Core version
# Possible tags include:
# - 4.8.1-windowsservercore-ltsc2025 (Windows Server 2025)
# - 4.8-windowsservercore-ltsc2022 (Windows Server 2022)
# - 4.8-windowsservercore-ltsc2019 (Windows Server 2019)
# - 4.8-windowsservercore-ltsc2016 (Windows Server 2016)
# - 4.7.2-windowsservercore-ltsc2019 (Windows Server 2019)
# - 4.7.2-windowsservercore-ltsc2016 (Windows Server 2016)
# - 4.7.1-windowsservercore-ltsc2016 (Windows Server 2016)
# - 4.7-windowsservercore-ltsc2016 (Windows Server 2016)
# - 4.6.2-windowsservercore-ltsc2016 (Windows Server 2016)
# - 3.5-windowsservercore-ltsc2025 (Windows Server 2025)
# - 3.5-windowsservercore-ltsc2022 (Windows Server 2022)
# - 3.5-windowsservercore-ltsc2019 (Windows Server 2019)
# - 3.5-windowsservercore-ltsc2019 (Windows Server 2016)
# Uses the .NET Framework SDK image for building the application
FROM mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2022 AS build
ARG BUILD_CONFIGURATION=Release
# Set the default shell to PowerShell
SHELL ["powershell", "-command"]
WORKDIR /app
# Copy the solution and project files
COPY YourSolution.sln .
COPY YourProject/*.csproj ./YourProject/
COPY YourOtherProject/*.csproj ./YourOtherProject/
# Copy packages.config files
COPY YourProject/packages.config ./YourProject/
COPY YourOtherProject/packages.config ./YourOtherProject/
# Restore NuGet packages
RUN nuget restore YourSolution.sln
# Copy source code
COPY . .
# Perform custom pre-build steps here, if needed
# Build and publish the application to C:\publish
RUN msbuild /p:Configuration=$BUILD_CONFIGURATION `
/p:WebPublishMethod=FileSystem `
/p:PublishUrl=C:\publish `
/p:DeployDefaultTarget=WebPublish
# Perform custom post-build steps here, if needed
# ============================================================
# Stage 2: Final runtime image
# ============================================================
# Base Image - Select the appropriate .NET Framework version and Windows Server Core version
# Possible tags include:
# - 4.8.1-windowsservercore-ltsc2025 (Windows Server 2025)
# - 4.8-windowsservercore-ltsc2022 (Windows Server 2022)
# - 4.8-windowsservercore-ltsc2019 (Windows Server 2019)
# - 4.8-windowsservercore-ltsc2016 (Windows Server 2016)
# - 4.7.2-windowsservercore-ltsc2019 (Windows Server 2019)
# - 4.7.2-windowsservercore-ltsc2016 (Windows Server 2016)
# - 4.7.1-windowsservercore-ltsc2016 (Windows Server 2016)
# - 4.7-windowsservercore-ltsc2016 (Windows Server 2016)
# - 4.6.2-windowsservercore-ltsc2016 (Windows Server 2016)
# - 3.5-windowsservercore-ltsc2025 (Windows Server 2025)
# - 3.5-windowsservercore-ltsc2022 (Windows Server 2022)
# - 3.5-windowsservercore-ltsc2019 (Windows Server 2019)
# - 3.5-windowsservercore-ltsc2019 (Windows Server 2016)
# Uses the .NET Framework ASP.NET image for running the application
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022
# Set the default shell to PowerShell
SHELL ["powershell", "-command"]
WORKDIR /inetpub/wwwroot
# Copy from build stage
COPY --from=build /publish .
# Add any additional environment variables needed for your application (uncomment and modify as needed)
# ENV KEY=VALUE
# Install MSI packages (uncomment and modify as needed)
# COPY ./msi-installers C:/Installers
# RUN Start-Process -Wait -FilePath 'msiexec.exe' -ArgumentList '/i', 'C:\Installers\your-package.msi', '/quiet', '/norestart'
# Install custom Windows Server roles and features (uncomment and modify as needed)
# RUN dism /Online /Enable-Feature /FeatureName:YOUR-FEATURE-NAME
# Add additional Windows features (uncomment and modify as needed)
# RUN Add-WindowsFeature Some-Windows-Feature; `
# Add-WindowsFeature Another-Windows-Feature
# Install MSI packages if needed (uncomment and modify as needed)
# COPY ./msi-installers C:/Installers
# RUN Start-Process -Wait -FilePath 'msiexec.exe' -ArgumentList '/i', 'C:\Installers\your-package.msi', '/quiet', '/norestart'
# Register assemblies in GAC if needed (uncomment and modify as needed)
# COPY ./assemblies C:/Assemblies
# RUN C:\Windows\Microsoft.NET\Framework64\v4.0.30319\gacutil -i C:/Assemblies/YourAssembly.dll
# Register COM components if needed (uncomment and modify as needed)
# COPY ./com-components C:/Components
# RUN regsvr32 /s C:/Components/YourComponent.dll
# Add registry keys if needed (uncomment and modify as needed)
# RUN New-Item -Path 'HKLM:\Software\YourApp' -Force; `
# Set-ItemProperty -Path 'HKLM:\Software\YourApp' -Name 'Setting' -Value 'Value'
# Configure IIS settings if needed (uncomment and modify as needed)
# RUN Import-Module WebAdministration; `
# Set-ItemProperty 'IIS:\AppPools\DefaultAppPool' -Name somePropertyName -Value 'SomePropertyValue'; `
# Set-ItemProperty 'IIS:\Sites\Default Web Site' -Name anotherPropertyName -Value 'AnotherPropertyValue'
# Expose necessary ports - By default, IIS uses port 80
EXPOSE 80
# EXPOSE 443 # Uncomment if using HTTPS
# Copy LogMonitor from the microsoft/windows-container-tools repository
WORKDIR /LogMonitor
RUN curl -fSLo LogMonitor.exe https://github.com/microsoft/windows-container-tools/releases/download/v2.1.1/LogMonitor.exe
# Copy LogMonitorConfig.json from local files
COPY LogMonitorConfig.json .
# Set non-administrator user
USER ContainerUser
# Override the container's default entry point to take advantage of the LogMonitor
ENTRYPOINT [ "C:\\LogMonitor\\LogMonitor.exe", "C:\\ServiceMonitor.exe", "w3svc" ]
Note: Customize this template based on the specific requirements in the containerization settings.
When adapting this example Dockerfile:
YourSolution.sln, YourProject.csproj, etc. with your actual file namesAS stage-name syntax gives each stage a name--from=stage-name to copy files from a previous stageThe LogMonitorConfig.json file should be created in the root of the project directory. It is used to configure the LogMonitor tool, which monitors logs in the container. The contents of this file should look exactly like this to ensure proper logging functionality:
{
"LogConfig": {
"sources": [
{
"type": "EventLog",
"startAtOldestRecord": true,
"eventFormatMultiLine": false,
"channels": [
{
"name": "system",
"level": "Warning"
},
{
"name": "application",
"level": "Error"
}
]
},
{
"type": "File",
"directory": "c:\\inetpub\\logs",
"filter": "*.log",
"includeSubdirectories": true,
"includeFileNames": false
},
{
"type": "ETW",
"eventFormatMultiLine": false,
"providers": [
{
"providerName": "IIS: WWW Server",
"providerGuid": "3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83",
"level": "Information"
},
{
"providerName": "Microsoft-Windows-IIS-Logging",
"providerGuid": "7E8AD27F-B271-4EA2-A783-A47BDE29143B",
"level": "Information"
}
]
}
]
}
}
Create, set up, or update the personal context portfolio: structured markdown files describing who you are, how you work, your teams, and your tool/ADO configuration. Runs the interview workflow for first-time setup and targeted edits for updates. Trigger this skill when the user asks to: set up their context, create or update their context portfolio, "create my IQ", "set up my IQ", edit their profile, add/remove a stakeholder, update ADO config, change team info, update pillars, or set up any plugin configuration. Trigger when another skill fails to find context (missing files or TODO markers) and needs context populated. Also trigger when the user mentions a context change in passing (e.g., "my manager changed", "we added someone to the team") to offer a context file update. Do NOT trigger for read-only questions like "who's on my team?" or "what's my ADO config?". Those are answered directly from the context files referenced in the loaded custom instructions; no skill is needed.
Adopt repository-level harness engineering for coding agents. Use when a user wants to prevent repeated AI coding-agent mistakes by turning failures into durable instructions, drift checks, regression tests, failure memory, and adoption reports tailored to the target repository.
Security hardening reviewer for GitHub Actions workflow files (.github/workflows/*.yml). Reasons about the Actions threat model that pattern matchers and general code linters miss — untrusted-input script injection, privileged triggers running fork code, mutable action references, and over-scoped tokens. Use this skill when asked to review, audit, harden, or secure a GitHub Actions workflow, when writing a new workflow, or for any request like "is this workflow safe?", "review my CI for security issues", "why is pull_request_target dangerous here?", "pin my actions", or "lock down GITHUB_TOKEN permissions". Covers script injection via ${{ }} interpolation, pull_request_target / workflow_run privilege escalation, SHA-pinning of third-party actions, least-privilege permissions, GITHUB_ENV/GITHUB_OUTPUT injection, secret exposure, OIDC over long-lived credentials, and self-hosted runner exposure on public repositories.
Build GitHub Copilot workflows with Xquik X API SDKs, REST endpoints, MCP tools, signed webhooks, tweet search, user lookup, follower exports, media actions, and agent automation.
Comprehensive guide for configuring and managing GitHub Dependabot. Use this skill when users ask about creating or optimizing dependabot.yml files, managing Dependabot pull requests, configuring dependency update strategies, setting up grouped updates, monorepo patterns, multi-ecosystem groups, security update configuration, auto-triage rules, or any GitHub Advanced Security (GHAS) supply chain security topic related to Dependabot. For pre-commit dependency vulnerability scanning in AI coding agents via the GitHub MCP Server, this skill references the Advanced Security plugin (`advanced-security@copilot-plugins`). Use this skill when an agent needs to scan dependencies for known vulnerabilities before committing.
Enable code intelligence (go-to-definition, find-references, hover, type info) for any programming language by installing and configuring an LSP server for Copilot CLI. Detects the OS, installs the right server, and generates the JSON configuration (user-level or repo-level). Use when you need deeper code understanding and no LSP server is configured, or when the user asks to set up, install, or configure an LSP server.