我目前正在将 VB.NET 网站迁移到 VB.NET Web 应用程序。以前我会将所有组件 DLL(第 3 方类库)存储在 bin 文件夹中,它们会在运行时进行编译。我已经在我的新应用程序中手动添加了对 DLL 的引用,但是 bin 文件夹是存储这些附加 DLL 的理想位置吗?这是否被认为是最佳实践,当我创建新版本时它会干扰应用程序生成的 DLL 吗?
抱歉,如果这是一个非常基本的问题,我对 Visual Studio 中的 Web 应用程序概念不熟悉。
我目前正在将 VB.NET 网站迁移到 VB.NET Web 应用程序。以前我会将所有组件 DLL(第 3 方类库)存储在 bin 文件夹中,它们会在运行时进行编译。我已经在我的新应用程序中手动添加了对 DLL 的引用,但是 bin 文件夹是存储这些附加 DLL 的理想位置吗?这是否被认为是最佳实践,当我创建新版本时它会干扰应用程序生成的 DLL 吗?
抱歉,如果这是一个非常基本的问题,我对 Visual Studio 中的 Web 应用程序概念不熟悉。
作为一般规则,我从不直接将任何东西放在 bin 文件夹中。我总是允许构建过程将 dll 或其他文件复制到 bin 文件夹中。
如果添加引用,并确保“本地复制”设置为 true,则 dll 将在构建期间被复制。这有许多优点,尤其是在使用版本控制时。
至于你应该把这些文件放在哪里,我通常在解决方案级别创建一个文件夹并将 dll 放在那里,然后我将它们作为该位置的引用添加。这使它们可以轻松地检查到版本控制中(并像许多版本控制系统一样标记为只读)。
将文件检入 bin 文件夹中的版本控制时,您会遇到很多问题。另一个问题是当您需要“清理” bin 文件夹时,其中的文件可能会导致问题。如果您使用我描述的方法,您可以随时删除 bin 文件夹中的所有文件。
更好的方法是使用 NuGet 包。如果所需文件不属于现有 NuGet 包,则可以创建自己的文件并运行自己的本地 NuGet 服务器。
不,它不会干扰应用程序生成的 dll。
如果这些是您在很多应用程序中使用的 dll,您可以考虑在 GAC 中注册它们。
将它们放在 bin 中可以轻松部署(只需复制 Web 应用程序文件夹),如果您处于无法在 GAC 中安装 dll 的共享托管环境中,这可能是您唯一的选择