Wrox Programmer Forums
Go Back   Wrox Programmer Forums > Visual Basic > VB 6 Visual Basic 6 > Pro VB 6
|
Pro VB 6 For advanced Visual Basic coders working in version 6 (not .NET). Beginning-level questions will be redirected to other forums, including Beginning VB 6.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Pro VB 6 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old February 9th, 2004, 11:20 AM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 128
Thanks: 0
Thanked 0 Times in 0 Posts
Default Are you using Visual Source Safe?

I am in the process of implementing Visual Source Safe and was wondering a few things:

If you are using it and how well you like it?

I have a hard time understanding how this is going to work with ActiveX components that are required to be registered on the development machine? This is actually my biggest concern.

Why I am concerned. As should be much of the code we use is modularized into classes and dlls. On the development machine if I am working on a project the dlls have to be registered and the class modules are all based on a relevant path to the project. If we have multiple developers not all paths are going to be the same for each developer. In addition what about managing dlls? The documentation suggest having the dlls as part of the project. If I check out a project how can I be sure I am getting the latest version of the dll? It also seems that I would have to update each project that uses the dlls. Currently I have a library of classes and dlls. Project reference those libraries and if a dll is modified all project are updated by association.

I think largely this is my ignorance showing I am sure it is a much better way to manage projects but I need more information. Can anyone recommend a good book?

Thanks in advance for any help?


Larry Asher
__________________
Larry Asher
 
Old February 9th, 2004, 12:53 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 101
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via MSN to jlick
Default

There are many things to consider here, and you really need to meet with all the developers and hash out an agreeable solution.

Here are some suggestions though:
1) You should have all classes in exactly one DLL. It is just bad coding to have classes that are part of multiple components. It makes it very hard for maintenance. Also it wastes resources on the client computer. I have worked at a place that had a class that made SQL calls. Rather than having this class be part of a DLL, and thus only loaded into memory once, they had each component load the class directly. This means that a copy of the class is loaded for each component. At this particualar company, their main product/program loaded this class in memory over 250 times. What a waste. Also to have improvements to the class, they would have to recompile each of the 250+ components.
2) When working with DLLs. You really need to look at how your development process works. I have worked at places where you had to do a "Get Latest" from VSS every morning. This way you would only be a day or so behind the new updates. This could mean unregistering and reregistering the DLLs. It will make your lives much better if you understand binary compatability, and try to design not to break it.
3) I have found that breaking your components into logical parts, and having one "bin" project in VSS to store the DLLs/OCXs. Rather than storing them with the code is helpful. This way, if you (as a developer) are just looking for the latest version of a compiled component that you are dependent on, you don't have to do a lot of tree navigation.

Overall, you need to look at how your group's development process works, and determine if there are reasonable rules that you can put in place. If not, then you may have to adjust your process to work inside of the constraints that you have. This is not a one time magical fix. It takes making some rules, seeing how they work, then in the future adjusting them.

Remember that developers love their own habbits, and that coming in with a set of rules that the developers don't have input into will not resolve anything, because the rules will not be followed if the group doesn't agree with them.

John R Lick
JohnRLick@hotmail.com
 
Old February 9th, 2004, 01:29 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 128
Thanks: 0
Thanked 0 Times in 0 Posts
Default

John,

I like the idea about the BIN directory and much along the same line of thinking I have. But, it is contradictory to the guideline in the VSS documentation - noting it is just a guideline.

I am glad to see how adamant you are about classes and dlls. But, if we consider OOP almost everything is a class. Not all objects are dlls. The dlls themselves are a group of classes compiled with the intent to be shared. On the other hand individual projects may contain only class modules specific to that application. In either case, these class libraries still need to be maintained.

As you, I am in strong favor of binary compatibility. If you break it it is probably a good time to rename it - depending where you are in the development phase.

It sound like you have had some experience with VSS. From what I am gathering you have to create all of the dependent relationships manually. This is another fear of mine, having a project checked in then checked out missing some of the dependencies. In your experience did you find this to be a problem?

Thanks for your reply.

Larry Asher
 
Old February 9th, 2004, 03:14 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 627
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi Larry,

my division uses Source Safe and we like it ok (well, it comes for free with MSDN...) but as the division grows (we now have developers in three countries across two continents) we realize that working remotely with SS is not efficient (slow slow), and we are investigating other products.

As for binary compatibility, we found out that the problem is not SS per se, but mostly the VB IDE and the virtue of the developer. If you check out a file within the IDE, the application automatically gets the latest. But if you use the IDE disconnected from SS (happens working remotely) if you check out and get the latest under SS, the IDE does not realize that a file in the project has been changed, and happily continues with the old version (to be 100% sure I always exit VB before working on SS).

I agree that binary compatibility IS a problem. If someone forgets to get the latest or, worse, changes an interface WITHOUT COMPILING AND CHECKING IN THE BINARY (I capitalized this because it is easy to forget) all the compatibility breaks right away. Usually we call each other when a change as been made in an interface, but things get messy once in a while. Not for nothing this problem is calles DDL Hell...
Rule of thumb: get the latest in the morning before start working, and hope that everyone is virtuos :-)

