>Hey everyone!
>
>I am a little confused on the issue of deploying developer components. I have a dll that would be useful for me and my fellow coworkers to use. What is the best way to deploy/distribute a developer component? Do they just put it on their local machine and go from there? Should I make a MSM installer file for it and if so how would they reference my component in their program? What concerns are there if I start updating it and to update the old versions of the component? Most of the material I've been looking though just deals with deploying executables, but nothing really on the best way to deploy developer components.
>
>TIA!!

Eric;

This is a most important topic and I am glad you brought it up.

Having just returned from a week of .NET training, I just presented this issue to a fellow developer. We have to consider our strategy at the corporate level. The promise of reusable components/methods etc. through OOP is a true timesaver but there are many responsibilities to be considered. We do not want to allow code to be broken by someone modifying an object.

Using VFP 3.0 in 1995-96 I worked on a major engineering application. It was for the construction industry and was concerned with refrigeration – evaporators and coolers used on factories and large office buildings to provide what we term air conditioning. It did English/Metric conversions on the fly as well as international currency. The companies catalog was used and the interested party would fill out information such as the roof structural loading, ambient temperature, cubic footage, desired internal temperature, number of fans and capacity, etc.

I worked with two other developers and we each had an area of responsibility. We each maintained our own class libraries and mine had all the engineering, currency, and other complex elements. They took care of purchase orders, etc. Having an engineering background was a real benefit to this project. We called in the client and they sent two engineers to see our work. The engineers were thrilled at what we had done and we were ready to start real testing of this $200,000 project and then delivery.

The next day I came to work at my usual 0630 only to find nothing worked. I received error messages that objects could not be found. I looked at my class library and it was apparent someone had modified many things. I resolved the problems, which included re naming objects and placing them in different libraries. When the other two programmers came in some four to five hours later I asked them if they knew anything about this. They said, “Yes. We did not like your naming conventions or which libraries you placed them in”. The owner of the company agreed no one would modify anyone’s libraries or objects.

Planning how to use a component library is imperative. You should also have a library file that defines how an object will be used, parameters, data types, etc. There is no need to have component bloat by allowing everyone to have his/her own pet object. Cooperation, planning and common sense go a long way in having a successful component library. The benefits will be realized once the first object is reused. An improper act by one person can cause all your companies applications to break.

Tom