This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(32, 44%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERC%3C/text%3E%3C/svg%3E)
In C++, I use #import ". \PptInterface.tlb" to call the functions in the C# class library I generated, provided that PptInterface.dll and PptInterface.tlb are available in the current program directory.I am confused, however, in that when going to a new computer to use this function, it is necessary to reuse RegAsm.exe to do the same thing to the DLL. RegAsm.exe to register the DLL so that the COM interface of the program can call the function properly. I don't want to have to register the DLL every time I go to a new computer, is there a good way to do this?
For example, it is possible to activate the “Common Language Runtime Support” option in C++ applications, or create C++/CLR projects, where the C# Class Libraries can be referenced using the Add Reference dialog. (COM Interfaces are not needed in this case).
Since my program requires the "Multi-Threaded /MT" compilation option (just so I don't have a missing DLL on the target computer), I can't use C++/CLR.
Maybe the “Multi-threaded” options are not relevant in this context.
I'm not sure my translation software translates accurately, sorry. But the "Multi-Threaded /MT" compilation option described above refers to this option in the picture.
This is the Chinese language version, and I think he's in the same place as the English version, presumably.
Since my program requires the "Multi-Threaded /MT"
Perhaps you mean that you are linking with the static CRT library (/MT) instead of using the CRT dynamic link libraries (/MD).
I have put together a demo for you that uses registration-free COM from a native C++ application to instantiate a COM object hosted in a .Net Framework 4.8 C# class library. The demo is contained in CSRegFreeComServer.zip and it can be downloaded from https://1drv.ms/u/s!AmnqrCFBv4nDhBoobsLB-8I5_MSE?e=HXGeHI
Before you extract the contents of the CSRegFreeComServer.zip file make sure to unblock it -
The demo solution contains a .Net Framework 4.8 C# class library project that exposes a COM object (CSRegFreeComServer.csproj). The project has been configured so that the manifest required for registration-free COM will automatically be embedded in the resultant DLL. The DLL is built using the AnyCPU platform so that it can be loaded by a 32-bit or 64-bit COM client application. DO NOT USE RegAsm with this DLL. The C++ project described below will handle type library creation.
The project contains the following Registration-Free COM Manifest -
The solution also contains a C++ project for a COM client application (CppClient.vcxproj). This project has been customized to accomplish several tasks that are specific to the sample:
The registration-free COM manifest entries needed for the C++ project are provided directly in the project properties as seen here -
Thank you for your reply, I am just now logging in due to difficulties in my area for logging into this site, I apologize. I will get back to you when I have researched this, thank you.
@RLWA32 Thanks, I downloaded the file you shared and this demo worked fine. Next I tried to replicate it in my project, but it reported an error when I finished:
I changed the solution properties but CSRegFreeComServer.tlb is not generated when compiling, what is going on? Comparing the generated records, I see that they are missing:
2>Microsoft (R) .NET Framework Assembly to Type Library Converter 4.8.3928.0
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>All rights reserved.
2>Assembly exported to 'H:\Download\CSRegFreeComServer\CSRegFreeComServer\CppClient\Release\CSRegFreeComServer.tlb'
@RL Chen What was the error that was reported in the Application Event log?
I changed the solution properties and when I run it CSRegFreeComServer.tlb has been generated correctly, but the above problem occurs.
The type library generation is unrelated to a run-time, manifest related error.
The C++ project property for "Additional Manifest Dependencies" as shown in my answer will automatically add what the .exe needs. The version number must exactly match the version of the C# class library. The name and version fields must match the like entries contained in the C# manifest's assemblyIdentity section.
The manifest for the C# class library is a file in the demo project and is also reproduced in my answer above.
The C# COM server class library should be in the same folder as the C++ .exe COM client. The demo project takes care of this. Have you done the same in your own project?
I'm happy to help you but you need to provide more detailed information or share your own demo with me that reproduces the errors. After all, I don't know what was done to replicate my demo in your own project.
@RLWA32 Sorry for updating my description as I tried some content on my own, not enough for me to confirm that the description I ended up questioning was the one below:
I changed the solution properties but CSRegFreeComServer.tlb is not generated when compiling, what is going on? Comparing the generated records, I see that they are missing:
2>Microsoft (R) .NET Framework Assembly to Type Library Converter 4.8.3928.0
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>All rights reserved.
2>Assembly exported to 'H:\Download\CSRegFreeComServer\CSRegFreeComServer\CppClient\Release\CSRegFreeComServer.tlb'
Well, now I'm not sure what you are experiencing. First you wrote about a run-time error and then you edited your post to completely change its focus to something else.
Next I tried to replicate it in my project, but it reported an error when I finished:
This kind of feedback doesn't provide any information. You need to post specific errors and related error codes and text.
The C++ project contained in my demo will only extract a type library from the C# class library if it does not already exist or if the C# class library has been updated. This is to avoid performing this task needlessly every time you build the demo or compile the C++ project. The demo C++ project has a reference to the C# class library project so that Visual Studio creates a build dependency to ensure that building the solution always builds the C# class library first.
Don't forget that in my answer I described how the C++ project was customized. If you have not looked at the contents of the demo project's .vcxproj file and replicated those customizations in your own project then it will not perform identically to the demo. The customization was done to simplify what was needed for a demo of a registration-free C++ COM client/ C# COM server class library. However, you can still perform the same steps manually if needed
@RLWA32 Maybe my translator didn't translate what I expressed accurately. I was imitating and learning from the project you wrote, but when I finished, the project didn't compile correctly. Due to more information, I am placing the test project I wrote directly below, please help me to see what is wrong there and let me know, thank you.
Thanks for sharing your solution/projects. After looking at them I have the following observations and took the described actions.
The C# project does not embed the registration-free COM manifest in the generated assembly (CSRegFreeComServer.dll) during the build process. I have corrected the .csproj file accordingly. In the future for a registration-free C# Com server class library you can use Visual Studio to add an application manifest. The added manifest is applicable to a .exe and you should replace its content with the manifest entries required for registration-free COM. In the demo project, after I replaced the content I renamed the manifest file since I found the name "app.manifest" to be confusing for a class library project.
The C++ project did not have a reference to the C# class library project to ensure proper build behavior for the solution. I added the reference.
The C++ project Linker properties only contained the required registration-free COM information in "Additional Manifest Dependencies" for a 32-bit Release build. I added the entries for 32-bit Debug and both 64-bit Debug and Release.
The C++ project customization extracts the type library to the projects Intermediate Directory. The appropriate Visual Studio macro called $(IntDir) was added to the Additional Include Directories property so that the type library can be found when building.
The C++ project omitted virtually all of the customization that was made in my demo. I have updated your C++ project to correct these omissions.
I suggest you run a file comparison utility to display the differences between your .vcxproj and .csproj files and the ones that include the changes that I have made for you.
Your updated files can be downloaded from https://1drv.ms/u/s!AmnqrCFBv4nDhBxp7kD5tlty_xA0?e=dy8VdM
I set the manifest exactly as you did and found that it still won't generate a tlb. finally I found that CppClient.vcxproj is not the same. How do I set it up? Which property page do I set it up on? I think the current situation is as if my project doesn't find the no-registration manifest.
By way of comparison, I realized that my own project seems to be missing these parts below:
<ItemGroup>
<ProjectReference Include="..\CSRegFreeComServer\CSRegFreeComServer.csproj">
<Project>{66f84848-5c28-4398-80d7-78f6189fc442}</Project>
</ProjectReference>
</ItemGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
<ItemGroup>
<SrcFile Include="$(SolutionDir)CSRegFreeComServer\bin\$(Configuration)\CSRegFreeComServer.dll" />
<TlbFile Include="$(IntDir)CSRegFreeComServer.tlb" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\CSRegFreeComServer\CSRegFreeComServer.csproj">
<Project>{f33abf92-e01f-4e05-b8cb-493285c2d066}</Project>
</ProjectReference>
</ItemGroup>
<PropertyGroup Condition="'$(Platform)'=='Win32'">
<TlbPlatform>win32</TlbPlatform>
</PropertyGroup>
<PropertyGroup Condition="'$(Platform)'=='x64'">
<TlbPlatform>win64</TlbPlatform>
</PropertyGroup>
<!-- Copy .Net Framework assembly to C++ project output directory -->
<Target Name="CopyCSRegFreeComServer" AfterTargets="Build;Rebuild">
<Copy SourceFiles="@(SrcFile)" DestinationFiles="@(SrcFile -> '$(TargetDir)%(FileName)%(Extension)')" />
</Target>
<!-- Create 32-bit or 64-bit type library from .Net Framework assembly for #import directive -->
<Target Name="CreateCSRegFreeComServerTlb" BeforeTargets="ClCompile" Inputs="@(SrcFile)" Outputs="@(SrcFile -> '$(IntDir)%(FileName).tlb')">
<Exec Command="%22$(SDK40ToolsPath)TlbExp.exe%22 %22@(SrcFile)%22 /silence:131175 /$(TlbPlatform) /out:@(TlbFile)" />
</Target>
<!-- Delete .Net Framework assembly from C++ project output directory -->
<Target Name="CleanCSRegFreeComServer" AfterTargets="Clean">
<Delete Files="$(TargetDir)CSRegFreeComServer.dll" />
</Target>
</Project>
Did you download and build using the update with corrections that I provided? It worked flawlessly for me.
As I said earlier, you omitted the necessary project customizations.
I have compared the new project you gave me and am working on the problems of my original project, as you said "As I said earlier, you omitted the necessary project customizations.", my actual problem is that I My actual problem is that I don't know how to set the "registration-free COM manifest", then I compared the property differences (as in the xml above), so I would like to know how to specifically set the "registration-free COM manifest" in the VS property page, the manifest is correct.
Thank you for your patience, after my research the problems were all solved. Thanks again.
@RLWA32 Next a new problem arose, now my program has the correct DLL and works fine, but as soon as the DLL is missing an error is reported:
[Window Title]
C:\Users\AlanCRL\Desktop\智绘教.exe
[Content]
C:\Users\AlanCRL\Desktop\智绘教.exe
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
[OK]
I would like to somehow, that is, not check the DLL status before the main function is passed in, because if the DLL is missing, I will make it up for the user after the program is started and then load the DLL. What should I do?
Next a new problem arose, now my program has the correct DLL and works fine, but as soon as the DLL is missing an error is reported
I would like to somehow, that is, not check the DLL status before the main function is passed in, because if the DLL is missing, I will make it up for the user after the program is started and then load the DLL.
Any application will fail to start if a DLL that is required at load-time is missing.
If your application, including the dll, has been deployed to a computer other than your own development system and the dll is missing how could you replace it and load a new copy?
In my opinion the best protection against this kind of problem is to deploy the application to a protected file system location such as a sub-folder of C:\Program Files. While this requires the installation to be performed with Administrator privileges it also prevents users from deleting or moving your application's individual files afterwards.
Isn't there any option to make the program startable first, rather than forcing a DLL status check. I don't know if lazy start can be applied here.
You haven't answered my question about how your proposed solution would solve the missing dll problem on a machine other than your own.
If your application, including the dll, has been deployed to a computer other than your own development system and the dll is missing how could you replace it and load a new copy?
I think when my program loses the dll he needs, if I can start it first, the program will write the copy dll from the program resource file to the local directory in the first place, and then load it, so it's no problem.
I think when my program loses the dll he needs, if I can start it first, the program will write the copy dll from the program resource file to the local directory in the first place, and then load it, so it's no problem.
Applications don't suddenly "lose the dll he needs". A properly handled deployment can prevent such "accidents" or repair an installation of needed.
If you simply copy application files to unprotected file system locations then they are subject to mistakes (file deletion/moving) made by users and to malware that can act without privilege escalation.
However, if you are committed to following this path then do not add the registration-free manifest information to the C++ COM client. Management of activation contexts then becomes your responsibility. That is a different subject and if you want to pursue it you should ask a new question.
Yeah, I guess I should ask a new question, that's all. Because my application deploys automatic updates, older users will not be able to run it due to the lack of this DLL. But I'm having trouble asking the question because unlike other DLLs, which can be lazily loaded, C# class libraries cannot. So I need a solution to this problem. If it doesn't work then forget it.
unlike other DLLs, which can be lazily loaded, C# class libraries cannot
In this case don't think of it as loading a C# class library. It is the presence of the registration-free COM manifest information in the C++ COM client that causes the system to look for the dependent assembly at load-time.
Without that manifest information the system will start the C++ client whether or not the C# COM server is present.
Management of activation contexts means that it is now up to you to do what had been previously handled automatically by the system. You are now responsible for creating the activation context required by COM to instantiate COM objects from your in-process server at run-time.
I don't quite understand what you mean. The current situation is that when I give the exe and the DLL together, the software starts and works fine. However, assuming the DLL is removed, the program will not start and will report an error.
[Window Title]
C:\Users\AlanCRL\Desktop\智绘教.exe
[Content]
C:\Users\AlanCRL\Desktop\智绘教.exe
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
[OK]
My goal is to make the program startable without the DLL.
It seems that I'm having problems accessing this site and I'm not sure if the previous question was sent successfully, so I'm sending it again.
I don't quite understand what you mean. The current situation is that when I give the exe and the DLL together, the software starts and works fine. However, assuming the DLL is removed, the program will not start and will report an error.
[Window Title]
C:\Users\AlanCRL\Desktop\智绘教.exe
[Content]
C:\Users\AlanCRL\Desktop\智绘教.exe
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
[OK]
My goal is to make the program startable without the DLL.
I think there is another viable option, which is to embed the dll directly into the exe and then reference the embedded DLL, any options?
Earlier I wrote "It is the presence of the registration-free COM manifest information in the C++ COM client that causes the system to look for the dependent assembly at load-time. Without that manifest information the system will start the C++ client whether or not the C# COM server is present."
In the CppClient project remove the highlighted information added to the "Additional Manifest Dependencies" project property as shown below -
After this is removed and you build CppClient again then the executable will always run.
However, without the manifest information the system will no longer create the runtime support needed by COM to find and instantiate the C# COM server. Consequently, the C++ Client will fail to instantiate the COM object.
It is now your responsibility to provide COM with what it needs to load your C# Com Server and instantiate its COM object. This is what I referred to as "Managing the activation context". You can refer to Using the Activation Context API.
I think there is another viable option, which is to embed the dll directly into the exe and then reference the embedded DLL, any options?
Even if you embed a DLL into a native C++ executable as a resource it must still be written to disk for it to be used. And you would still need to handle the activation context issue.
Using this API is a good option, but I don't know how to write detailed code to solve this problem, can you help me? Goal: To start a program without a DLL and then load COM components and use them via this API. Thank you very much~
This thread has gotten very long and has also digressed from the initial focus.
You should read the documentation and make an effort to implement your solution. I understand this is new to you so feel free to ask questions as you progress. I'm happy to help you as you go along.
Please don't append new questions to existing posts for which answers have been accepted. New questions should be a separate post to be more visible to the community.
Sorry, I seem to have forgotten about this as well as being off center. The reason why I have been pursuing this is because I think your answer has helped me immensely and solved a lot of difficult problems. I am here to express my sincere gratitude to you! A new question has been posted, feel free to come and answer it at https://learn.microsoft.com/en-us/answers/questions/1389449/how-to-dynamically-load-a-registration-free-com-dl.
If you are deploying an in-process COM server (DLL) you can use registration-free COM to avoid having to register the DLL on systems to which it is deployed.
Refer to How to: Configure .NET Framework-Based COM Components for Registration-Free Activation
Thanks for the answer, but I'm still not quite sure, because I'm using COM to call C# class libraries in C++, and I need a more realistic description.
I need a more realistic description.
Did you completely read the document in the link provided as well as the other documentation linked to in its See Also section?
If you don't understand something then ask specific questions about it.
From Registration-Free COM Interop --- "Registration-free COM interop activates a component without using the Windows registry to store assembly information. Instead of registering a component on a computer during deployment, you create Win32-style manifest files at design time that contain information about binding and activation. These manifest files, rather than registry keys, direct the activation of an object."