 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / December 2004Use .NET DLL from VB6 app -> broken references on rebuild?
I'm building a set of DLLs in .NET that I plan to call from a VB6 application. I've almost got that to work, but now I find that whenever I re-build any of my .NET DLLs, the reference to that DLL in my VB6 project gets broken. So, I need to re-create the reference after every rebuild. This is incredibly frustrating and time-consuming. Is there a way around this? (PS. I'm using VB6, and VS.NET 2003 with the 1.1. framework.) Are you strong naming the assemblies, setting the versions in the AssemblyInfo.vb file and have you set the ComClass() attrribute for ClassID, InterfaceID and EventsID and specified the GUID strings for those clsid values? Robert Smith Kirkland, WA www.smithvoice.com > I'm building a set of DLLs in .NET that I plan to call from a VB6 > application. [quoted text clipped - 9 lines] > > (PS. I'm using VB6, and VS.NET 2003 with the 1.1. framework.) look here for more info: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcn7/html/vawl kWalkthroughCreatingCOMObjectsWithVisualBasicNET.asp and in case you're interested: Best help for you and your coworkers on the project is to go to your local bookstore today and get Rockford Lhotka and BIlly Hollis' "Professional Visual Basic Interoperability: COM and VB6 to .Net" I think it only had a .Net1.0 version ... if it's at your store get it anyway. The main stuff you need is in it and the differences will be more easy to figure out after you've read the first several chapters of this book. If it's not at your store then rush it from amazon, they've got a deal on it because of the death of WROX press. There are other Interop books, some with lots more neat-geeky code that will make you think that your money will go farther on them ... but it sounds like you need a crash course and you need it in a syntax that will make it work for you. This is the book. Robert Smith Kirkland, WA www.smithvoice.com > Are you strong naming the assemblies, setting the versions in the > AssemblyInfo.vb file and have you set the ComClass() attrribute for [quoted text clipped - 4 lines] > Kirkland, WA > www.smithvoice.com Robert, Thanks very much for your reply, and also for the next one about the book. Actually it's a C# DLL, but I think I'm doing the equivalent C# stuff for some of what you mention (GUIDs etc.). Without doing that, I can't see the DLL/classes/methods from VB at all, so I must be doing something right. Note that the problem I have is not that I can't reference call the DLL, it's just that a recompile of the DLL means that it disappears from the references list in my VB project. I haven't done anything with the version number in the AssemblyInfo.vb^H^Hcs file, and now that you mention it I can see that that would be a problem if the version number is auto-incremented, which I think it might be. I'm not strong naming the assemblies either - I've yet to find a description of why you'd want to do that, but if it's going to help me here then I will. I can find plenty of the "how", just not the "why" :-) Thanks again, Gary McGill > Are you strong naming the assemblies, setting the versions in the > AssemblyInfo.vb file and have you set the ComClass() attrribute for ClassID, [quoted text clipped - 18 lines] > > > > (PS. I'm using VB6, and VS.NET 2003 with the 1.1. framework.) Ah, ok. VB.Net and C# deal with versioning differently. VB.Net doesn't automatically increment the assembly versions when you use wildcards in the version attribute of the assemblyinfo file if you're running the same instance of the IDE (unless you switch from a non-strongnamed build to a strongnamed build) and VB developers are urged to set version numbers implicitly, wheras rebuilding with C# will give a new version number on every build in the same IDE instance. IMO, strong naming for a production assembly is a correct practice in all cases and just a good habit to get into. For a detailed set of "Whys" on versioning and strongnaming you may find the first several paragraphs of the following link helpful: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg _ch5.asp Now, I wanted to check the tlb reference issue for you but I don't have VB6 installed where I am so I'll have to get to it later or maybe someone else will pop in and help out. It's been a little while since I've been on a project where I did this every day, but just of the top of my head what I will be trying first is trying to duplicate the issue by building a .Net assembly and pointing VB6 at it's tlb where it sits in the .Net build bin folder, then recompiling (generating a new tlb file) and seeing if the ref gets hosed ... and if so I'll copy the tlb and dll to a second different location and point VB6 at it there, then rebuild (without changing the interface) and just copy the new dll to the second location and see if VB6 is still ok (because it's using the same tlb as before). I'd figure that the tlb is what's going to make the difference because that's what VB is linking to. That being said, so long as you're not changing the dll's interface then using the same tlb should be working... and only if you add or alter the public interface should you need to set VB6 to a different tlb. If I can get to this today I will, but maybe someone else can just run these steps and post the results here. In any case, please look to the link above, even with C# you might decide that using strongnames and maintaining your own version numbers is the real-world best practice, it does get tedious in a solution with multiple projects/assemblies but it helps keep things straighter in your head over time. Robert Smith Kirkland, WA www.smithvoice.com > Robert, > [quoted text clipped - 22 lines] > Thanks again, > Gary McGill Boy I hate it when people quickly addendum-post, and here I am doing it again :) Meant to say: "VB developers are urged to set version numbers EXplicitly" Personally I think the VB.Net way is best after you know about the difference... but, of course, I'm a proud VB developer, and MS knows well my mindset ;-) -smith > Ah, ok. > [quoted text clipped - 69 lines] >> Thanks again, >> Gary McGill Robert, Thanks again for your comprehensive and extremely helpful reply! Gary Just checking in... I haven't had a chance to get to a box with VB6 on it over the weekend. But did manually setting the version numbers do the trick for you? -smith > Robert, > > Thanks again for your comprehensive and extremely helpful reply! > > Gary Robert, I've just tried setting an explicit version number, rebuilt my C# DLL, and - hurrah - the reference from the VB project is not broken. :-) FYI, I didn't have to strong-name anything, though I probably will. Gary > Just checking in... I haven't had a chance to get to a box with VB6 on it > over the weekend. But did manually setting the version numbers do the [quoted text clipped - 7 lines] >> >> Gary Like you said easrilier, that was probably the issue, and one that a VB dev wouldn't notice as much becuase of the diffs in the versioning systems. Great news & nice working with you ;-) -Smith > Robert, > [quoted text clipped - 4 lines] > > Gary Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.