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(9.6, 65%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EE%3C/text%3E%3C/svg%3E)
I have a .net 7 class library with GUID and ComVisible attributes defined. Also added EnableComHosting tag in csproj.
After registering (regsvr32) the comhost.dll it is usable from e.g. Excel VBA, but only as late bound.
Anyone able to guide me further on how to make it early bound? (guess I have to generate a tlb some way, but have no clue how)
![](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(35.2, 18%, 13%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAK%3C/text%3E%3C/svg%3E)
I created the same (com visible) interfaces & classes in .net framework then used it's tlb to embed in net 7 dll.
It doesn't work though. I am getting Class not registered error.
And without embedding tlb i can't add reference to comhost.dll in VB IDE. I can't get it to work even as late bound. I followed all the steps of "Expose .NET Core components to COM" from the official web page.
Do you have any idea why it is happening with me?
Do you mean that you used 3.5 or higher version of full framework and produced the tlb file from there and then embedding this file into your .net 7 project?
I haven't tried this, but as far as I know it should work (I created an idl and used midl compiler to produce a similar tlb which works fine (more-or -less).
Did you add EnableComHosting elenet i a PropertyGroup and a ComHostTypeLibrary element in an ItemGroup (Include attribute refers to tlb), both in the csproj file?
I managed to make this early-bound, but with some other problems regarding VBA's debugging abilities, please see https://github.com/dotnet/samples/issues/5752
yes i used .net framework 4.8 to create tlb. But i am getting "Class not registered" error when running the exe created through vb IDE. Process you described feels too cumbersome and lengthy. I think i have to give up on using .net 7.
![](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(240, 30%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
I think your way of creating tlb is quite ok. Did you include both elements in csproj? Did you regsvr32 the generated comhost.dll? If so it should work.
Don't forget that if you want VB6 compatibility you must be working with 32-bit code and components.
There is a comprehensive sample that includes creating and registering a type library for both in-process and out-of-process COM servers created using .Net that was recently updated for .Net 7.
https://github.com/dotnet/samples/tree/main/core/extensions/OutOfProcCOM
I wish I misunderstand the whole thing, but if you have a look at your reference it states
"The .NET 6.0 SDK (Preview 5 or later) supports embedding type libraries into the COM DLL."
It also referes to the in-proc version of COM exposure, namely https://learn.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com
Which states:
"Unlike in .NET Framework, there is no support in .NET Core or .NET 5+ for generating a COM Type Library (TLB) from a .NET assembly. The guidance is to either manually write an IDL file or a C/C++ header for the native declarations of the COM interfaces. If you decide to write an IDL file, you can compile it with the Visual C++ SDK's MIDL compiler to produce a TLB.
In .NET 6 and later versions, the .NET SDK supports embedding already-compiled TLBs into the COM host as part of your project build."
The in-proc article is a bit clearer on it, but I think they both basically states that embedding an already existing tlb is supported. (but creating the tlb is not supported anymore).
Thus my problem seems to be "how to make a tlb"?
In my case I am going to replace/emulate an existing (but not good working) in-proc library probably written in c++ many years ago with a .net version.
I have used OLEVIEW to "fetch" the idl file from the registry for the old component, but midl compiler seems to refuse making anything from it and I am stuck.
I just commented on your latest comment, but seemingly my comment has disappeared.
Basically what my comment was pinpointing that your reference and the reference within it (for in-proc) states that the newer versions of .net (core) supports embedding already existing type-libraries, but no support for making them.
I have an idl file, but midl.exe refuses to generate anything from it (without reporting any error either).
So I am still stuck with late-binding which is not satisfactorily (to say it least) in this case because my goal is 100% reuse of old client code except for replacing one single reference from an older in-proc COM server (which is not working good)
(Just saw that my lost comment suddenly appeared again after waiting half an hour almost)
You are correct that .Net 7 does not provide the convenience of generating and registering type libraries that was supported by the .Net Framework.
If you take the time to download and actually build the sample it will create a type library and, if you provide the parameter for embedding, the DLL server that is created will contain the type library. Registration of the DLL server will also register the embedded type library.
If you need assistance with an IDL file and usage of MIDL you should ask a separate question and provide relevant details. We neeed more than "I have an idl file, but midl.exe refuses to generate anything from it (without reporting any error either)" to help you create a type library.
Thanks a lot indeed.
Sure I will try this (out-of-proc) and see if it could possibly be applicable for in-proc as well. (reporting back)
Of course I didn't in any way expect anyone to solve my problem based on my statement regarding midl (except possibly a hint of what could be obvious to other, but not to me). B.t.w. I have never used midl.exe before, just try to follow some articles.
I don't want to overwhelm you with COM details. Just be aware that the Out-of-process COM Server Demo for which I provided a link is designed to create an .exe server and also a DLL COM server that can also be used for out-of-process activation by using the system's DLLSurrogate. The DLL can be instantiated as an in-process COM server also and the relevant parts of the demo for you would relate to type library creation, embedding and registration. So don't get hung up on the out-of-process language. :)
Could you use the .tlb from the old in-proc server?
Thanks a lot again.
It worked in a way (the msbuild OutOfProcCOM.sln -restore failed on DllServer, don't know why not, but VS2022 could build it including tlb.
However, It seems like embedding the tlb made the reference dialog in excel/vba seemingly happy, but library was not added anyway, manually adding by browsing to the tlb file and selecting this directly made vba early-bound and I think I can live with that (providing I am able to tweak the fetched idl though).
Can't resist remembering how easy all this was with old framework, do you know the reason why MS didn't make it as simple this time?
Glad to hear that there has been some progress.
If you are willing to share the IDL file that you extracted using OleView I could work with you to resolve problems. Of course, I understand that it might contain private/proprietary information and so it cannot be shared.
As far as the change between .Net/.Net Framework is concerned don't forget that the .Net Framework is for Windows. Since .Net is designed to accommodate other platforms I can understand why Windows specific features might have been removed. Just my best guess...
Thank you very much for your proposal of resolving problems related to idl/tlb
To be honest I am not sure if I can openly share the extracted idl as is in an open forum, however I don't need the full idl, at least not for now. My replacement library only needs to implement a small part of the interface and that small part could be changed to a degree of me feeling safe that I do not break any agreements with the original supplier of the library. This means that I must be able to understand the process so I can replace the changed idl back to the (possibly reduced) original to fulfill my work.
I guess your proposal is about full openness through this forum or do you possibly mean by a private channel?
I was referring to sharing the IDL through public channels.. After all, other community members might take an interest and provide guidance and/or solutions.
After some internal discussion I/we (my employer) is not eagerly willing to share the idl due to possibly Intellectual Property Rights.
I am able to do the necessary changes to the idl file for a total "dis-association" (by changing all guids to newly generated ones) with the original component.
Then I am able to use the sample mentioned early in this thread and tweak it a bit to generate a tlb and then I think I can generate an assembly by tlbimp.exe, but from there I feel a bit helpless in how to use this for implementing my version of the original component and get it registered as a component without any coupling to the original.
Thankful for any hint on how to proceed.
B.t.w. In the end of the day, this .net COM server component will be referred from a vb6 class library which in turn is referred to from vba in Excel, is it possible to make the .net COM component reg-free and use it in this context (would simplyfy a lot for end users I think)
A couple of observations --
The OutOfProcCOM demo should have embedded the type library in the DLL COM server and registration of the server should have registered the embedded type library. You wrote "However, It seems like embedding the tlb made the reference dialog in excel/vba seemingly happy, but library was not added". I don't understand what you mean by this statement.
Its not clear to me why you are thinking about using tlbimp.exe. This .Net Framework utility is used to create a PIA. The .Net Framework isn't in the scenario you described. COM registration for a .Net 7 COM Server is the same as for a native C++ COM Server.
If your intent is to consume the .Net 7 COM object from a VB6 DLL loaded into Excel then the COM registration should be sufficient. Presumably you will need to change some code since it appears that you will be using different CLSIDs and IIDs than the old COM server that you are replacing with your .Net 7 server. Everything that you have mentioned so far relates to creating a new component that has no dependencies or relationship to the old COM server.
Since VB6 creates 32-bit code you need to make sure that you are creating a 32-bit .Net 7 binary.
Registration-Free COM generally requires manifests for both the COM client (.exe) and any in-process COM Servers. Since your COM client is Excel this may not be practical.
Finally, this thread has started wandering. It was initially focused on creating and registering a type library to support early binding.
Additional questions about interoperating with VB6/VBA should be posted in new questions.
You are absolutely right, this thread has been wandering du to my changing goal during the process.
My statement regarding tlb embedding was a bit vague, but anyway correct, however the reason was found to be some errors in the build process (because two components in Visual Studio 2022 Installer was not enabled and thus not installed, adding argument for binarylogging and using MSBuild Structured Log Viewer hintet me to the missing components and then all was ok regarding early-binding.
Then I got an idea that running tlbimp making an assembly which then could be decompiled /several tools e.g. Telerik JustDecompile, JetBrains dotPeek, ILSpy etc. even VS2022 itself (but I can only run it class by class) may give me cs files as "templates" for the interfaces and classes for free which may help me saving lots of time (I would like to implement all classes in the original lib which are more than 100 with a total of approx 1400 methods even if most methods will be implemented as throwing NotImplemented Exception).
So my current strategy is:
Extracting idl from OleView.
Replacing all guids in idl (by regex etc.).
Tweaking a bit on the idl.
Compile idl to tlb (MIDL)
tlbimp to make rcw (is that what is made?)
Running one of the mentioned decompilers to make skeleton file(s) for C# interfaces and classes.
From now a simple extract of the OutOfProcCOM can be used to build and embed tlb which may be referred to from vb6 and vba.
I would never got this far without your hints so again thank you very much for your help
You're welcome. If your original issue about creating a type library to support early binding has been resolved currently accept the answer to close this thread.
But you can add your library as reference in VBA/VB6? Then early binding should work.
Didn't mention it, but no, neither the MyLibrary.dll nor the MyLibrary.comhost.dll can be referenced from vba/excel, probably because no type library is embedded (I think old frameworks did exactly that by using regasm.exe which doesn't work for net core)
This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Comments have been turned off. Learn more