.NET Core 3.1项目中web.config配置迁移至launchsettings.json的方法咨询(Visual Studio 2019环境)
Great question—let's clear up a common misconception first: .NET Core doesn't ditch web.config entirely, but its purpose shifts. launchsettings.json is only for local development startup configurations (like ports, debug modes, environment variables), while web.config remains essential when deploying to IIS (it configures the AspNetCoreModule that hosts your .NET Core app).
Let's walk through each part of your legacy web.config and map where each setting belongs:
1. HTTPS Redirect Rule
Local Development
You can skip relying on IIS rewrite rules locally and configure HTTPS directly in launchsettings.json, plus add middleware to handle redirects across all environments:
launchsettings.json example:
{ "$schema": "http://json.schemastore.org/launchsettings.json", "profiles": { "IIS Express": { "commandName": "IISExpress", "launchBrowser": true, "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" }, "sslPort": 44300 // Pick your preferred local HTTPS port }, "YourLegacyApp": { "commandName": "Project", "launchBrowser": true, "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" }, "applicationUrl": "https://localhost:5001;http://localhost:5000" // Enables both HTTP/HTTPS } } }
Add HTTPS redirection middleware (in Startup.cs for .NET Core 3.1):
// In ConfigureServices services.AddHttpsRedirection(options => { options.HttpsPort = 443; // Your production HTTPS port }); // In Configure (before app.UseEndpoints) app.UseHttpsRedirection();
Production (IIS)
Leave the rewrite rule in web.config—this is handled by IIS before requests reach your .NET Core app, which is still a valid and efficient way to enforce HTTPS.
2. aspNetCore Section Settings
This section controls how IIS hosts your .NET Core app. Split these settings between local dev and deployment:
Move to launchsettings.json (Local Dev)
- Logging: Instead of relying on IIS stdout logging locally, you can configure app-specific logging in
appsettings.Development.json, but if you want to mimic IIS's behavior:"environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development", "ASPNETCORE_STDOUT_LOG_ENABLED": "true", "ASPNETCORE_STDOUT_LOG_FILE": ".\\logs\\stdout" } - Hosting Model: If you want to use InProcess hosting locally, add this to your IIS Express profile:
"IIS Express": { // ... other settings "hostingModel": "InProcess" }
Keep in web.config (Deployment)
processPathandarguments: These are auto-populated when you publish to IIS—no need to edit them manually.handlerSettings: These are specific to the AspNetCoreModule, so they stay in web.config for production IIS hosting.
3. Third-Party ISAPI Handlers, Modules, and Filters
All entries under <handlers> (like IsapiModule and thirdPartyWebAgentModule), <modules>, and <isapiFilters> are IIS-native configurations, not .NET Core-specific.
You cannot move these to launchsettings.json—they must stay in web.config. These settings tell IIS how to handle specific requests (like .abc files) before they even reach your .NET Core app, so they're critical for maintaining your legacy third-party agent integration.
Final Key Notes
- Local Dev Workflow: Use
launchsettings.jsonto tweak your local setup (ports, environment variables). The third-party IIS modules won't impact local dev unless you're using full IIS (not IIS Express) locally—most devs stick to IIS Express or the direct Kestrel profile. - Deployment: When publishing to IIS, your web.config needs to retain all IIS-native sections (rewrite rules, handlers, modules, filters) plus the
aspNetCoresection. The publish process will updateprocessPathandargumentsautomatically. - Compatibility Check: Verify that your third-party web agent supports .NET Core 3.1 and InProcess hosting (if you're using it). Some older ISAPI modules may have issues with modern IIS hosting models.
内容的提问来源于stack exchange,提问作者7 Reeds

