Question

我正在处理一个多产品代码库，该代码库有两个独立的C ++ / CLI项目，两者都用于在大型非托管C ++共享＆＃34;核心＆＃34;之间进行Interop。代码和WPF以及ASP.NET UI前端。一个是通用的并且在每个产品中使用（让我们称之为CLI.Interop.Shared），并且一个产品具有用于高度专业化使用的特定项目，我们不希望混淆一般产品（let＆＃ 39; s称之为CLI.Interop.Product）。

CLI.Interop.Shared包含与每个产品相关的代码（例如，将System :: String ^编组为自定义实现的C ++字符串，等等），CLI.Interop.Product具有与单个相关的高度专业化的代码产品。就我而言，这似乎是一个简单而合乎逻辑的分解，但简单性就此结束了。

目前，我们基本上已将CLI.Interop.Shared入侵到CLI.Interop.Product中，方法是将其添加为项目参考，然后将#including标头添加到其中。这适用于纯标头（我们可能需要marshal_as模板用于编组的情况），但是当我们想要更多的互操作时，这个设置基本上不适用于包含保护的任何东西，因为它会覆盖它，因为它是一个单独的汇编，并且编译的C ++ / CLI文件存在阴影问题。

例如，这里是我们遇到问题的地方，我试图在CLI.Interop.Shared中继承一个特定于产品的API：

#pragma once

#include "./FooAPI.h"

msclr
{
    interop
    {
        product
        {
            foo
            {
                public ref class ProductFooAPI :: public msclr::interop::foo::FooAPI
                {};
            }
         }
     }
}

这将生成重新定义问题（C2011）和使用未定义类型（C2027）错误，并且不会编译。我的工作理论是，它只是将所包含的文件中的所有内容转储到新的程序集中，但是当进行比较时，它会产生明显的冲突。此外，这似乎不是支持引用其他C ++ / CLI程序集的方法。

然后我尝试将它切换为＆＃34;正确的＆＃34; （从我可以收集的方式）使用#using和引用.obj文件的方法（将正确的目录添加到其他#using目录）。这个问题没有得到解决，看起来很相似：我对这个已经被导入的符号抱怨了：

Error   14  error C3846: 'FooClass': cannot import symbol from 'c:\checkout\mainrepo\dotnet\libraries\CLI.Interop.Shared\product debug\fooapi.obj': as 'msclr::interop::foo::FooClass' has already been imported from another assembly 'CLI.Interop.Shared'

删除项目参考我已在CLI.Interop.Product中设置CLI.Interop.Shared创建了明显的错误：

 error LNK1312: invalid or corrupt file: unable to import assembly  c:\checkout\mainrepo\dotnet\libraries\CLI.Interop.Shared\product debug\CLI.Interop.Shared.lib

我已尝试直接引用DLL（即#using＆＃34; CLI.Interop.Shared.dll＆＃34;以及#using＆＃34; CLI.Interop.Shared.lib＆＃34;），无济于事。我想我已经尽可能地围绕这个问题进行了讨论。我错过了什么吗？有明显的解决方案吗？是否有一些我无法提及的东西会照亮这一点？我厌倦了使用被黑客入侵的CLI项目！

从另一个C ++ / CLI程序集引用C ++ / CLI程序集

0 个答案: