How can I use this kind of mechanism from an dotnet dll rather than a dotnet exe?

[Cyandr]

I have tried this way to invoke my cpp winrt dll from other c# assembly with a test C# exe ,but i have to let my C# exe module to depend on this cpp winrt dll and add a manifist file and add a reference of VCRTForwarders or it will cause a C# System.TypeLoadException. So can I use this invoke machanism from a standalone C# assemly ? Or I didn't use it correctly?

[BenJKuhn]

The registration of the C++ /WinRT component appears in an application manifest. I'm not entirely certain I know what you are referring to by a standalone C# assembly, so I don't know how to give you a more targeted answer, but I'll try to provide some useful input.

The lookup support for the C++ /WinRT registration data and the corresponding type metadata (.winmd) are provided by the manifest and consumed by the operating system. Neither of those two activities are unique to .NET (except that not all programming languages rely on the .winmd at runtime... .NET does). Regardless of how you package your C# assemblies, the initial .exe that you run will need to have an associated file, .exe.manifest describing the types. Short of packaging your application into an MSIX, there's no way around this requirement.

If you're building your C++ /Winrt component DLL for desktop clients only, or can build separate desktop and store versions, you could build with a static CRT dependency to reduce the files you need to bundle. It won't get you down to just one file though. I think at best you can get to three: the exe, the component DLL, and the manifest.

Given what you're trying to accomplish, you may also find that the modern support for MSIX makes it easier to package, distribute and keep your users up to date depending on your situation. This may be easier than trying to push around a bundle of files.

https://docs.microsoft.com/en-us/windows/msix/desktop/managing-your-msix-deployment-overview

I hope that helps.

Ben