I would like to create utils class library (eg, logging, etc).
I want to use the utils solution in several indepandent applications.
I'm using source control of course...
does that mean I should manage utils solution (holding the utils class library)
and also seperate solution for each application ?
what do I have to do to use the utils class library from ApplicationA solution
can ApplicationA solution also include the utils solution (eg, go to definition works ?)
if that is possible, does that mean that any change proggrammerA apply to utils library via ApplicatioA solution, also affects ApplicationB solution using the same utils class libray
what do we to do when we fix a bug in utils solution ?
how does the fix bubbles to ApplicationA and B .
It sounds like you have the possible approaches identified already:
Develop and manage your utility library independent of any specific application.
Advantages: no need to manage multiple versions, updates done in one solution don't impact/break other solutions
Disadvantages: the Utilities assembly is essentially a closed box, a component your applications are consuming, the same as any third-party or .NET framework assembly.
Put your Utilities library project into source control, and have the solution to each of your applications include it as a project reference (this is possible, to answer your question above).
Advantages: Utilities library is kept up to date in all projects, and can be stepped into during debugging, etc.
Disadvantages: Changes made to Utilities as part of development in one project may break it for another. Also, this may add issues with versioning, you may need to roll back changes for patch builds, etc.
Create a new copy of the Utilities library for each project
Advantages: no issues with build, debug, deployment or versioning
Disadvantages: changes made to the Utilities in one project are not reflected in others, and must be manually copied over if needed.
At the end of the day, there is no one correct answer; it depends on the stability of your utility methods, how often they need to be changed, and how often you will want/need to debug into them.
In most cases, I find that it is more convenient to just create a new copy of the Utilities class library for each project. They end up being somewhat different eventually, but the ease of maintenance makes up for the lack of consistency across all projects. If you had a very complex set of utility classes that encapsulated some portion of your business, you would probably want to go the other way and maintain it independently.
I think you need to read up on how to distribute APIs for consumption. You should keep this as a separate project. Version it how you would something you release to the public. If you make a change in the utils and you need it in AppA, thats fine, just know that until you test with AppB you will either need to use a branch or the old version of the util class.
Related
Task: reuse C# code in different projects but without project referencing (don’t want extra dll/references just because of a small utility class).
There’re 4 projects, one of them contains utility class which is currently source-code-linked by other 3 projects.
Problem: once one of the projects starts referencing one of others (for some other needs), the compiler starts complaining (obviously) that there’s the same class (with the same namespace) in these projects.
Are there any solutions other than to move the class to separate project or to make 4 copies of the class for each project and maintain them separately?
I wonder is there a way to source link files so that the class inside a file gets project-specific unique namespace…
I wonder is there a way to source link files so that the class inside a file gets project-specific unique namespace…
Well you could use preprocessor directives:
#if PROJECT_FOO
namespace Foo
#elif PROJECT_BAR
namespace Bar
#elif PROJECT_BAZ
namespace Baz
#endif
... and then link the file into each project, defining appropriate symbols in the project properties.
But I would thoroughly recommend against it. It's horrible, and it's certainly not how C# was designed to be written.
Just break it out into a separate project - you're bound to find you want more and more code like this anyway.
To the question:
"Are there any solutions other than to move the class to separate project or to make 4 copies of the class for each project and maintain them separately?"
The short answer is: no, there isn't. Or at least, there is no elegant way of doing that.
The right way is indeed to make it part of a referenced project. But you don't have to make a project that will contain JUST that utility class! Instead, make it a project holding multiple simple utilities with as little dependencies as possible and share it across your solutions. Much easier and cleaner this way.
i joined a new project where they use c#.
I noticed that several dll's were being add in the references
From my knowledge and the e-learning that i have done, after building a class(which has some Methods & data), a DLL is generated.
Now in a new project, the class that just got converted into a DLL is added as a reference so that the functions defined in it could be called.
So, now my question is:
1) what is the need for converting the class file into a DLL file. Even it were a Class file, I could still be calling the functions defined in it by adding its namespace at the top of the code
2) If After adding the reference of the DLL , I deleted the entire contents of the project, leaving only the dll untouched(and in the same place), would the class using this dll still work
Separating your code into different projects (each of which will create a separate assembly) has various benefits:
It makes the structure of your code clear. For example, it can separate your storage layer from your business logic, and also from your user interface.
It allows reuse: two different user interfaces can refer to the same assembly containing the business logic, for example.
It allows greater encapsulation: classes which are only needed within their own assemblies can be declared as internal (which is the default for top-level classes in C# anyway) which means code in other assemblies won't even know about them. If all your code is in a single assembly, all those classes will "know about" each other.
Now choosing just how many projects to have is a balancing act - I've certainly seen applications where this has gone much too far, with lots of assemblies containing just a single class. If you have a large number of assemblies, that becomes a headache in terms of project and reference management. However, having too few assemblies makes it harder to reuse that code cleanly.
In addition to Jon Skeets answer, I'd like to add "updateability" as well. For me, this has two benefits
one is that the build time becomes smaller if only one project needs to be rebuilt
and second, pushing to "release" could be limited to a few dlls instead of one major .exe.
The first might not be a big deal in C# since projects build pretty fast, but for instance switching to C++ would be a big impact, since C++ code take a long time to compile.
The benefit of Separating is that it lets you change the internal implementation without breaking client code. It doesn't protect you if you decide that you need to change the interface to your code, but that's a different matter.
they can reuse their code. but if they use classes every time they need to implement these classes ( in the best way copy and paste all codes )
when they use dlls in instead of classes they can update all project easily by just Update one or more dll although if you use class in multiple projects you suould modify all classes in all projects.
I might add that a class is a language construct while an assembly is a deployment package.
Already in UML those are two totally different things.
http://en.wikipedia.org/wiki/Package_(UML)
When approaching the new idea of subdividing a solution, projects may be seen as "places" in which to put namespaces (i.e. folders) and classes (i.e. files).
It will take some time until you realize that a project best fits the concept of stratum (or layer) which is an architectural separation of a system.
When stratifying a system, you'll realize that the most crucial problem to tackle are the dependencies between strata (which would be the references to projects or dlls).
There cannot be loops but more important, you should study OCP (Open-Closed principle) and ISP (Interface Segregation Principle) and DIP (Dependency Inversion Principle) of SOLID:
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
At that point a new question will emerge. How can you know which classes depend on each other or do not? You may draw class diagrams, but there is a conceptual approach to the problem. Over the years it becomes a "practice" of designing systems. The concepts are described for educational purposes in GRASP:
http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)
The most important parts of GRASP for stratification are "Low Coupling" and "High Cohesion". In other words, you should batch functionally very similar classes in a stratum and separate through the stratification classes that functionally are not very much related to each other.
just finished one of my projects and about to start another. This is never taught in my university so i dont even know if it exists. Lets say for example you have the code...
MessageBox.Show("Hi");
Now i know i can call it in Form1.
I also know i can call it in another form providing it is in a public class / void or something?
My question is, is there a library system where i can add 30-40 code snippits each to do their own job. So when i want to update sql or run calculations i just call a code file from a library?
Sorry if im missing something obvious google is driving me insane, i know what i want to ask, just not how to ask it! Hope you understand my question..
Thanks, Regards..
Of course. In your solution in Visual Studio you can add a Class Library project and fill it with all of the re-usable code that you want. Then any project in the solution can reference it by adding a Project Reference to that project.
Note that it's very easy to go overboard on something like this. Take, for example, your example:
MessageBox.Show("Hi");
The MessageBox class is tightly coupled to the user interface. So it belongs in the user interface objects. (The forms in this case.) This is because if you try to use it in your class library then you would need to add user interface libraries to that class library, making it more tightly coupled with that specific user interface implementation. This makes the class library much less portable and less re-usable because it can only be used by projects of that same user interface technology. (Can't be used by web projects, for example.)
So you'll want to think about each common utility that you encapsulate into its own re-usable code. Does it belong in the UI, in the business objects, in the data access, etc.? If it's tightly coupled with a specific periphery technology (user interface technology, data access technology, etc.) then it probably belongs there.
One approach to this would be to have multiple "common utilities" libraries. Using a contrived naming scheme, a larger enterprise domain solution might have projects like this:
Domain.BusinessLogic (class library, referenced by everything)
Application.Forms.AdminPanel (forms application)
Application.Forms.OperationsPanel (forms application)
Application.Forms.Common (class library, referenced by other Forms apps)
Application.Web.PublicWebsite (web application)
Application.Web.Common (class library, referenced by other Web apps)
Infrastructure.DataAccess.SQLServer (class library, dependency-injected into the Domain)
Infrastructure.Vendor.SomeService (class library, dependency-injected into the Domain)
etc.
So you have a core business logic project, which contains anything that's universal to the entire business domain in which you're working. It should have no dependencies. (Not rely on user interfaces, databases, frameworks, etc.) Then you have applications of various technologies, into which are mixed class libraries which have application-coupled common functionality. And finally you have the other periphery of the domain, the back-end dependencies. These could be your data access layer, integrations into 3rd party systems and services, etc.
As any given piece of functionality is abstracted into a common utility to reduce duplication and increase re-use, take care to keep your code-coupling low so the "common utilities" aren't tightly bound to "uncommon dependencies." All too often in the industry there's an increase in tight coupling with code re-use. (See the Single Responsibility Principle.) So exercise good judgement to avoid that.
There's nothing inherently wrong with writing the same piece of code ("same" by keystrokes alone, not necessarily by conceptual purpose) more than once if it serves more than one responsibility and those responsibilities should not be mixed.
It sounds like you want to use static methods. Group your routines by what they do, and put them in a static class, .e.g
internal static class Utility
{
public static void Method1(int whatever)
{
// do stuff
}
public static void Method2(string another)
{
// do other stuff
}
}
You can then call them like:
Utility.Method1(7);
Utility.Method2("thingy");
The simple solution is create a new project and select the "Class Library" option. This will create a class which is compiled into a DLL (dynamically linked library). Everywhere you want to use this common code you add can add a reference to the assembly, then in the specific files you use it, you'll have to add a using statement for it.
If you're required to turn in multiple projects you could put all of them under a single solution. If you right click the solution and select the properties option for the drop down menu it will open a new window with a "Configuration Properties" option in the left nav bar. Select it, then you can specify build dependencies. So if you have projects A and B which use methods in project C (the class library) then you can set that as a build dependency meaning whenever you build project A, B or the solution as a whole, it will first build project C.
This is commonly how enterprise software is structured; some dll's or exe's that are the application level code, then many other projects which build common code that is often shared by multiple projects. All of this is usually put under the umbrella of a single solution.
If you go this route there are more details (like which exe runs by default when you debug) that I can update with. It's probably nothing you'll be taught in university but you'll most likely see as soon as you start your first job.
I wrote some classes that I use with many different projects.
For example, I use Library.Controls.FlatButton.cs almost in every project.
The problem is when I add this as an "existing item"; the class gets created/copied in my soultion folder everytime. And each time I edit/update the contents of that class, I have to update all the Library.Controls.FlatButton.cs files in every project folder.
I need to be able to edit a single source of FlatButton class and when I compile/build a project (that uses the class file) gets updated to the new version of that class.
Question 1: Is there a way to do this?
I know that I can gather all these classes in a library project (Library.Controls) and add it to each application solution as a dependency.
Question 2: Is this the only way to work from a single source of common library files? And if I do; will all the classes in the Library.Controls namespace get compiled with every application, even if I've only used this FlatButton class in the project?
Hope this is clear for you..
thanks
I'd rather go with the approach of the shared library and add them as references to your client project.
If you don't want to do this. You could add the file as "Link". In Add existing item, select Add as Link instead.
Yes, a class library is the way to go and yes, since the whole class library will be referenced from your applications, all the classes will be available to it.
However, the fact that all the classes are available is not a bad thing, since they're in a separate class library it won't make your applications harder to understand (since the amount of code in those applications will stay the same), it might just be that you use up a little bit more hard drive space, though if you really worry about that you could put the class library in the GAC so that all apps reference the same copy of the library, though you'd better research this first to make sure that it's suitable for you.
Alternative way is to add FlatButton.cs file "As Link":
How should I divide source files into projects (within one solution) to
be able to use common classes in more relatively independent apps,
avoid lots of dlls needed (preferably all in one file for each application),
keep it fast?
There are working (data processing) classes, User controls, some utility classes and Forms of the application.
You can make a separate assembly by creating a class library, and use that library within other projects within your solution. Just put your reusable classes within a class library project, and add a project reference in your applications to that library.
Each time you separate out code into a separate (reusable) assembly, it does add one extra DLL (the class library project) as a requirement at runtime, but this is very minimal.
There are no real (significant) changes to performance when doing this. It is a very common practice.
You should make Class Library project(s) for each logical unit of classes, then add references to the libraries in each project that uses them.
For example, you could have a Common library that contains basic classes used by everything else, and perhaps a Controls library that contains user controls.
Each logical unit of classes can go in a namespace within the same library or in a separate library; you need to decide which.
It would be a good idea to drop the second requirement of avoiding lots of DLL's. If you put your common code into a single "common" DLL then you need to recompile every time any class is added or modified. This could then give you a terrible versioning problem that is worse than managing lots of DLL's.
You should group your common code, by the functionality they provide, into separate DLL's. So one for data access, one for user controls, one for each type of utility function, etc. Then if you have web service that accesses data you won't need to recompile the service when you add a new user control to a single DLL. Only those apps that depend on the change will need to be recompiled.
You could put the common classes into one assembly (say CommonUtils) and then use namespaces inside for the groupings to indicate how they are split