You need to enable JavaScript to run this app.
最新活动
大模型
产品
解决方案
定价
生态与合作
支持与服务
开发者
了解我们

如何在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 ./publish in your project’s root directory. This builds an optimized release version and drops it into the publish folder.
  • Configure IIS:
    1. Open IIS Manager, right-click SitesAdd Website.
    2. Name your site, set the Physical path to your published publish folder.
    3. 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.
    4. 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 logs directory.

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 publish folder and run dotnet 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 sc command. 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 (and appsettings.Production.json for production) includes all necessary settings that were previously in your MVC 5 web.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.
  • Check Dependencies:
    • Run dotnet restore and dotnet build -c Release locally first to confirm no missing NuGet packages or build errors slipped through during the upgrade.
    • Inspect the publish folder to ensure all required DLLs are present—if something’s missing, you might need to adjust your project’s dependency settings.
  • 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.Rewrite middleware in your Program.cs (e.g., add app.UseRewriter(new RewriteOptions().AddRedirectToHttps());).
      • For IIS-specific configs: Edit the web.config file in your published folder (this is an IIS-specific config file, not your app’s main config) to add rules or modules as needed.
  • 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 update in 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

火山引擎 最新活动