I am new to C# and want some help regarding some small task.
I have two projects (Project1 and Project2) which are dependent on each other. I would like to call the methods from Project1 which is used as reference in Project2 without creating object of Project1. This means that I don't want to use Project1 directly because if I do so and some changes are made in Project1 I will have to recompile Project2 as well.
Can we create any intermediate project (say Project3) which will work as bridge between this two projects? So that Project3 can be used in some other task if needed. If this is possible then please let me know how?
I have stuck due to this.
Related
I'm writing a program in C# that has two classes, Foo and Bar. I have two executables that will use them, GenerateFooBar and SearchFooBar. My question is how should my solution be partitioned? From what I can gather, everything can live in one solution and each executable should have it's own project. Should Foo and Bar
share a project?
each have their own projects?
go with one of the other projects?
something else?
Thanks for the help! I'm coming from Java if that's helpful.
In your solution, create project called for example Common, and put all your classes and businbes logics there. Set project type as Class Library
Next add your other projects and in them Add Reference to Solution Common project to use it.
If multiple users are meant to work with the shared library, the best solution will be to create the local nugget
Create a shared project and put Foo and Bar into it. Reference that project from both executable projects.
If you later have many developers depending on the shared library you might make it into a Nuget package that you publish and have them depend on that.
From what I can gather, everything can live in one solution and each
executable should have it's own project.
Yes, you are right.
how should my solution be partitioned?
Totally depends on you and how you would like to manage it.
You could create one project, multiple projects, each separated projects, etc.
But, to reuse code as much as we can and to give a more structured way. Here is what you can do.
Make one Project which will hold the ApplicationServices, Helpers, etc eg: Foo and Bar.
Make Another Project which will hold the application itself (Could be two projects one for search and one for generate). You can add reference of service project to your foo and bar projects and to any other project you create in future.
So in the end you will have 2 or 3 projects (depending on you)
1- ApplicationServices
2- Generators/GeneratorServices/GenerateApplications/anyname
3- Search/SearchServices/SearchApplications/anyname
There are a lot of variables and methods in my program and I want to seperate some of them in other class files. But as the program grows the methods and functions can change.
I searched on the net but many people generally speaking for dll files. Without making a dll file, how can I arrange my code and split into small class files?
Yes, just split it out in to a separate file in a new class but still inside the same project. The term for what you are doing is called Code Refactoring. There are some tools built in to Visual Studio to make it easier to do, and there are some 3rd party tools that add even more features to make it easier to do.
But all it boils down to is just making new classes in the same project and referencing those new classes from where you took the code out from.
You can add folders to your solution. Classes are by default a namespaceprovider, so that classes in this folder have a different namespace.
For example if your default-namespace is MyNameSpace and you create a folder called Entity then all classes in this folder have the namespace MyNameSpace.Entity
And all Items in a project are compiled to one single dll or exe
Just add more classes to the project and put the data and behavior (methods) into the appropriate classes. The project will still build into a single exe or dll.
Generally, it's better to add a second project under the same solution call it "CommonLib" or something like that. Then you add it as a reference to the main application and set up the project so that the applications build depends on the libraries build. Add a using statement for the common lib where ever you want to use those objects. This is definitely better for large scale or enterprise applications. There's a pretty decent chance that somewhere down the line you'll want to reuse some of this code, if everything builds into a single exe that won't be an option.
I am creating a dll project. In this project I have a main namespace, for example myClasses. In this project, I create a new folder, myClasses2, so I have a second namespace, myClasses.myClasses2. When I create the dll, I get the myClasses.dll.
In other project, for example in a WPF project, I add a reference to this dll, and I can do "using myClasses" but I can't do "using myClasses.myClasses2" so I can't use this second group of classes.
There is any way to have, in one dll, the two namespaces? I would like to avoid to have two separate dlls, one for myClasses and other for myClasses2.
EDIT1: Thanks to all. The problem is that the classes are not public. I use the default when add a new class. When I set the class as public and generate again, I can using the second namespace.
Thanks.
Project1 = Asp.net pages project (presentation Layer)
Project2 = Data Access Layer
when Project1 is hosted and running smooth, if i have to add few PRIVATE methods into the Project2 and call these methods within some of the PUBLIC methods that i know are being called by Project1, should the changes apply that i made in Project2?
I did the above, but the new methods were not called. (I think Project1 is still pointing to the old assemblies of Project2)
I am sure if i rebuild the Project1, the changes will work.
But if i have to rebuild Project1 after every change i make in Project2, what is the point of having the separate tier Architecture? I thought the good thing about separate tiers is that one can do as many changes in 1 layer, without rebuilding the other layers ... is that a wrong perception?
You don't HAVE to rebuild it. You can just copy the new project2 dll to the web app\bin directory and it will work if the interface hasn't changed. A build of project1 will redundantly rebuild project1 and produce the same result, and also include the latest version of project2, that's why it works, too.
First of all separate tier doesn't really mean separate assemblies. A multitier archtecture program can easily be stored in 1 assembly and have DAL, presentation and BL classes separated by some logical separator like namespace or even project folders with classes (or even no logical separation whatsoever, but you will known that certain set of classes is for DAl, and annother for BL, etc)
To your question - if your DAL is generic and has a fixed interface you can update your dal assembly ( for example fix some buggy methods, or something else) if you dont change interface of public methods. Obviously if you change some interface your other assemblies that reference this assembly will have to be not only rebuild but rewritten in order to use new method names for example
Project1 = Asp.net pages project (presentation Layer)
Project2 = Data Access Layer
when Project1 is hosted and running smooth, if i have to add few PRIVATE methods into the Project2 and call these methods within some of the PUBLIC methods that i know are being called by Project1, should the changes apply that i made in Project2?
I did the above, but the new methods were not called. (I think Project1 is still pointing to the old assemblies of Project2)
I am sure if i rebuild the Project1, the changes will work.
But if i have to rebuild Project1 after every change i make in Project2, what is the point of having the separate tier Architecture? I thought the good thing about separate tiers is that one can do as many changes in 1 layer, without rebuilding the other layers ... is that a wrong perception?
You don't HAVE to rebuild it. You can just copy the new project2 dll to the web app\bin directory and it will work if the interface hasn't changed. A build of project1 will redundantly rebuild project1 and produce the same result, and also include the latest version of project2, that's why it works, too.
First of all separate tier doesn't really mean separate assemblies. A multitier archtecture program can easily be stored in 1 assembly and have DAL, presentation and BL classes separated by some logical separator like namespace or even project folders with classes (or even no logical separation whatsoever, but you will known that certain set of classes is for DAl, and annother for BL, etc)
To your question - if your DAL is generic and has a fixed interface you can update your dal assembly ( for example fix some buggy methods, or something else) if you dont change interface of public methods. Obviously if you change some interface your other assemblies that reference this assembly will have to be not only rebuild but rewritten in order to use new method names for example