jkavx
asked on
Solution vs. Project
After many years of working in a Java environment, I'm working with a small team of C# developers. We have several different applications that will share some common code. In my Java experience, this is handled by separate applications, that share a jar file for the common code. In the .Net world, my suggestion is to create multiple Windows form applications, and then create an application for the common code that will build as a .dll. The .dll can be shared by the Winform applicaitons.
There is another suggested approach that puts all the code into a single solution, with each Winform application as a project, and the common code also as a separate project.
Am I wrong to think that since the Winform applications have nothing to do with one another they should be separate solutions. And that the common code should be a separate solution. As development is done on the common code, it can be checked into the SVN repository. Only when the common code is ready for a releaase, should the revised dll be made available to the other applications.
There is another suggested approach that puts all the code into a single solution, with each Winform application as a project, and the common code also as a separate project.
Am I wrong to think that since the Winform applications have nothing to do with one another they should be separate solutions. And that the common code should be a separate solution. As development is done on the common code, it can be checked into the SVN repository. Only when the common code is ready for a releaase, should the revised dll be made available to the other applications.
ASKER
Thx. I just don't see the advantage to using a single solution; since the Winform apps are not related, why group them together? How is it easier to work this way?
The problem I see with the proposed solution containing 2 Winform apps and a library application is that if work is done on the library application that is shared by the 2 Winform apps, updating the solution source code brings the library application changes into the solution. I want to postpone integration of the dll changes until an actual release of the dll is ready. Am I misunderstanding how the projects would utilize the library application project?
The problem I see with the proposed solution containing 2 Winform apps and a library application is that if work is done on the library application that is shared by the 2 Winform apps, updating the solution source code brings the library application changes into the solution. I want to postpone integration of the dll changes until an actual release of the dll is ready. Am I misunderstanding how the projects would utilize the library application project?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thx for the example. It does seem, though, that in your case, the projects can form one coherent whole. But in my case, the projects are completely unrelated, except that they share some common code, basically database access.
A solution is a group of related projects. If you have unrelated projects, then I agree that you are describing a multi-solution scenario.
1) A solution file is a logical grouping of projects. It brings together different projects into one "solution".
2) Projects need references to other DLLs, so the solution doesn't build a single DLL. Each project would still have its own DLL.
3) Single solutions can be easier to work with.
4) You can use SVN with the solution, that would manage the sub-projects, too.