实现ASP。NET核心应用程序
近年来，微软一直在大力宣传ASP。网Core framework作为ASP.NET的未来。ASP。网Core is of interest to web professionals on the Microsoft stack. If you’re running web applications on Windows and want to make the upgrade, what are the gotchas? Is the transition to the latest and greatest paved and smooth?
在这篇文章中，我将深入探讨当您升级到ASP时可能会遇到的常见陷阱。NET Core -假设你渴望进行转换。作为开发人员，能够获得让您的工作更轻松的新工具总是令人兴奋的。
对于本文，我将使用“ASP。网classic” to refer to the legacy ASP.NET framework. I’ll use “ASP.NET Core” to refer to the standard framework Microsoft makes available to ASP.NET developers.
微软在开发ASP方面取得了积极的进展。NET Core跨平台。新工具可以在Linux、macOS和Windows上运行。知道后端代码现在可以在任何地方运行可能会让人感到欣慰。这将使开发人员不必在Windows系统上编写代码。可用的新工具可以满足您的个人喜好。
来自ASP。网classic, a valid assumption is that you’re on the Windows platform. To you, going cross-platform may not be relevant right at this moment. Up until now, ASP.NET classic has been a first-class citizen and exclusive to Windows. This tight integration with Windows and IIS, of course, is both a blessing and a curse.
那么，ASP。网Core mean for developers on Windows Server and IIS? Now that ASP.NET Core is cross-platform, what are the implications?
依赖地狱
与IIS解耦的一个自然后果是依赖关系的激增。ASP。网Core runs on Kestrel, a separate process that responds to HTTP requests. This means the framework leans on a bunch of dependencies where IIS once stood. These dependencies are basic NuGet packages you can download from the internet.
ASP。网Core, NuGet is the canonical way to get dependencies. In fact, most of the tooling is now a decoupled NuGet package you can add as a dependency. The tooling you install on your local dev box is only a shim. The intent is to get your app to be self-contained with all its dependencies. The majority of ASP.NET Core comes in modular NuGet packages you plug and play.
这是对与IIS紧密耦合的旧单片框架的全新尝试。ASP。网Core is cross-platform and means it. What was once leaning on colossal IIS and Windows installs is now reduced to a NuGet package. This makes the framework nimble and more flexible. It’s easier to change a small NuGet dependency than installing modules on your web server.
但是，通常情况下，有一些陷阱:
- 在本地开发机器上，团队看到一个包含1GB依赖项的NuGet packages文件夹。
- 如果构建服务器位于防火墙之后，则需要上传每个微小的依赖项—这是一个乏味的过程。
- 默认情况下，该工具会引入元包，这些元包可能具有无关的依赖关系。
元包的一个缺点是，如果你在Windows上，你会看到奇怪的依赖关系，比如:
将Linux和macOS运行时作为依赖项包含进来并不常见，因为您只希望在Windows上运行它。然而，如果您想要通过构建，这是必要的。有一种方法可以减少依赖占用，但是不太实用在企业环境中。很少有专业人士有时间调整一个gig值的微小依赖项。希望该工具将来能做得更好，并为您规范化依赖关系。
在构建服务器上获得成功的构建存在一定的挑战。我和我的团队都觉得这就像我们没有准备好的过山车一样。在ASP团队中一个可爱的代号。网Core was “Fat Lady”, because of all the dependencies.
这给我们留下了一个问题。如何将这个相当大的框架放到web服务器上?
自动化部署
如果您的团队在ASP上有工作部署。网classic, you’ll see that a lot has changed. ASP.NET Core uses a new set of tools for deployments.
来自ASP。网classic, the hope was that deployments were reusable. In automation, there’s a set of scripts you use to get changes onto a web server. The scripts that run in automation are often called a deployment pipeline. In Windows, this means PowerShell scripts to ensure reliable and predictable deployments. Having reusable pipelines is one way to ensure consistent deployments.
ASP。网Core tooling uses a separate set of command line tools to create a deployment package. There are nuances with this that will force you to create a new deployment pipeline. For example, MS Build was the CLI tool of choice for ASP.NET classic deployments. With ASP.NET Core, there’s adotnet发布命令创建包。两人之间的细微差异使团队进入了一个新的管道。不幸的是，许多现有的自动化是不可重用的。
ASP的自动化。网classic made assumptions that were no longer valid. For us, the goal was to gather together the bare necessities for a good deployment. This took an all-hands-on-deck approach to flesh out all the necessary details.
微软在最近发布的ASP。NET Core新增支持MS Build．考虑到时间框架，我们现在宣布这个消息有点太早了。一个想法是审查部署需求之前你深入研究ASP。净的核心。调查现有管道的哪一部分是可重用的。
IIS上的情况大致相同:有很多变化。Windows Server和IIS需要一个新的ASP模块。NET Core应用程序工作。一个很好的解决方案是分离ASP。网Core apps from classic legacy apps. The HTTP module necessary may have a negative impact on ASP.NET classic. On a live server, make sure you apply latest patches and have time to sort out any issues while the server is down. There are指导你开始建立ASP。asp.net Core在IIS。
既然胖夫人(ASP。网Core) is happy and running, what other pitfalls are there?
托管代码与非托管代码
对于自动化，一个常见的缺陷是将应用程序池设置为托管代码。在ASP。网Core, this is one piece of configuration you cannot reuse. One issue that kept cropping up during deployments was setting the app pool to the wrong mode. If you do so, you’ll see a process failure with a 502 error.
可能引起混淆的是ASP。网Core runs on top of the standard framework. ASP.NET classic, for example, runs on the classic framework and in managed code. In ASP.NET Core and IIS, the process that hosts your web application does not run on any framework. ASP.NET Core runs in a separate process, decoupled from the standard framework.
确保将应用程序池设置为非托管代码。当你双击应用程序池时，它应该是这样的:
IIS运行ASP。网Core apps as an external process through a reverse proxy. This is because it no longer has this tight integration with IIS and is cross-platform. The web server uses an HTTP module to track the process. ASP.NET Core has all the middleware necessary to send the HTTP response, it no longer depends on IIS.
ASP。网Classic Dependencies
任何不在ASP上的依赖。NET Core会有后果。在依赖项列表中，您可能会发现一个依赖于ASP的依赖项。净经典。任何依赖于ASP的东西。网classic needs the entire legacy framework for it to work.
微软已经在无缝过渡方面取得了长足的进步。对于外部流行的依赖项，您经常会发现与ASP一起工作的包。净的核心。ASP。网Core framework has many of the same packages already familiar to you. This makes the upgrade a lot more practical and attainable.
例如，ASP。网Core has packages for Entity Framework, Dapper, and ADO.NET. These packages are like their counterparts in ASP.NET classic.
对于内部依赖关系，情况则完全不同。如果依赖项没有ASP。NET核心端口，你将需要ASP。净经典。ASP。网Core and ASP.NET classic are exclusive. This is often a blind spot for teams looking to move to the shiny new framework.
一个好的方法是评估你的依赖项列表，找出哪些依赖于哪些。找出依赖关系的层次结构，并深入到依赖关系的依赖关系中。这样你就能提前知道接下来会发生什么。这个想法是为了减少在部署过程中以不可预测的方式表现的意外。
如果您仍然需要ASP。网classic because of dependencies, it is possible to run ASP.NET Core on the legacy framework. But,这就增加了风险你的部署，比如处理身份验证饼干．
一个问题是，您期望依赖项的默认行为将会改变。当连接ASP。网Core dependencies, make sure you’re not making any assumptions. For example, the身份验证饼干有一组不同的默认设置。ASP。网Core is in some cases a complete rewrite, so a safe assumption is that default behaviors will change. Don’t make any of the same assumptions you made in ASP.NET classic. Test and verify all your dependencies.
结论
总的来说，使用ASP得到的新框架。NET Core非常灵活。作为开发人员，您将获得更好的编码体验。工具简化了框架，并且可以从Visual Studio外部访问。与Windows和IIS解耦是朝着正确方向迈出的一步。
ASP。网Core, you’ll find a leaner framework with less cruft. I find the CLI tooling refreshing and very effective. For example, to run all unit tests, dodotnet测试并在不到一秒的时间内得到即时反馈。在Visual Studio中，没有必要为了获得反馈而点击和沮丧。当你有一堆测试时，Visual Studio中的反馈通常很慢。一般的编码经验来自于一个极简的现代框架。
ASP。网Core MVC framework comes with improvements. Web API and MVC are now a single framework. You inherit from a single controller to use both. There’s no confusion in determining which one to use, which makes it more effective.
就像所有新事物一样，一头扎进去是有后果的。我希望这篇文章指出了您至少应该考虑的常见陷阱。在开始这段新的冒险之前，最好先知道自己要面对什么。
SitePoint上的更多资源:必威西盟体育网页登录
