我的发布站点部署在不同的专用服务器上。通常，我们从客户端接收页面级别的更改，这需要更改客户端和服务器端代码，我们首先在本地完成更改，然后我在服务器上部署带有服务器端代码的页面，而无需完整发布构建代码，因为我的客户一次又一次地要求进行微小的更改，当客户对页面更改感到满意时，我将发布版本放在服务器上。我想知道发布和非发布代码部署的主要区别是什么？当我将带有 aspx.cs 的 aspx 放在服务器上时，它工作正常，那么为什么部署发布版本很重要。
【问题讨论】：
标签： asp.net .net asp.net-mvc webforms
当我将 aspx 和 aspx.cs 放在服务器上时，它工作正常，那么为什么会这样 部署发布版本很重要。
这主要是效率问题。当您将服务器上的 ASPX 和 ASPX.cs（代码隐藏）文件并排放置在一起时，当有人第一次请求该页面时，该代码隐藏文件将被编译成它自己的程序集（.dll 文件）。您实际上是将源代码推送到您的服务器，而不是编译后的代码。如果对每个 ASPX 文件执行此操作，最终可能会得到数十到数百个单独的程序集（每个 ASPX 文件一个程序集），并且一个缺点是编译器首先将源代码转换为二进制 dll 时的延迟。另一个是您的服务器必须管理大量程序集，而不仅仅是一个。
当您部署发布版本时，编译器会将您的所有代码隐藏文件合并到一个程序集中。它还会稍微改变 ASPX 文件中的 @Page 指令。您最终没有将源代码部署到服务器，只有一个二进制 DLL，这样效率更高。
因此，如果您只进行 ASPX 更改（例如样式、纯 HTML 等），则可以单独推出这些更改，只要 @Page 指令与预编译和已部署的代码隐藏相匹配。但是，当您同时更改 ASPX 和代码隐藏时，您应该进行发布，因为它会导致不同的合并代码隐藏程序集，必须将其部署到服务器上的 bin 文件夹。
有时我要做的是将 ASPX 和代码隐藏一起部署以在服务器上测试某些东西，一旦我确定它可以工作，返回并执行发布部署以将代码隐藏更改烘焙到合并的 DLL 中。然后只需将它们推送到文件（dll 和 ASPX），删除代码隐藏源，然后完成。
【讨论】：