-1

I am trying to upgrade a set of projects from VB6 to VB.NET 2.0. This project includes a set of library code and application code. Prior to upgrading, my VB6 application code would load my library code using the standard mechanism CreateObject() with a ProgID.

I have about 8 different library assemblies, all of which have strong names, are using the same .NET version (2.0), are compiled with x86 compatibility, and are in the GAC. When I try to load my libraries using CreateObject and my ProgIDs I get an ActiveX error. I have tested with ADODB ("ADODB.Command") and it successfully grabs the COM object. I am not sure what I am doing wrong.

I am also confused as to whether I should be using the System.Runtime.Interop class attribute for the library classes, or if I should configure them as ComClass implementations. I'm also not sure if I need to use those same attributes inside of the AssemblyInfo.vb file.

One other difference I noticed is that AssemblyInfo.vb for the upgraded vb projects is in the root directory, as opposed to when i make a new project and it is under "MyProject", might not matter but I want to provide all the info I can. Any bit of help that could be provided would be awesome.

Thanks!

killthrush
  • 4,859
  • 3
  • 35
  • 38
user2548289
  • 1
  • 1
  • Please post some code that shows what you are trying to do. It's not entirely clear whether your library is being upgraded, or your consumers, or both. That makes all the difference. COM Interop is really designed for situations where you need to have legacy or non-.NET code use a .NET library. If that's your situation, it's not quite clear from your question. If that *is* what you are trying to do, putting something in the GAC is not enough. You need to create COM wrappers and use the regasm.exe utility so that old-school COM knows what to do with your newfangled .NET library =) – killthrush Jul 03 '13 at 22:12
  • Well basically the system scrapes websites for data. The system uses these libraries to perform different database functions (Each has different methods for putting data from different websites into each part of the database). In the old vb6 these libraries were registered so that they could be called vis CreateObject, so I read that I need to add the libraries to GAC to use that CreateObject. All the projects are .NET, so maybe simple reflection is a better answer but I believe they want it to just be upgraded to .NET as opposed to rewriting much... a typical library class looks like this: – user2548289 Jul 03 '13 at 22:25
  • Option Strict Off Option Explicit On Public Class TR_flows – user2548289 Jul 03 '13 at 22:25
  • Sorry i did forget to mention, that all of the code (The libraries i want to put in GAC, as well as the code that uses it through CreateObject) are being upgraded as they were all previously done in vb6. In my last comment you will see TR_flows_NET.TR_flows as the ProgId. The Project for this library in particular is "AlbertaPower" and the class is "TR_flows" so i assume it should be "AlbertaPower.TR_flows" but that didnt work either, i figure maybe there is something missing in my library classes code that is stopping it from being visible in GAC, but it feels like ive tried everything. – user2548289 Jul 03 '13 at 22:35
  • OK, thanks. I edited your question accordingly. For future reference, you can edit your own questions to include code snippets and so forth - the comment feature is pretty limited for that purpose. I would still encourage you to add your sample COM attribute to your question so it's more visible. – killthrush Jul 08 '13 at 20:08

1 Answers1

0

I'm not really an expert on VB.NET, but putting the attribute on your class, strong naming, and GACing are all things you did right. That stuff is also required for C# .NET and I'm familiar with that.

I think your problem is that you've set up all your VB.NET code so that it makes a COM-callable wrapper, but you didn't actually register that wrapper with COM. The stock COM components like ADODB work because they were registered when the components were installed on your system. Registered COM components appear in your windows registry along with any related CLSID/ProgIDs. You can confirm this by searching your registry for your ProgIDs - I'll bet they are missing and that's why you get the error.

Basically, you need to add a step to your process. You need to run your assemblies (the same ones you're putting in the GAC) through regasm.exe. This utility comes with .NET and is designed to make the registration process really simple. There are not a great many tutorials for VB.NET & interop out there, but I did find this one that is probably good enough to get you unstuck.

There's also this link - it has a section in it titled "Wrapping Managed Objects in a Native Application". Give it a read, as it's essentially what you're doing.

I say "essentially" because in this case you are building .NET code to load some other .NET code...using COM. If you hadn't already gone down this path, I would encourage you to avoid COM altogether and just use .NET references, skipping the whole business with ProgIDs and RegAsm altogether. It's kind of like taking a long bumpy detour. You'll end up with a working application, but it will be harder to maintain and probably slower. Food for thought anyway.

Don't forget to upvote and accept this answer if it helped you solve your problem! Thanks =)

killthrush
  • 4,859
  • 3
  • 35
  • 38
  • One thing I thought of just now that *might* be relevant here - you should unregister any of these old COM components that you are upgrading. If you don't they will leave a bunch of cruft behind in the registry that *might* interfere with the proper functioning of your new components if the ProgIDs are the same. – killthrush Jul 10 '13 at 18:47