I would like to know which is the best way to organize the dll tools.
For example, I can have a project that has all the class tools the the company has been implement. For example, class to work with strings, class to work with files... and so on. I mean, a generic dll with tools that I can use in many projects. This would be a generic myCompaty.Utils.dll for example.
Other way it to have many dlls, of for each type of work. For example, I could have a myCompany.Utils.Files, other myCompany.Utils.Strings... etc.
With the first option, I would have only one dll, but if two persons need to add or fix something, only can work one person, because if two persons work at the same time, when one of the person compiles the new dll, the other person loses the work.
If I have many dlls, one for each kind of type of work, then is more difficult that two persons need to modify the same dll, because it's possible that each person is responsible of one of the dlls. However, the problem is that in this way, when I deploy the application, I would have a lot of dlls in the program directory.
So I would like to know which is the best practice when is created dlls.
Thanks.
Apart from the versioning system, (should be a must when more than half developer works on a project), it's really crazy that your organization allows everyone to change the base library (or libraries) on which every other project depends on. This will be evolve in a mess very quickly.
In my shop only one/two people are allowed to change anything there. And these guys are the most skilled and valuable colleagues.
For the subdivision of functionality present in the library I am not concerned with the big one DLL. It's true that I need to redistribute all even when we change a little bit of code (and when your code is mature and well tested this happens very rarely), but keeping track of every dll shipped for this project or for that project outweights the cost of the single one DLL