G
Guest
Hi...
Our company has a fairly large client-server application and is very complex in its construction. The main point about that is there are a number of separate client pieces that require dependent project references to be maintained. For example, we have at the very bottom a data access layer application. On top of that there is layer that accesses that data access layer. Above that is a middle layer of classes and collections that are ultimately consumed by the user interface.
Ok.. nothing new about this kind of architecture. In VB we had guids that "assured" our compatibility between these layers. Now in VB.Net we have References. Again, I am not telling you anything you don't already know. However, I am having a horrible time, in the development environment, maintaining these references.
Now, for the stuff that I don't know that maybe some of you do know.
In my development environment, I have a single executables directory where I place ALL of my DLL files. When I make the references in the programs, I browse to this single executables directory and reference those DLLs in that directory. On the reference property, currently I leave the Copy Local property remain the default of True. My understanding of this is that I can browse to that single executables directory to make my reference, but in reality the file is copied to that particular projects /bin directory. If this is incorrect, please enlighten me.
So, two things happen that constantly drive me crazy. 1) Say I am working on the user interface but realize that the layer above the data layer has a problem. I close my UI project and go to that project, fix the problem and recompile. I go back to my UI and try it again, the problem still exists - duh! - the project between the UI and the project I just fixed has its own personal copy of the old code in its /bin directory. 2) So I go to that project and renew the reference... in the process, when I delete the reference in the project, it literally deletes the newly compiled dll in the single directory. I have to recompile the other project again to get a new copy of the dll in there, go back to this project and rereference it and recompile it. It goes that way up the reference foodchain.
Then I tried setting the Copy Local property to False, meaning (I assume once again) that it is going to have a tight lock on the compiled dll in the executables directory. This seemed to work for a while, but when you have to fix and recompile things you have to shut down all projects because they lock out those files in the executables directory. Then, when you delete and re-reference one of the dlls it does the same as 2 (above). And if all of the futzing around I will occasionally forget to set the Copy Local to False (as it always defaults to True) and suddenly I have about two hours of fighting and tracking down the problems.
It is a nightmare!!! Is there anyone who feels my pain and knows a better idea about how to use references in VB.NET?
Our company has a fairly large client-server application and is very complex in its construction. The main point about that is there are a number of separate client pieces that require dependent project references to be maintained. For example, we have at the very bottom a data access layer application. On top of that there is layer that accesses that data access layer. Above that is a middle layer of classes and collections that are ultimately consumed by the user interface.
Ok.. nothing new about this kind of architecture. In VB we had guids that "assured" our compatibility between these layers. Now in VB.Net we have References. Again, I am not telling you anything you don't already know. However, I am having a horrible time, in the development environment, maintaining these references.
Now, for the stuff that I don't know that maybe some of you do know.
In my development environment, I have a single executables directory where I place ALL of my DLL files. When I make the references in the programs, I browse to this single executables directory and reference those DLLs in that directory. On the reference property, currently I leave the Copy Local property remain the default of True. My understanding of this is that I can browse to that single executables directory to make my reference, but in reality the file is copied to that particular projects /bin directory. If this is incorrect, please enlighten me.
So, two things happen that constantly drive me crazy. 1) Say I am working on the user interface but realize that the layer above the data layer has a problem. I close my UI project and go to that project, fix the problem and recompile. I go back to my UI and try it again, the problem still exists - duh! - the project between the UI and the project I just fixed has its own personal copy of the old code in its /bin directory. 2) So I go to that project and renew the reference... in the process, when I delete the reference in the project, it literally deletes the newly compiled dll in the single directory. I have to recompile the other project again to get a new copy of the dll in there, go back to this project and rereference it and recompile it. It goes that way up the reference foodchain.
Then I tried setting the Copy Local property to False, meaning (I assume once again) that it is going to have a tight lock on the compiled dll in the executables directory. This seemed to work for a while, but when you have to fix and recompile things you have to shut down all projects because they lock out those files in the executables directory. Then, when you delete and re-reference one of the dlls it does the same as 2 (above). And if all of the futzing around I will occasionally forget to set the Copy Local to False (as it always defaults to True) and suddenly I have about two hours of fighting and tracking down the problems.
It is a nightmare!!! Is there anyone who feels my pain and knows a better idea about how to use references in VB.NET?