我们有一个用ASP.NET MVC编写的应用程序。
现在我们写了Common DB上下文＆amp;本应用程序所需的实体模块（2个项目/类库）。同样的DB上下文和实体也将是另一个应用程序的一部分。
现在我的问题是如何将这个共同的项目添加到我们的应用程序中。
我们应该将其添加为DLL，还是应该将它们添加为每个解决方案中引用共同项目的单独项目。上述方法的任何优点。或者如果有更好的处理方法。
谢谢jas
这在很大程度上取决于这些应用程序如何共同增长。您有可能在数据应用程序中进行更改，以破坏其他应用程序中的消耗代码？如果这可能经常发生，我将将所有这些项目保留在相同的解决方案和存储库中，并使用项目参考。这使重构变得更加容易，因为Visual Studio将了解所有下游依赖性中给定类别或成员的所有用法。
但是，如果此时数据层已经很好地硬化了，并且您可能需要使用它的不同版本部署不同的应用程序（我发现这不太可能），那么您应该将数据项目部署为Nuget软件包。这样，每个应用程序都可以指定其知道哪个版本，并且可以确保其与指定的版本始终兼容。
我同意其他评论者/答复者的观点，您不应直接创建对DLL的依赖性。这是一种真正的老式方式，可以通过较新版本控制技术进行管理不佳的事物。
宁愿在同一解决方案中使用一个单独的项目，或者在最坏的情况下，您可以使用一些自定义注册来创建一个Nuget模块，您需要根据需要添加到每个项目中。
目前我在自己的项目中所做的就是这样。
Solution
App.Data
App.API
App.ServiceWorker
... API＆amp;服务工人然后将我们的超级通用模块（内部）通过nuget分发以重复使用（但请确保它们能够作为孤立的作品起作用）...以 @Masosn的评论重新熟悉，不要只需避免使用绘图DLL即可。
理想情况下，您想引用库项目，而不是dll。您可以将所有项目保留在同一解决方案中，或者像其他人一样使用私人Nuget存储库。
但是共享DbContext不是一个好主意，因为一旦您有了新的迁移，所有使用共享DbContext的项目都必须重新部署。这也不是一个好主意，因为您不希望多个项目对数据存储中的数据负责。
尽管这可能需要一些重组，但您可能需要研究微服务架构。每个微服务仅负责其数据存储。