I have a .NET assembly which I am exposing to COM. The assembly has two public interfaces and one public class. When I build the assembly I get this warning:
(assemblyName.dll) does not contain any types that can be registered for COM Interop.
My assembly information includes the following line.
[assembly: ComVisible(true)]
Most people having this problem on the web, that I have found, fixed it with the above line in their assembly information. This has not helped for me.
I also tried adding [ComVisible(true)] to the class and interface definitions, and it also did not help.
ComVisible classes generally need to have a public default constructor. Its members should typically also reference only ComVisible types.
You don't need to specify ComVisible(true) on the class if you have specified it at the assembly level.
However, the usual way to generate an assembly with ComVisible classes is:
Specify ComVisible(false) at assembly-level. Thus only classes that are explicitly marked with ComVisible(true) are exposed to COM.
Define an explicit ComVisible interface :
e.g.
[
ComVisible(true),
GuidAttribute("..."),
Description("...")
]
public interface IMyComVisibleType
{
// members...
}
Your ComVisible class should specify ClassInterfaceType.None, and should implement the ComVisible interface:
e.g.
[
ComVisible(true),
GuidAttribute("..."),
ClassInterface(ClassInterfaceType.None)
]
public sealed class MyComVisibleType : IMyComVisibleType
{
// implementation ...
}
Note that the Guid and Description attributes are not required, but useful to give you more control of the COM generation.
If the above doesn't help, try posting some sample code and I'm sure someone will be able to help.
I ran into the default constructor problem. What fooled me was that the type library file will contain the class GUID reference even though that class is not being registered. A quick way to see what will be registered is to create a registry file ('assembly.reg') like this:
regasm assembly.dll /regfile:assembly.reg /codebase
There's a good discussion of exposing interfaces in COM Interop: Base class properties not exposed to COM. Some example code is here: Exposing .NET Components to COM.
Here are a few other things to true
Make sure the types you want to register are marked as public
Add the ComVisible(true) attribute to the type directly in addition to the assembly
Add the Guid attribute
Not sure if the last 2 are strictly necessary but I would try them out.
I think you need to have a strong-named assembly. Do you sign your assembly with a key file?
Further, also try specifying :
[Guid("{newly generated GUID}")]
[ClassInterface(ClassInterfaceType.AutoDual)]
I had the same problem on a project where I checked the "Register For COM interop" option for my C# project. There is an easy solution:
While in the Solution Explorer, go to the Properties folder. Open the AssemblyInfo.cs file. Scroll down to the line that says:
[assembly: ComVisible(false)]
Change this to:
[assembly: ComVisible(true)]
This will remove the warning messages, and allows the .tlb file to be created, which then enables the .NET code for COM visibility.
If you don't want the entire assembly to be COM-visible then follow one of the other tips above.
Related
I have a C# library project which is designed to be used from unmanaged C++ code via COM.
Only 2 or 3 methods are going to be called in this way but I get warnings like this:
warning : Type library exporter warning processing ''.
Warning: Type library exporter encountered a generic type instance in
a signature. Generic code may not be exported to COM.
These properties and methods are not designed to be accessed from C++, an in fact they are not even public methods so they (surely) wouldn't be visible anyway.
Two questions really:
Q1: How can I control what is exported? Access modifiers on classes/methods or something else?
Q2: How can I see what is exported e.g. check what's in the type library to see if I missed something
It would be nice to double check I'm not bloating my type-library with a load of stuff that's not supposed to be there...
I can declare the whole assembly to be invisible to COM, like this (in fact when you use Visual Studio C# class library template it should put it itself in AssemblyInfo.cs):
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]
Now, in each class I can decide it will be visible to COM or not like here:
using System;
using System.Runtime.InteropServices;
namespace ClassLibrary1
{
[ProgId("MyCoolClass")]
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.AutoDual)]
public class MyCoolVisibleClass
{
public void SayHello()
{
Console.WriteLine("Hello COM world");
}
// explicit non COM visible because it's set to true at class level
[ComVisible(false)]
public void SayHello2()
{
Console.WriteLine("Hello world");
}
}
// implicit non COM visible
public class MyCoolInvisibleClass
{
public void SayHello()
{
Console.WriteLine("Hello world");
}
}
}
You can use the project properties to register ("Register for COM Interop" checkbox) , but I personally register myself with a command line like this (for 64-bit registry world):
%windir%\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe ClassLibrary1.dll /codebase /tlb
This outputs something like this:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe ClassLibrary1.dll /codebase /tlb
Microsoft .NET Framework Assembly Registration Utility version 4.8.3752.0
for Microsoft .NET Framework version 4.8.3752.0
Copyright (C) Microsoft Corporation. All rights reserved.
RegAsm : warning RA0000 : Registering an unsigned assembly with /codebase can cause your assembly to interfere with other applications that may be installed on the same computer. The /codebase switch is intended to be used only with signed assemblies. Please give your assembly a strong name and re-register it.
Types registered successfully
Assembly exported to 'D:\KilroyWasHere\ClassLibrary1.tlb', and the type library was registered successfully
And I can check what's really inside the .tlb using OleView from Windows SDK:
I have a WSDL generated class
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
public partial class FVZServicesClient : System.ServiceModel.ClientBase<FVZScanningDocumentInfo.FVZServices.FVZServices>, FVZScanningDocumentInfo.FVZServices.FVZServices {
...
}
I need to provide a library that is used in VB6. I use a COM Interface which happens to use the above class.
When I register the assembly with
regasm MyAssembly.dll /tlb:MyAssembly.tlb
I get the error message
Microsoft .NET Framework Assembly Registration Utility version
4.7.3062.0 for Microsoft .NET Framework version 4.7.3062.0 Copyright (C) Microsoft Corporation. All rights reserved.
Types registered successfully Type library exporter warning processing
'MyAssembly.FVZServices.FVZServicesClient, MyAssembly'. Warning: Type
library exporter encountered a type that derives from a generic class
and is not marked as [ClassInterface(ClassInterfaceType.None)]. Class
interfaces cannot be exposed for such types. Consider marking the type
with [ClassInterface(ClassInterfaceType.None)] and exposing an
explicit interface as the default interface to COM using the
ComDefaultInterface attribute. Assembly exported to
'C:\Users\MyName\Documents\ScanLibrary\Packet\MyAssembly.tlb', and the
type library was registered successfully
When I add the Attribute [ClassInterface(ClassInterfaceType.None)] as suggested to FVZServicesClient, I still get the same error message the next time I try the regasm. I know that the generated code can be overwritten at any time, but I verified with DotPeek that the ClassInterface-attribute was still in the compiled code.
Another thing I tried, was to create a partial class of FVZServicesClient that had the ClassInterface-attribute. I also marked the default interface with COMDefaultInterface as the message suggests. The result was the same. Adding the Attribute [ComVisible(false)] for the FVZServicesClient did not help either.
When the library is referenced in VB6, the compile results in an error: "User-defined type not defined".
How can I exclude FVZServicesClient from the COM interface?
Try adding the attribute [ComVisible(false)] to class FVZServicesClient.
I'm not sure how your code generation process works, but as noted in the question you can at least try adding this manually and seeing if it has the desired effect.
The error message was deceiving. In FVZServicesClient there is a method that expects a parameter to be passed by reference.
public ScanBatchItemType[] CheckBatch(ref ScanBatchItemType[] scanBatchItemTypes)
I did not pass it by ref. Once I corrected that, the error message disappeared. At the moment there is no COMVisibility or ClassInterface Attribute on FVZServicesClient and COM is Ok with that.
I have created a project with some ComVisible methods. To have these available in VBA with Intellisense, I mark the assembly as ComServer in the .dna-file, and generate the .tlb-file using RegAsm in a post-build event. This works great.
I also have another project, that has some ComVisible methods. I would like to have these methods included in that same type library as well. Is this somehow possible?
I thought I could very easily just embed the assembly, which would then do the trick. This is unfortunately not possible. So... any other way I could do this?
I insert the line:
[assembly: InternalsVisibleTo("MyTests")]
inside my project under test( Properties/AssemblyInfo.cs) where MyTests is the name of the Unit Test project. But for some reason I still cannot access the internal methods from the unit test project.
Any ideas about what I am doing wrong ?
If your assembly is signed with a strong name look at this answer.
Otherwise check that the name of your test assembly really is "MyTests.dll" (it doesn't have to match the project name, though it will by default).
Let's break it down a bit as many of us have experienced this slight mix-up in the past...
Assembly A has your internal class.
Assembly B has your unit tests.
You wish to grant the internals of assembly A visibility in assembly B.
You need to put the InternalsVisibleTo assembly attribute inside assembly A and grant access to assembly B.
You still need your test project to reference your main project.
This can be easy to overlook and if you have no existing test code this may appear like the InternalsVisibleTo is not functioning.
I had the same issue after renaming a namespace. Basically the in .cs files was the new namespace but in the .csproj and AssemblyInfo.cs it was the old namespace.
namespace newNamespace {
....
}
So, I changed in .csproj the following to the new namespace:
<RootNamespace>oldnamespace</RootNamespace>
<AssemblyName>oldnamespace</AssemblyName>
And in AssemblyInfo.cs:
[assembly: AssemblyTitle("oldnamespace")]
[assembly: AssemblyProduct("oldnamespace")]
In my case I was coding to an Interface. As interfaces can only specify public properties the internal properties were not present on the interface.
Make sure you're not doing the same thing as I was!
I changed:
Assert.IsNotNull((exportFileManager)?.ThumbnailFileExporter);
To:
Assert.IsNotNull((exportFileManager as ExportFileManager)?.ThumbnailFileExporter);
I made the incorrect assumption that InternalsVisibleTo will help in accessing Private methods too.
Here are some other aspects that can lead to this error:
Your class is either internal or public
Your method is internal
The InternalsVisibleTo property contains the full namespace of your test project.
You can expose internals from strong named assembly to another strong named friend assembly only. But non-strong named assembly can expose internals to strong named friend assembly.
i have a c++/cli class having a constructor and destructor and method name requirement. i need to call this method in c# wcf program, so this is what i did in c# wcf code for calling c++/cli method.
Class1 test= new Class1();
test.requirment();
my question is that how does the c# program knows that which c++/cli program it is referring to and i added this cli dll as a reference to the c# wcf program and also used it as a namespace. So i want to know like what i am doing is correct or not, and also want to know whether is there any other way to do this or any other settings need to be changed in c# program.
You could only do slightly better as you're already doing. If your C++/CLI class contains some native resources (usually the only reason to use C++/CLI) and you've properly implemented the C++/CLI "destructor" i.e. ~Class1() method:
using (var test1 = new Class1()) {
test1.requirement();
}
This works because each C++/CLI class implements IDisposable by default and maps ~Class1() to an implementation of Dispose.
This is defined by your project references (right-click the project -> Add References...). If the C++/CLI project is in the same solution, you should add it under the "Projects" tab, otherwise select "Browse" and select the C++/CLI assembly on the file system.
C++/CLI projects and assemblies are no different in this regard than any other .NET project or assembly.
To make sure that the identifier "Class1" in your code refers to the correct type, you can use Go To Definition and it should show you where the type is defined. If there is an ambiguity or missing reference the code will not compile anyway.
What you are doing is correct in my opinion and you dont need to do anything else. Make sure that Class1 is declared as a Managed class in the C++/CLI assembly (public ref class Class1), and you are good to go.
Since you have added the C++/CLI assembly as reference to the assembly that has the WPF code, and also added the namespace in using clause, the runtime and compiler has enough information to resolve the things.