John's statement (all classes in one DLL) leaves me perplexed. We have dozens of servers, dlls and ocx in our application (written in both C++ and VB), it would be problematic to fit all classes in one object (besided going against the concept of distribuited components) But I agree that it is much better to put shared coded in one component. You start with one shared Form, and soon as the projects goes that form start using external classes, modules or dlls. Every change in that form breaks all the other projects that use it! Shared coded must be simple and self contained (like constant definitions or simple methods) Well, I am going to far here, sorry for this long post ;)

Marco
 
Old February 9th, 2004, 03:19 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 101
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via MSN to jlick
Default

Unless you have a good management/tracking system, dependencies are always an issue. Do you track this in something like Rational, or build your own. How do you enforce it. These are all process questions, and the answers are different depending on the size of your team, and the types of applications that you develop.

As for the classes that are in exe's, again it depends on what type of development you are doing. I do mostly business application developement, not scientific or game development. For business development, I strongly believe in having N-Tier, even if all the tiers except the DB on the client box. This type of development wouldn't have classes on in the exes. This is not a good model for Game development (as a friend who owns a game company tells me). I don't know if it is good for scientific development.

If you build a good framework, then you can write N-Tier applications almost as quickly as you write an exe that does it all. This then gives you the option to reuse more code. But it takes more planning, and you have to take the time to build the framework.

If a class is part of just one exe, and it will only be used by the exe, then you don't have to worry about re-use, so the comments I made aren't applicable. But you need to consider that things change, and you may end up wanting to reuse something that you didn't expect when you wrote it.

If you use the bin directory approach, then you should get latest from the Bin directory. If you aren't changing code in one of those components, then you should be referencing the dll, not the code. Therefore you shouldn't need to worry about it. If you are making changes to the DLL, then you should get latest in the bin directory, and get latest from the code directory. If you componentize properly, and you follow this, then you shouldn't have issues. THESE ARE BIG "IF"s and you need buy-in from your team.

Again, you really need to have the team determine what will work best, and review the process and fix things that aren't working for you.

John R Lick
JohnRLick@hotmail.com
 
Old February 9th, 2004, 03:25 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 101
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via MSN to jlick
Default

I think I must have worded things poorly. I did not intend to say that all classes should be in one project. What I ment to say was that if you have classes that say: 1) Call SQL, 2) Handle Nulls, 3) Do other DB related stuff. These should be in one project (DLL/OCX as the case may be). Then you are not loading them with each component that uses them.

To have all classes for an entire department/company in one component would be stupid. And if what I wrote was interpreted this way, I appologize.

(When I use the term Component I am referring to a DLL, EXE, OCX, not a class as many people use the term.)




John R Lick
JohnRLick@hotmail.com
 
Old February 9th, 2004, 03:31 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 101
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via MSN to jlick
Default

In line with Marco's comment about the IDE & VSS, I turn it off right away. I hate how it works, and I only use the VSS UI, and I reload the project in VB whenever I make changes in VSS directly.

As for using VSS over long distances, I spent many years using VSS's "thin" client. This is a client that is installed, and it works well over the web. I actually like this better than the real VSS interface, because it gives better statuses of files. It is missing many things that the thick client has, but for someone who is only doing development, (not management of VSS) I like it better.

I was only doing this in the USA, but I was going from CA to MI (Pacific Time Zone to Easter Time Zone) and with a T1+ style connection, I didn't have speed issues. I expect that it may be different going between continents.

John R Lick
JohnRLick@hotmail.com
 
Old February 9th, 2004, 04:45 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 128
Thanks: 0
Thanked 0 Times in 0 Posts
Default

I appreciate the feedback from each of you. This will really help me in planning the implementation. Our department is not very big <10 developers. As of now all are on site, but we are talking about joint development with a sister company in another state.

The funny thing is I just spent 6-8 months of the last year developing an Electronic Document Manager application for our engineering department. I keep wondering if I shouldn't look at using it. In regards to that version control becomes the biggest issue. But the more I am learning about VSS our EDM may be a good alternative.

Thanks for all of your input.




Larry Asher
 
Old February 9th, 2004, 05:25 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 101
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via MSN to jlick
Default

I have spent the majority of the last 10 years doing EDM & Imaging. Standard EDM products are a bad fit for tracking code. There are many reasons for this, including being able to merge code. View differences, etc. If you choose to go a different route than VSS, I would suggest investigating products that are aimed specifically at code management.

John R Lick
JohnRLick@hotmail.com
 
Old February 9th, 2004, 06:31 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 128
Thanks: 0
Thanked 0 Times in 0 Posts
Default

That sounds like good advice.

Larry Asher





Similar Threads
Thread Thread Starter Forum Replies Last Post
Source Code re Ivor Hortons Visual C++ 6.0 gavin_murray Visual C++ 5 September 27th, 2007 09:05 PM
Visual Basic .Net Business Objects Source Download LMDSD Forum and Wrox.com Feedback 5 May 20th, 2005 04:24 PM
Visual Source Safe "Replace Writable Files" ritag VB How-To 5 August 16th, 2004 04:59 PM
Source code for the book "Visual C++.net: a primer Julie Lin .NET Web Services 0 September 29th, 2003 02:40 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.