如何在Windows系统中部署ASP.NET Core项目?含MVC5迁移编译后部署方案
Hey there! Let’s walk through both of your deployment questions clearly—whether you’re deploying a fresh ASP.NET Core project or your upgraded MVC 5 → Core app, I’ve got you covered.
1. Deploying a Fresh ASP.NET Core Project on Windows
The two most common ways to deploy on Windows are via IIS (the standard for production) or self-hosting with Kestrel (great for testing or simple deployments). Let’s start with IIS since it’s the go-to for most production scenarios:
IIS Deployment Steps
- Install the .NET Core Hosting Bundle: This non-negotiable component includes the ASP.NET Core Module (ANCM), which acts as a reverse proxy between IIS and your Core app’s Kestrel server. Just search for ".NET Core Hosting Bundle" in your browser to grab the installer from the official .NET downloads page.
- Publish Your Project:
- In Visual Studio: Right-click your project → Publish, choose Folder as the target, pick an output directory, and hit Publish.
- Or via CLI: Run
dotnet publish -c Release -o ./publishin your project’s root directory. This builds an optimized release version and drops it into thepublishfolder.
- Configure IIS:
- Open IIS Manager, right-click Sites → Add Website.
- Name your site, set the Physical path to your published
publishfolder. - For the Application Pool, create a new one (or use an existing one) and set .NET CLR version to No Managed Code—since ASP.NET Core runs its own runtime, IIS doesn’t need to manage .NET code here.
- Set up your binding (port, hostname, SSL if needed) and click OK.
- Troubleshooting: If the site won’t load, check the Event Viewer under Windows Logs → Application for ASP.NET Core errors, or look for log files in your published folder’s
logsdirectory.
Self-Hosting with Kestrel
If you don’t need IIS (e.g., for testing or internal tools):
- After publishing, open Command Prompt/PowerShell in the
publishfolder and rundotnet YourProjectName.dll. Your app will start on the default port (usually 5000/5001). - To run it as a Windows Service (so it starts automatically on boot), use tools like NSSM or the built-in
sccommand. For example:sc create "MyCoreAppService" binPath="C:\Program Files\dotnet\dotnet.exe C:\path\to\publish\YourProjectName.dll" start=auto
2. Deploying Your Upgraded ASP.NET MVC 5 → ASP.NET Core Project
Good news: The core deployment flow is almost identical to a fresh Core project! But there are a few migration-specific checks to avoid headaches:
- Validate Publish Configurations:
- Make sure your
appsettings.json(andappsettings.Production.jsonfor production) includes all necessary settings that were previously in your MVC 5web.config(like database connections, API keys). - Double-check that your project’s publish profile includes all required files—Visual Studio usually handles this, but it’s worth verifying that
appsettings.json,wwwroot(static files), and any custom config files are included in the published output.
- Make sure your
- Check Dependencies:
- Run
dotnet restoreanddotnet build -c Releaselocally first to confirm no missing NuGet packages or build errors slipped through during the upgrade. - Inspect the
publishfolder to ensure all required DLLs are present—if something’s missing, you might need to adjust your project’s dependency settings.
- Run
- Migrate IIS-Specific Settings:
- If your old MVC 5 site used URL rewrite rules, custom headers, or IIS modules, you’ll need to port these to ASP.NET Core:
- For rewrite rules: Use the
Microsoft.AspNetCore.Rewritemiddleware in yourProgram.cs(e.g., addapp.UseRewriter(new RewriteOptions().AddRedirectToHttps());). - For IIS-specific configs: Edit the
web.configfile in your published folder (this is an IIS-specific config file, not your app’s main config) to add rules or modules as needed.
- For rewrite rules: Use the
- If your old MVC 5 site used URL rewrite rules, custom headers, or IIS modules, you’ll need to port these to ASP.NET Core:
- Test Core Functionality:
- After deployment, test critical features first: routing (make sure old URLs still work if you kept them), database connections, authentication/authorization (especially if you upgraded Identity), and static files.
- If you made database schema changes during the upgrade, run
dotnet ef database updatein the production environment (or generate a migration script and run it manually for more control) to ensure your database is up to date.
内容的提问来源于stack exchange,提问作者Amir Hamza




