因此，我继承了一个项目，该项目似乎正在广泛使用Spring.net来进行依赖项注入。每个可执行模块都实现一个方法，在该方法中，它转到给定模块的应用程序配置文件，并沿着assembly://Config/Company.Protocol.Config/DIConfig.xml的行提取一个值，中间位"Company.Protocol.config"对于不同的可执行文件略有不同，具有与项目相似但不相同的名称。该XML文件似乎包含在Config目录中，该目录位于包含该项目的解决方案的基础上。虽然我觉得事情有点过于复杂，但我看到了它们的目的，在DIConfig.xml文件中存储对各种处理例程的引用，以便可以注入它们。
我遇到的问题是，我实际上似乎无法导航到上面指定路径的XML文件，而且我对Spring.net的理解似乎还不足以理解他们计划使用"Assembly://"位的位置。我收到一个Could not resolve resource location错误。我试着联系上一次使用该代码的人，但显然他们也继承了它，并且因为害怕破坏它而避免弄乱它
我认为上面这行的目的是转到程序集的底部，然后转到Config目录或项目，然后在那里获得DIConfig.xml，但当我尝试使用它时，它找不到文件。我试着删除了Config和DIConfig.xml之间的位，以防这是一个问题，因为它们之间曾经有目录，但没有骰子。我可以通过将DIConfig.xml文件放在与可执行文件相同的位置，并将要读取的文件更改为简单的"DIConfig.xml"，从而使其"工作"，因此位于同一目录中，但当然，这不是很容易扩展，尤其是当我试着运行使用它的服务时。
assembly://告诉Spring.net使用"汇编"协议来定位资源。它具有通用格式assembly://<AssemblyName>/<NameSpace>/<ResourceName>。因此，在assembly://Config/Company.Protocol.Config/DIConfig.xml的情况下，应该有一个名为Config的程序集(不一定与项目名称相同；请检查属性)。xml文件包含在保存程序集源的源项目中。
项目中的文件夹可以添加到命名空间中；因此，如果项目的根命名空间是Company.Protocol，那么您将在名为Config的文件夹中找到您的xml文件。
xml文件应标记为嵌入式资源。有关更多信息，请参阅文件的第5.2.2.1节。