I created a VS 2010 class library. Marked the assembly for Com Visibility. Signed the assembly with a strong key. Created my class, have my entry point method available.
The library works fine from a test project in C#.
I regasm the class library to gac, via:
c:\windows\microsoft.net\framework\v4.0.30319\regasm testdll.dll /tlb: testdll.tlb /codebase
Include the tlb file as a reference in my VB6 project. I find it through resources 'browse' so its there.
When i try to instantiate the class... its empty. the public method that should be available via the public class doesn't show.
Dim objTest as testdll.testclass
set objTest = new testdll.testclass
objTest.testmethod <--- this 'testmethod' doesn't display in intellisense... nothing does.
In addition i tried calling the 'testdll.testclass' via CreateObject, i get the error "ActiveX component can't create object"
Now i have other projects i've done COM visibility for and i've tried comparing the difference, but i don't see any. I can't understand why it isn't working.
Any clues??? tx very much.
Just use an interface... one you define or to use the [ClassInterface(ClassInterfaceType.AutoDual)]
there are comments online you can find that indicate not to use autodual, but if you control the complete usage of your library, it seems like an 'ok' way to go.
I tried all sorts of ways to simulate / understand why my one project didn't need an interface to be visible by an vb project, without success. i had originally thought perhaps possible that it was because that project implemented an IDisposable Interface (the ONLY interface used in the C# projects that is com visible) but that didn't turn out to be the reason. Anyway I don't want to waste anyone else's time on this. thanks for the responses.
this link provides ample information on the subject:
http://anturcynhyrfus.blogspot.com/2011/03/creating-com-visible-c-component.html
Related
I am attempting to add a Fakes assembly (in Visual Studio 2012 Ultimate) for an library that I reference in my code so that I can test independently of the libraries implementation. The the problem I'm having is that when I right click the referenced assembly and click "Add Fakes Assembly" I receive the message:
"Assembly not supported
Fakes does not support this assembly."
I've tried Googling this message but get 0 results if I put it in quotes and nothing relevant if I don't. I thought this was quite strange as you would expect someone else to have run into this issue at some point but anyway...
After giving up on searching for the message I tried searching for somewhere that might tell me what types of assembly Microsoft Fakes does support but this also proved fruitless.
I guess my question is: Does anyone know what types of assembly Microsoft Fakes does/doesn't support.
I've included some information about the assembly I'm referencing in case anyone knows why this one in particular isn't supported:
-Its a COM Interop assembly.
-Its an ActiveX component.
-It isn't strongly named.
Any leads at all would be greatly appreciated.
To be honest, the things you mentioned probably aren't the problem. It's entirely possible to fake Excel interop classes, for instance (not that you can use them!).
But if you take a look at what thing's don't support fakes, such as sealed classes, which don't allow stubs because stubs require inheritance, and some reflection classes which restrict shims, it's clear that some classes will have neither, thereby allowing a dll to have no fakeable components. Not much you can do there.
Additionally, Shims cannot be used on all types from the .NET base class library mscorlib and System. says MSDN.
Visual Studio includes a refactoring function called "Extract Interface" that generates an interface based on a class implementation.
The extracted interfaces are Internal by default. Problem is, we end up changing nearly all of them to Public.
Does anyone know why it's Internal by default? Better yet, is there a way to customize this to default to Public?
It might work if you change the Visual Studio template for interfaces (I haven't tried that but assume this should work).
For Visual Studio 2008 the template is stored at
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates
\CSharp\Code\1033\Interface.zip"
This is described in more detail in this answer.
I don't have a reference, but I have a wild guess as to why it is internal by default.
Let's say you have 3 projects / assemblies: log4net (a 3rd party API), MyApp.Util, and MyApp.Web (a Web project). Web references Util, which references log4net. Web does not reference log4net, and you want to keep it that way.
Inside of DAL, say you have an internal class, and one of its members references a type defined in log4net. It could be the return type or one of the parameter types of a method, or the type of a property.
Let's say you extract an interface from the aforementioned class, including the aforementioned member that references log4net. Well, if you make that member public (part of a public interface) and reference a type that implements it, you then require that the Web project reference log4net.
By making the interface internal, Web may continue to be ignorant of log4net.
I am building something similar to Server Explorer for Apache CouchDB. One of the things necessary is to be able to edit CouchDB view definitions which in CouchDB are JavaScript functions.
How can I trick Visual Studio into using my object to retrieve and save the content of the JavaScript function but still use the rest of it - I am happy with editor itself and have no intention of writing my own Editor/Language Service, etc. The latter would be much bigger effort than what this project warrants
Edit
After more digging I am still stuck. Here is what I know: IVsUIShellOpenDocument interface provides a method OpenStandardEditor which can be used to open the standard Visual Studio editor. As one of the parameters this method takes a Pointer to the IUnknown interface of the document data object. This object is supposed to implement several interfaces described in many places all over the MSDN.
Visual Studio SDK also provides a 'sample' implementation of the document data object VsTextBufferClass. I can create an instance of this class and when I pass the pointer to the instance to the OpenStandardEditor I can see my editor and it seems to work ok.
When I try to implement my own class implementing the same interfaces (IVsTextBuffer, VsTextBuffer, IVsTextLines) OpenStandardEditor method returns success, but VS bombs out on call editor.Show() with an access violation.
My suspicion is that VsTextBufferClass also implements some other interface(s) but not in C# way but rather in the good old COM way. I just do not know which one(s).
Any thoughts?
What if you had a program that would export the javascript to files on disk, then imported them back into the database once you were done editing them with Visual Studio? That might be the simplest way to do this.
I have a C# library that I am using for a COM object in unmanaged C++ code. I registered the library using Visual Studio's checkbox "Register For Com Interop" and set ComVisible to true.
imported the tlb to the C++ app..... when I run it, I get a "Class Not Registered"....
This has worked before, but this started happening after I moved the directory of my C# project to a different location.... yes I did re-register the library after I moved it.
I've removed all references from the registry... I 've even tried doing a gacutil.exe /i on it... no dice.
Anyone know how to fix this?
A better way of using unmanaged objects in managed code is to use C++ / CLI. You can easily create a managed wrapper around the native object.
If you don't have explicit CLSID set on your managed object, it's possible that the move and rebuild has generated a new CLSID. Make sure your unmanaged project does not have a stale copy of the typelib.
Go to HKCR\CLSID\{XXXX} and ensure that the class registration for the managed object points to the right managed dll.
After asking about what Visual Studio does to register a COM Library, it became clear that VS did two things for COM registration:
Registered the COM Library
Creates and registers a Type Library
Visual Studio seems to do this registration using regasm.exe. For the first part (the direct COM registration) using tallow or heat (WiX 2.0 or WiX 3.0) seems to get all of the basic COM registration information correct.
However, what tallow/heat doesn't seem to do is set up a type library installation. It would be possible to create a custom action to do this with a WiX installer and regasm.exe, but invoking custom actions are not best practices when it comes to Microsoft installer based installers.
Upon further research, it looks like an msi has the ability to generate the type library upon installation. In fact, WiX seems to have direct support for it! In a file element, you can add a Typelib element. In fact, an article over here on wix has an example of filling out the TypeLib element with Interface elements.
It seems there's at least two required attributes to an Interface element:
Id
Name
Larry Osterman speaks about the other parts of the interface that need to be registered for a TypeLib in general, and this Interface entry seems to take care of the individual parts. Larry says we need to specify the ProxyStubClassId32 as "{00020424-0000-0000-C000-000000000046}", so we can easily add that.
Where to go from there and what to fill out for the various Interface elements has me stumped. I've gone ahead and added the TypeLib element to my wix file, and it successfully compiles. I'm a bit clueless as to how to set up the Interface elements though. What do we need to do to properly fill out the TypeLib element, and what apps or tools can I use to get it?
The answer below by wcoenen looks promising...I'm going to give it a shot.
Update: Posted my final solution below as an answer.
Here's the lazy man's way of solving this problem: Use heat from WiX 3.0.
If you have a type library generated automatically and installed via regasm, heat can take the .tlb as an argument in
heat file c:\my\path\to\my.tlb -out tlb.wxs
It will generate all the typelib and interface elements you need to register. This won't solve the problem of needing to know them ahead of time, and it won't solve the problem of GUIDs changing when the version of the assembly changes (even if the interface doesn't - which is the only time you're supposed to change it) but it will get you partway there.
The following trick can help with harvesting any registry changes and turning them into a wxs file, including the typelib element you're after.
First, bring your registry back in a state where the type library was not registered:
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe /tlb /u mylib.dll
Export this clean state of the registry to hklm-before.reg:
c:\WINDOWS\system32\reg.exe export HKLM hklm-before.reg
Register the type library again:
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe /tlb mylib.dll
Export the new state of the registry to hklm-after.reg:
c:\WINDOWS\system32\reg.exe export HKLM hklm-after.reg
Now we have two text files, hklm-before.reg and hklm-after.reg. Create a diff.reg file which only holds the relevant differences between these. You can find the differences easily with a diffing tool. I like to use the diff tool included in TortoiseSVN since I already use that every day. (WinDiff doesn't seem to work well in this case because of text-encoding issues.)
We can now convert diff.reg into a .wxs by calling heat.exe with the reg command. (Requires wix 3.5 or newer.)
heat reg diff.reg -out typelib.wxs
It looks like to register a Type library, the best way would be to generate your own IDL or ODL file, which will contain your GUIDs. The Typelibs generated directly from the Assembly are [i]dependent[/i] on the assembly version numbers : the GUIDs are generated based on that information, even if the interface hasn't changed. Visual Studio uses regasm to register and generate the typelib. Underneath that, it uses RegisterTypeLib, a win32 call. Using the typelib element seems to do something similar. No good.
However! Creating the type library by hand is painful. It is possible to get those GUIDs another way: digging them out of the typelib and creating the elements yourself.
Larry Osterman has the information that's needed: there's certain registry keys that need to be set. You can do those with the Registry table (and in Wix3, that means RegistryValue elements.) The trick here is getting the GUIDs: any old GUID will not work. Normally, getting the GUIDs is simply a matter of looking in the IDL for your library (you wrote your own IDL, right? :) ).
If you didn't write an IDL or ODL file to compile into a typelib, they still exist, in the file. Microsoft provides several handy tools: LoadTypeLibEx and the ITypeLib interface. With these interfaces, you can browse the type library and get all sorts of information. How do we browse the library?
I simply took a look at how Regasm did it! A quick dissassemble later, and we find that regasm is written in C# too. Glory day. I started up a project, and with a few using statements and a PInvoke later, we have:
using System.Runtime.InteropServices; // for struct marshaling
using System.Runtime.InteropServices.ComTypes; // for the ITypeLib + related types
// TYPELIBATTR lives in two places: Interop and ComTypes, but the one
// in Interop is deprecated.
using TYPELIBATTR = System.Runtime.InteropServices.ComTypes.TYPELIBATTR;
/// <summary>
/// The registry kind enumeration for LoadTypeLibEx. This must be made
/// here, since it doesn't exist anywhere else in C# afaik. This is found
/// here: http://msdn.microsoft.com/en-us/library/ms221159.aspx
/// </summary>
enum REGKIND
{
REGKIND_DEFAULT,
REGKIND_REGISTER,
REGKIND_NONE
}
// and this is how we get the library.
[DllImport("oleaut32.dll", CharSet = CharSet.Unicode, PreserveSig = false)]
private static extern void LoadTypeLibEx(string strTypeLibName, REGKIND regKind, out ITypeLib TypeLib);
Whew! Once we have this out, we have to navigate the structure. This is interacting with unmanaged resources, so get ready to be Marshaling stuff around.
ITypeLib lib = null;
LoadTypeLibEx(Value, REGKIND.REGKIND_NONE, out lib);
IntPtr libInfoPtr = IntPtr.Zero;
lib.GetLibAttr(out libInfoPtr);
TYPELIBATTR libInfo =
(TYPELIBATTR) Marshal.PtrToStructure(libInfoPtr, typeof(TYPELIBATTR));
int typeCount = lib.GetTypeInfoCount();
for (int i = 0; i < typeCount; ++i)
{
ITypeInfo info;
lib.GetTypeInfo(i, out info);
IntPtr typeDescrPtr = IntPtr.Zero;
info.GetTypeAttr(out typeDescrPtr);
TYPELIBATTR type =
(TYPELIBATTR)Marshal.PtrToStructure(typeDescrPtr, typeof(TYPELIBATTR));
// get GUID, other info from the specific type
}
lib.ReleaseTLibAttr(libInfoPtr);
libInfoPtr = IntPtr.Zero;
Whew. So, you have to write some code to extract the information. Once you do, you have to fill that information into Registy Entries, as specified By Larry Osterman.
Of course, you could avoid that step by simply writing your own IDL file to begin with. The choice in pain: it's up to you!