希望是直截了当的。我正在查看一个 C# 产品，由于 Xamarin，它注定可能具有桌面 (WPF)、Web 和任意数量的移动构建输出。
有几个组成部分:
- 我有一个“CoreApi”项目，它具有接口(interface)和共享模型，可以调用它们来编写任何应用程序前端(并实现以编写后端)。
- 我还在另一个程序集中拥有所有“应用程序逻辑”——目前采用与 MVVM 模式中的 View 模型类似的样式，但以应用程序为重点。
- applogic 中包含一个特定于平台的接口(interface)实现，它与动态生成用于播放的音频缓冲区有关。也将项目/程序集分开
我正在使用 Ninject，它运行良好。但随着解决方案的发展，包括其他项目类型(网络、移动客户端)，我可以预见到一些“味道”:
目前，客户端项目引用了特定于平台的 (DirectX) 音频引擎和后端的本地/测试实现。它仍然使用 Ninject 并且不直接引用实现类，但是让它们可访问并像那样直接引用感觉是错误的。
我几乎想在构建解决方案时拥有不同的“包”:
- 套餐一:桌面客户端+DirectX引擎+后端X
- 包 2:带有后端 Y 的 Web 部署包
- 套餐三:Android版，后端X + Android音频引擎...
我走在正确的轨道上吗？我真的想求助于构建后步骤，将内容复制到目标文件夹吗？
最佳答案
我会考虑使用 MSBuild 功能来执行必要的复制。我采用了使用 dependency.proj 文件的方法，您可以配置这些文件以根据您选择设置的任何配置选项执行适当的复制操作，例如您可以根据配置和 CPU 类型将特定文件复制到输出文件夹中。我不提倡使用旧式的后期构建步骤，因为这些步骤不可靠且难以调试。在我看来，MSBuild 是前进的方向。
关于c# - 正确的 DI 项目/build设置，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15790348/