这个 .tlh 文件是否正确，如果不正确，那么如何生成正确的文件？

我试图从非托管 C++ 代码调用 .NET 4.0 dll。

我按照中的说明进行操作

我构建了 .NET dll，并遵循了所有步骤，包括使用 regasm 注册它。

接下来，我创建了一个非托管 C++ 项目，并在 .cpp 文件的开头添加了这一行：

#import "D:\PathToMyCSharpProject\bin\Debug\com.DeviceServices.tlb" rename ("EOF","adoEOF") no_namespace named_guids raw_interfaces_only

当我构建 C++ 项目时，在 D:\MyCPlusPlusProject\Debug 中创建了一个 .tlh 文件。

接下来，我添加了 CodeProject 文章建议的代码，该代码尝试创建指向 C# 库中的对象的指针。

CoInitialize(NULL);   //Initialize all COM Components

// <namespace>::<InterfaceName>
MyCSharpNamespace::IMyCSharpInterfacePtr pMyCSharpInterfacePtr;

“MyCSharpNamespace”是我在 C# 项目中使用的命名空间。

当我构建 C++ 项目时，我现在收到编译错误：

错误 2 错误 C2653：“MyCSharpNamespace”：不是类或命名空间名称

还有其他错误，因为它无法识别 IMyCSharpInterfactPtr。

于是，我查看了.tlh文件，内容如下：

// Created by Microsoft (R) C/C++ Compiler Version 10.00.40219.01 (6478e0c7).
//
// MyCPlusPlusProjectPath\debug\com.deviceservices.tlh
//
// C++ source equivalent of Win32 type library MyCSharpProjectPath\bin\Debug\com.DeviceServices.tlb
// compiler-generated file created 05/27/14 at 11:52:16 - DO NOT EDIT!

#pragma once
#pragma pack(push, 8)

#include <comdef.h>

//
// Forward references and typedefs
//

struct __declspec(uuid("961b3c24-98f2-400e-8bea-ab357a18d851"))
/* LIBID */ __MyCSharpProject;

//
// Named GUID constants initializations
//

extern "C" const GUID __declspec(selectany) LIBID_MyCSharpProject =
    {0x961b3c24,0x98f2,0x400e,{0x8b,0xea,0xab,0x35,0x7a,0x18,0xd8,0x51}};

#pragma pack(pop)

我在互联网上搜索以找出 .tlh 文件中应该包含的内容，并发现msdn 上的 #import 页面。 http://msdn.microsoft.com/en-us/library/8etzzkb6.aspx

它表示 .tlh 文件的内容应包括智能指针声明（即 IMyCSharpProjectInterfacePtr）和 typeinfo 声明，这些声明不存在于我的 .tlh 文件中。

MyCSharpProject 声明了一个公共接口，包括生成的 GUID，构建正确，并且我从本文中遵循的所有步骤似乎都是成功的。

所以，我的问题是，有人可以建议为什么这些定义不存在于我应该存在的 .tlh 文件中吗？

.tlh 文件不会有错，它是从 COM 服务器的类型库自动生成的。一个明显的缺陷是它相当空，你根本看不到任何声明。

问题出在 Codeproject.com 的那篇文章上，与此类项目中的课程一样，它缺少一个重要的步骤，没有解释到底发生了什么，而且经常使用非常糟糕的做法。为了使 .NET 类型可以从 COM 客户端使用，您必须明确使其对 COM 客户端可见。将此属性添加到您要导出的每种类型：

  [ComVisible(true)]

将其应用于接口和类。

正如作者建议的那样，使用 [Guid] 属性是非常危险的。在开发库时将其保留在适当的位置是可以的，它有助于避免注册表污染并让您跳过 Regasm 步骤（并非总是如此），但在交付库之前再次删除它非常重要。 COM 中的一条硬性规则是，对接口的修改需要新的 GUID，这是一种基本的 DLL Hell 对策。当您将其交给 CLR 自动生成时，您会自动获得一个新的。

在开发时最好避免在 GAC 中注册程序集，因为在 GAC 中留下程序集的陈旧副本会导致太多事故。使用/codebaseRegasm 命令中的选项，因此不需要这样做。您可以忽略收到的警告。