将程序集清单直接加载到应用程序上下文中是否正确？(Is it correct to load the assembly manifest directly into the application context?)

 我正在尝试使用免注册COM来运行一个相当纠结的方案。 
 
 并不是它不起作用，而是我遇到了一种令人困惑的情况，我似乎应该直接在应用程序上下文中激活程序集依赖关系的清单，而不是让应用程序上下文指向依赖程序集。 
 
 通过MS自己发布的示例项目很容易解释： 
 
 通常，您有一个应用程序，一个应用程序清单，一个（server-）dll和它的程序集清单。 这些对应于示例给出的内容 ： 
 
 
 
 client.exe 
 
 
 client.exe.manifest（这个指向 SideBySide.X作为dependentAssembly ） 
 
 
 SideBySide.dll 
 
 
 SideBySide.X.manifest 
 
 
 现在，一个标准情况是将客户端应用程序清单嵌入客户端可执行文件中，然后使用DLL及其外部清单文件。 
 
 现在，如果由于某种原因在编译时未知正确的应用程序清单，您可以通过Activation Context API在运行时加载清单文件。 
 
 这就是令人困惑的地方： 
 
 根据文章，客户端应用程序现在直接将其激活上下文切换到程序集清单： 
 
 
 
 如果你查看client.cpp中的_tmain函数...初始化激活上下文的新代码段如下： 
 
 
actCtx.lpSource = "SideBySide.X.manifest";
 
 
 我已经交叉检查了这个，它也可以动态加载包含来自client.exe.manifest的信息的文件，即只是对SideBySide.X的引用，并继续这个激活上下文 - 这也对应于ActCtx在我们将正确的应用程序清单嵌入可执行文件时使用。 
 
 也就是说， actCtx.lpSource = "client.exe.manifest"; 也会奏效。 
 
 TL; DR在应用程序代码中直接激活“包含” 程序集清单的激活上下文（如果有）的含义是什么。 
 
 这是从文件加载清单时应该如何完成的？ （如果是这样，为什么我们不能直接将汇编清单嵌入到可执行文件中，当它在编译时已知。） 
 
 
 注意 :(这应该是对@Eric Brown答案的评论，但它变得相当冗长） 
 
 链接的文章在解释两个RT_MANIFEST资源类型方面做得不错，但是对于regFreeCOm，它留下了一些松散的结尾。 我会抛出一些跳到我身边的引号： 
 
 
 
 ISOLATIONAWARE_MANIFEST_RESOURCE_ID主要用于DLL。 如果dll需要除进程默认值之外的私有依赖项，则应该使用它。 ... NT库加载器检查dll是否具有RT_MANIFEST类型的资源，ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID。 如果是，则加载程序使用资源调用CreateActCtx，并使用生成的激活上下文来探测dll的静态依赖项 。 
 
 
 我理解这意味着RT_MANIFEST/2的唯一要点是静态 DLL依赖加载器找到用于解析DLL依赖关系的正确资源。 （ 不是 COM依赖项，请参阅下文。） 
 
 
 
 有时，您希望在探测dll的静态依赖项之外使用激活上下文。 编译模块时，可以定义宏ISOLATION_AWARE_ENABLED。 
 
 
 定义ISOLATION_AWARE_ENABLED后，Windows会重新定义某些API。 例如，LoadLibraryExW被重新定义为IsolationAwareLoadLibraryExW。 
 
 
 ...并非所有受激活上下文影响的API都会被包装。 例如，......， 也不是任何COM API 。 
 
 
 总而言之：我认为RT_MANIFEST机制主要与regFreeCOM正交，因为COM根本不关心激活上下文的来源，并且没有regFreeCOM wrt的内置帮助。 隔离意识。 

I'm currently trying to get a rather tangled scheme running with registration free COM.
 
It's not that it is not working, it's that I have hit a kind of confusing situation, where it seems I should active the manifest of the assembly dependency directly in the application context, rather than have the application context point at the dependent assembly.
 
It is rather easy to explain by the example project MS themselves publish:
 
Normally, you have an application, an app manifest, a (server-)dll and it's assembly manifest. These correspond to what the example gives:
 
 
 
client.exe
 
 
client.exe.manifest (This one points to SideBySide.X as dependentAssembly)
 
 
SideBySide.dll
 
 
SideBySide.X.manifest
 
 
Now, one standard case is to embed the client application manifest inside the client executable, and then use the DLL and its external manifest file.
 
Now, if for whatever reason the correct application manifest isn't known at compile time, you can load a manifest file at runtime via the Activation Context API.
 
And this is where it gets confusing:
 
According to the article, the client application now directly switches its Activation Context to the assembly manifest:
 
 
 
If you look at the _tmain function in client.cpp ... a new section of code that initializes the activation context as follows:
 
 
actCtx.lpSource = "SideBySide.X.manifest";
 
 
I have cross checked this, and it would also work to dynamically load a file that contains the info from client.exe.manifest, i.e. just the reference to SideBySide.X, and continue with this Activation Context - which would also correspond to the ActCtx in use when we embed a correct application manifest into the executable.
 
That is, actCtx.lpSource = "client.exe.manifest"; would also work.
 
TL;DR What is the implication, if any, of directly activating an Activation Context "containing" an assembly manifest inside application code.
 
Is this how it's supposed to be done when loading manifests from files? (And if so, why can't we directly embed the assembly manifest into the executable, when it is known at compile time.)
 
 
Note: (This should really be a comment to @Eric Brown's answer, but it's getting rather lengthy)
 
The linked article does a decent job of explaining the two RT_MANIFESTresource types, but with regard to regFreeCOm, it leaves a few loose ends. I'll throw in some quotes that jumped at me:
 
 
 
ISOLATIONAWARE_MANIFEST_RESOURCE_ID is used primarily for DLLs. It should be used if the dll wants private dependencies other than the process default. ... the NT library loader checks to see if the dll has a resource of type RT_MANIFEST, ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID. If it does, the loader calls CreateActCtx with the resource, and use the generated activation context to probe the dll's static dependencies.
 
 
What I understand this to mean is that the only point of RT_MANIFEST/2 is for the static DLL dependency loader to find the correct resource to use for resolving DLL dependencies. (Not COM dependencies, see below.)
 
 
 
Sometimes, you want to use the activation context outside of probing the dll's static dependencies. You can define macro ISOLATION_AWARE_ENABLED when you compile the module. 
 
 
When ISOLATION_AWARE_ENABLED is defined, Windows re-defines certain APIs. For example LoadLibraryExW is redefined to IsolationAwareLoadLibraryExW.
 
 
... Not all APIs affected by activation context are wrapped. For example, ..., and neither is any of the COM APIs.
 
 
So, to sum up: I think the RT_MANIFEST mechanism is mostly orthogonal to regFreeCOM as COM doesn't care at all where it's activation context comes from and there is no built-in help for regFreeCOM wrt. Isolation Awareness.

原文：https://stackoverflow.com/questions/19381348