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.
From your question it is clear that you are using no versioning system. Try checking out something like Tortoise SVN - then, you will have no problems with several people working on same piece of software.
Regarding DLLs - I would go with having multiple DLLs, each only containing a specific type of utility methods. It will make deployment simpler. If you would do the opposite, that is, have a single DLL for all your utility methods, you would need to redeploy it everytime anything in it changes - you change the code responsible for working with files, you have to ship the whole DLL that will contain unrelated code, too. Whereas if you'll have multiple DLLs, you only need to redeploy the one that has really changed.
Basically it's going to depend on the number of classes, interfaces and delegates that your library is going to own.
Imagine the case you've 3000 classes in your "Company.Shared.dll" and you're developing a Web application. 600 of 3000 classes are for mobile development. What's the chance of using them in your Web application development? Zero.
So why you'd be deploying a 3000-classes-assembly for a Web application development if you only need Web development-related classes? Library size is greater than a Web-specific one as first can contain code for a lot of things which wouldn't be working in Web development.
For that reason you'd have a shared library called Company.Shared.Web.dll and a common to all development scenarios called Company.Shared.dll.
You can use above logic for other cases and scenarios.
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
Related
I am writing a C# application with Visual Studio that is divided in several modules (namespaces). Every module of course is going to be in charge of some particular function. For example there is a module that will deal with calling some firmware some place else, another module that will deal with just the UI with the user etc.
So far I have no problem doing that. But while writing the first module, I realized that perhaps the classes that I create for this, could very well be used for other future projects since their architectures seem similar.
So I am wondering if it would be a good decision to:
write a separate DLL that deals with all this functionality from scratch and then call that in my project
or just write the project, make it work and then later separate the particular module and shape it like a DLL.
You have to look at all the options and consider everything.
If you create a separate library then you need to be sure that you know all the requirements ahead of time, so that you can keep the library as stable as possible. As, each time you update the library you will need to update all of your projects which use it.
Creating a library will be at least little more work initially.
A well designed and developed library will give you the ability to be able to just drop it into a future project and be sure that it will do what you want.
A badly designed one will mean that you keep going back to it to make changes time and time again and have to keep updating all your projects, or maintain backwards compatibility which means you could end up with multiple different versions of the same method. And end up with something difficult to maintain and update.
You have to weigh all of this up against the advantages you would gain by using a library.
My experience, is that if you need to do something twice then often copy and paste is better. If you need to do it more than that, or sometimes if it is quite complex, then a library starts to pay off. But still for little things copy and paste is still easier, quicker, and lighter.
I'm still learning .NET (specifically C#), and I'm curious as the advantages of creating and referencing a dll versus having a multi-project solution? I have the opportunity to do either one, but I'm not sure which would be better. The projects that would be dlls are rather small, but will potentially be reused. Should size and reusability be a factor when making this decision? Thanks for any and all help.
You're still technically referencing other assemblies as each project generates an assembly.
One benefit of having a multi-project solution is that you don't need to build two different solutions- if you change code in both projects the whole solutions builds in one step. Also you can debug both projects at the same time (which is possible with separate solutions, but trickier).
Size may be a factor in build times, but unless they are huge it shouldn't be a huge issue. If projects are used by other solutions it may make sense to keep them in separate solutions so you can control the build process better.
Having separate solutions can also help you keep the interfaces constant since it's moderately harder to change interfaces through the whole stack.
Each project will still output it's own assembly, but grouping projects does make debugging and building easier.
If you are confident that you can reuse the individual projects in the future, start with a multi project solution. Design your projects carefully to minimize interdependence. If you do a good job of this, it shouldn't be too hard to separate them at a later date when you decide you want to develop an individual project independently from the whole solution.
If the assemblies aren't going to be shared amongst other projects I'd just have them in the same solution.
If the code is shared between projects that's different. I tend to treat code which is shared between projects the same way as any other third party binary - that is, I take a copy of the DLL at a specific version and reference the DLL.
The advantage of that is that, in 6 months or a year down the line when both projects that share the code are on different release schedules, each one has complete control as to when it takes the hit of updating the shared code and dealing with potentially breaking changes.
If you've just built the shared code directly into your project you're at the mercy of changes any other project requires - not a good place to be!
when you are initially developing the consuming programme i find it easiest to have a multi-project solution. but when later you develop another programme that also consumes teh same dll's, just reference tehm.
I would suggest you to add library project and you referencing project in the same solution. You reference the library project using Project reference. That would help you to debug and maintain your code better.
I've gotten to the point where I have made a few classes that I have found to be rather useful for a variety of different projects, they're either extensions of the already existing .Net ones or something entirely new.
Although I may not use them for EVERY project I would most certainly use them again at some point, my questions is what is the best way to keep these stored?
I was thinking about compiling them into a .dll that I can simply reference if necessary but at the moment there are only about 4 different classes, I've always thought that a .dll is more suited towards a larger amount of classes.
Would it just be simpler to store them somewhere in the cloud so I can access them from pretty much any computer?
What has worked best for you?
Edit: I'll be using more than one computer as I sometimes use the university computer facilities.
The classes range from memory management helper classes in XNA to niche functions in regular .Net/C#
If the classes don't fit together naturally as an assembly, keep the source files somewhere like Github and include them in your projects where needed. You can always rearrange them into components at a later date, when you feel it's worthwhile.
Are these classes in any way related? If you want to use one of them, do you need the others? If not, then those don't belong in a common package together.
Robert C. Martin provides some decent introduction in the chapter "Principles of Package and Component Design" of his book "Agile Software Development". There is also a C# adapted version with very similar content called "Agile Principles, Patterns and Practices in C#".
What I'm just saying is, packaging components is not only about thinking components X and Y are "cool enough" to be reused, but also about how you organize things and how well libraries or packages fit into the big picture.
You could compile them as a DLL and install them to the GAC. Then you can reference the DLLs from any project you need, just like any native C# library.
And I agree with Jim Brissom. Compile only the classes that go together as one assembly.
I keep my common classes in sourcegear and then share them into any projects as required.
Over time, the code base I maintain has grown exponentially. We have a variety of different utility classes, webparts, event receivers, console applications, and more.
Typically, each webpart lives in a separate DLL (one solution and one project per web part). Our utility classes have also been largely separated out into their own separate DLLs (this includes any specialized list access classes that get grouped with their beans together in a DLL). This has led to a large amount of solutions which has become more difficult to maintain (upgrading each solution to Visual Studio 2008, or simply just trying to find out the maze of DLL references).
With my discovery of the SharePoint Guidance, I'm re-evaluating our current code structure. For example, it looks like they recommend combining all of your specialized list access classes into a Repository (we've done completely the opposite so far by splitting them into DLLs based on what "solution" the code is for).
Questions: How should I be organizing my code? How do you decide what goes into a solution vs project vs folder or what goes in a namespace? One solution per web part?
I usually organize my code by functionality. Let's say I've got an extranet project and some code for some intranet webparts, I seperate it out into a Extranet and an Intranet project, and seperate the different classes of code (eventreceivers, timerjobs, webparts, etc.) into different namespace.
That way, I can deploy (sub)sets of functionality to different farms if I want to, and when editing code I got everything that depends on one another in the same place :)
When/where do you decide to split a large Visual Studio project into smaller multiple projects? If it can be reusable? when project is too big? (but how big is too big?)
and When you do split the project, do you,
group by database tables
group by similar functionality
other..
Pros of many projects:
Easier to isolate code for unit testing. I like to isolate code that has a dependency on a big external server thing, for example code that talks to the SMTP server gets its own assembly, code that talks to the database gets it's own assembly, code that talks to the webserver, code that is pure business logic like validations.
Pros of few projects:
Visual studio goes faster
Some developers just don't get your vision
about dividing up responsibilities
and will start putting classes
everywhere, so you end up with the
pain of extra projects and the
benefits of putting everything into
one project.
Each project has a configuration and when you make a decision about project configuration, often you have to make the same chagne everywhere, such as setting or changing the strong name key
Pros of many Solutions
You hit the maximum project level later.
Only the stuff in your current solution gets compiled everytime you hit f5
If the project isn't expected to change in the life of your application, why re-compile it over and over? Call it done and move it to its own solution.
Cons of many Solutions
It's up to you to work out the dependencies between solutions and manually compile the dependencies first. This leads to complicated build scripts.
Projects should be cohesive. Logic should be related, and accomplishing a similar goal
This answer will depend on the size of the product you are supporting. In general we organize our projects along domain and logic. And we will divide those even further, the more you divide the more organize you must be, or you are going to hit the dreaded recursive dependency issue.
When I do choose to break up project it is when it grows to be too large or two areas are becoming too similar.
When complexity is rising I do not split by tables, i generally split functionality.
Re-usability is another excellent time to reduce lines of code, as well as introduce a new project. However be careful how many "utility" libraries you introduce because they do have impact on readability/understandability.
I do not think there is a line in sand that says, if you hit 3k SLOC, you have too much. It all is contextual.
I always have several projects (and therefore a solution) , instead of one project with all of my source in it.
In some cases, it is unavoidable because you are using and open source library and want to be able to debug it. But more pragmatically, I typically have my applications provide functionality via plugins. This allows me to change the behavior or offer a user-selectable behavior at runtime. In the non-plugin case, it allows you to update one portion of your program without updating everything. There are also cases where you can provide the main apparently, and only download the modules / assemblies when you need them.
One other reason is that you can create smaller test apps to exercise an assembly, rather than building a very large solution and potentially requiring a user to execute several (and irrelevant) GUI operations before even reaching the part you want to test. And this isn't just a testing concern -- maybe you have less-savvy users in your organization that only want to be presented with the bits that concern them.
When the overall purpose of the project remains the same, but the number of classes is becoming large, I tend to create folders and namespaces to better group functionality within the project. Classes that are coupled to each-other tend to go in the same folder/namespace, so that if I need to understand a given class, the related classes are nearby in the Solution Explorer. I usually only create new projects if I realize that a particular piece of functionality is very different in purpose or if there is a common dependency between existing projects.
I usually wind up with a few relatively small Framework projects that define interfaces for loose coupling between other projects, with larger projects for the different types of concrete functionality. That's always at least one project for the UI and one project for logic and data (often split into two projects if the data layer becomes very large in its own right.)
I move code to a new project, if it has general functionality (theoretically) usable by other projects too. If the project is large, because it represents a complex problem, then namespaces provide a great way to bring order in the code. Here you can for example introduce a (sub-)namespaces for each SQL table, etc. etc.