DLL's losing reference when opening a project

[JMTS]

My team is working with an application, we are starting to break out some of our code into DLL's. I have compiled our projects with these new DLL's.

We are finding that when people open the projects that the reference to the DLL's is lost and they have to keep adding the reference. Any idea's why??

 

[DannyB]

You mean the reference in the IDE or when the application is running ?? Design time or run-time ??
Daniel.Barreto@Netc.pt

http://dba.8m.com

http://www.lusosis.pt

 

[JMTS]

Design time. When another developer opens the project to work on it the reference is no there. This does not happen on my machine (where the DLL's were created)

 

[edderic]

Are de VB files .vbw the same on both computers ? Eric De Decker
vbg.be@vbgroup.nl

Licence And Copy Protection AxtiveX
Source CodeBook for the programmer

http://www.createsoftware2000.com

 

[chiph]

JMTS -

Who's doing the building of the DLL's? There needs to be one person designated as the "build master" for each DLL. If two or more people build the DLL without compatibility being set, you get two different GUIDs being assigned, and OLE thinks you've got two different DLLs that just happen to have the same name (i.e. it gets confused).

What I've done in the past to allow other developers to build the *.exe (for testing on their PC only!) is to have a network share that has the "reference" copy of the DLL. When it comes time to update that to the next version, the build master builds the DLL with compatibility turned on, then overwrites the reference DLL with the newer one. Since they had compatibility turned on, it gets the same GUID as before, and has it's OLE version incremented (which is not the same as the file version).

You should also have the "auto-increment" version number flag turned on, so that you can right-click the DLL or OCX and see at a glance in the file's properties which one is newer, without trusting the date/timestamp (which the Microsoft networking occasionally resets when doing a filecopy).

If the programmers do something to break compatability (like remove a parameter from a public function, or remove/rename a class, or remove a function no longer used), the build master gets to hit them with a keyboard wrist-rest

Shortly before release, a build should be done that intentionally breaks compatability. This is your chance to clean up all the stuff left over from the internal builds. Because it breaks compatability and everyone has to then reset their references (a real PITA), you want to do this as seldom as possible.

Chip H.

 

[JMTS]

Thanks for the info Chip.

This is our first stab at DLL's(if you can believe that!) Right now my PC is the "build master". I have had to break compatiable one or twice (opps) but I have recompiled all of our exe's with the new versions. Once that occurs we have a process that runs to see if everyone has the "latest and greatest" on their my machines. If they don't we copy down the new DLL's and register them on their machine.

Could this be the problem??.....

I was referencing a DLL, that I had created, in our exe's, but the exe's was not using that DLL (it was being used by another DLL that the exe was referencing) Could the fact that I was referencing the DLL and not using it cause that message to appear(about not being able to reference the dll)??