I am curious what the preferred way to structure an application with an executable client program, an executable server program and a shared model in solutions and projects (using Visual Studio and C#). Being used to Java development I initially regarded projects as packages and defined a project for each package I designed.
This resulted in a six-project solution (one for the model, one for the server and four for the client) which in turn resulted in some silly dependencies causing me to reconsider if this is the best approach.
Now, I am planning to restructure the solution to three projects total: a client project, a sever project and a model project. Both the client and the server will be dependent on the model project (in which I will also add the shared interface between client and sever).
Is this the best way to structure such an application?
Also, what is the best way to reflect namespaces within the tree structure of Visual Studio? (Just creating a similar folder structure for instance?).
A 3-project solution (client / server / model) is indeed the norm for your scenario.
Regarding namespaces: Yes, your folder structure should reflect the namespaces you are using. The default namespace can be set in the project properties, folder names are added to that namespace.
Related
I have 5 basic projects that need to be part of multiple applications. WinForms, ASP.NET, WPF depending on the needs we have.
These Projects are:
Company.Business - Business Logic DLL
Company.Business.Model - Business Models
Company.Business.DAL - Various DALs
Company.Configuration.Classes - Classes that are used to initialize BOs
Company.Utilities - General Utilities
Now i am trying to decide how i should go about when i create new UI solutions?
1) Include the projects by Add->Existing project ?
2) Copy the compiled .dlls to each solution manually?
In case of option 2 where i should do the basic development for all the above? Probably a separate solution that includes them all? and in there i should start unit testing?
My take on this is that it depends on your needs and how mature the "basic" projects are.
Your needs
If you need to look at into the code of the "basic" projects while working on the using-projects, then I'd add them to the current solution with the add-existing project method. In situations with multiple added existing projects I make a solution folder called "referenced projects" and add them in this folder.
Maturity
If your "basic" projects are still being developed (perhaps side-by-side) with the using-projects I'd also would add them in the solution as described above.
But if you have no need to look at the code then you might as well include the compiled dll in your client-projects.
Harry
I am writing a networking library using Google Protocol Buffers. I have a Visual Studio project that performs a custom build step to run the Protobuf compiler, and another project that builds the output classes.
I would like to put the client library and server library in separate solutions. But both depend on the same Protocol Buffers classes. Is it OK if they both contain the Protobuf-related projects?
Edit to clarify: I know it's possible to do this, but I am curious if it's considered good practice or not.
Well, I don't think it's a bad idea, but you might want to consider compiling your protocol buffers project into a .dll file and have your client and server side projects refence that instead. Just cleaner in my opinion.
When you make changes to the .dll you can right click the reference to it in your server and client projects and click Update Reference. Simple as that!
That is OK.
I ususally have several solutions (when I have 20+ projects) with the same set of projects. E.g. I have main solution with all projects I need. And development solution where I also include unit tests projects or similar needed for development perposes only.
There are some links that point to best practices in organizing projects and solutions:
SSW Rules to Better Large Builds in Visual Studio.NET
Structuring Solutions and Projects
Managing Dependencies
Hope that helps to figure out what is the best practice could be applied to your case.
Being new to VS, how may I think of these two concepts, what is the difference?
I find some missing information in the other answers (at least for people who come from other IDEs like, say, Eclipse) . To say that a solution is a container for projects is only part of the thing. The conceptual feature of a VS project (what determines its 'granularity') is that one project produces one output: typically an executable or a library (dll). So, if you are going to code three executables that uses related code, you'll create one solution and at least three projects - probably more.
A solution is a container for projects, and tracks dependencies between projects.
Just to come up with a metaphor..
A solution is like a house, a project like a room. Each room provides a piece of functionality whereas the house, a container of rooms, provides the means to link the rooms together and organize them appropriately.
Kind of corny but I made it up on the fly, so bear with me :)
It doesn't help that Visual Studio seems to make things more confusing. "New Project" actually creates a new SOLUTION containing a project. "Open Project" actually opens a solution containing one (or many) project. (The file menu says "Open Project/Solution" but it really is opening solutions. There is no "Close Project" only "Close Solution" which is accurate.
So, in VS you are always working within a solution. Many solutions contain only one project and newer developers are likely to think of them as the same thing. However you can add other projects into a solution.
In case anyone decides to scroll down this far... I thought the MS docs did a pretty good job at describing the differences. I've copy pasted (and rephrased) the relevant bits here:
When you create an app, application, website, Web App, script, plug-in, etc in Visual Studio, you start with a project. In a logical sense, a project contains of all the source code files, icons, images, data files and anything else that will be compiled into an executable program or web site, or else is needed in order to perform the compilation. A project also contains all the compiler settings and other configuration files that might be needed by various services or components that your program will communicate with.
You don't have to use solutions or projects if you don't want to. You can simply open the files in Visual Studio and start editing your code.
In a literal sense, a project is an XML file (.vbproj, .csproj, .vcxproj) that defines a virtual folder hierarchy along with paths to all the items it "contains" and all the build settings.
In Visual Studio, the project file is used by Solution Explorer to display the project contents and settings. When you compile your project, the MSBuild engine consumes the project file to create the executable. You can also customize projects to product other kinds of output.
A project is contained, in a logical sense and in the file system, within a solution, which may contain one or more projects, along with build information, Visual Studio window settings, and any miscellaneous files that aren't associated with any project. In a literal sense, the solution is a text file with its own unique format; it is generally not intended to be edited by hand.
A solution has an associated .suo file that stores settings, preferences and configuration information for each user that has worked on the project.
A Solution can have many Projects.
The Solution can also handle managing the dependencies between its different Projects...making sure that each Project gets Built in the appropriate order for the final Solution to work.
A project contains executable and library files that make up an application or component of an application.
A solution is a placeholder for logically related projects that make up an application. For example, you could have separate projects for your application's GUI, database access layer, and so on. The projects would be specific divisions for your program's functionality, and the solution would be the umbrella unifying all of them under one application.
A solution is a readable text file whose extension is .sln and having a structured content that describes the projects that it contains. A project is a readable XML formatted text file whose extension is .vcxproj and having a structured content according to its XML schema, and whose primary purpose is to contain the listing of source codes filenames and their dependencies or references to other project's source codes as well.
Solutions are containers for projects - you can also use them to organize items that are used across different related project (shared dll's and such).
Solutions are containers used by Visual Studio to organize one or more related projects. When you open a solution in Visual Studio, it will automatically load all the projects it contains.
When you create a new project in Visual Studio, it automatically creates a solution to house the project if there's not a solution already open.
You can set dependencies of projects on other projects in the solution. The dependent project is build after the project it is depending on is built.
For more details refer - https://learn.microsoft.com/en-us/visualstudio/ide/quickstart-projects-solutions
If you are from an Eclipse background you would probably go to build path of a project and add a dependency on other project or add an external jar. In VS you can do that in a single container called solution where all related projects are grouped together.
Eg. Let's say you are build and android and iOS app in xamrin, there would be some common code and resources that could go in a separate project and then your android and iOS projects can depend on this common code project. Also you could have projects to test these projects etc.
I have been using the Codesmith framework NetTiers to generate a DAL etc., into a folder called, say, 'NetTiers', outside my main project's folder, and referencing the DLLs within that folder from my main project.
I've started using the Plinqo framework, and want to use the generated files from that framework within the same project as the one I'm using with NetTiers. (The reason I'm using both frameworks is that I want to get/learn the newer LINQ goodness from Plinqo, yet also have the familiar NetTiers code DAL, BLL syntax available, for compatibility.)
My question is: what's the best Visual Studio solution and file structure to use when using Codesmith templates like these? Should the frameworks' generated code be contained outside the main project and added as projects to the overall solution? Or should each template's generated code have its own solution? Should the generated files be within the main project's file structure?
I've tried combinations of each of these, and they each have their pros and cons. I'd like to know if there's a tried and tested pattern.
When it comes to .netTiers, I always compile the generated solution and add the assemblies as references to my project. This makes it much easier to upgrade/diff and regen.
However, there are going to be some cases where you would want to add your custom logic so keep this in mind.
Thanks
-Blake Niemyjski
I tend to just keep the .csp and the generated folder outside of my main app's folder. When adding a reference Visual Studio copies in the .DLLs from the built generated code. All of the generated projects sit under a main folder such as D:\CodeSmith Projects\
If you want to version control the .csp file it might be beneficial to move it in with the rest of your version controlled app files to tie it all together.
We put the generated projects inside our solution. In fact on my current project I generated the nettiers files to the location that I wanted the files to be, and Started adding my own project files to that...But we have always kept the files in the solution, that way if i need to add something to the code in the concrete classes I can do it without having to open a whole new project.
We have tried both scenarios. We settled for including the assemblies in a dependencies folder, which was shared by multiple projects.
We had problems with TFS when the projects were included in the solution. the downside, is that you can't so easily step into the .NetTiers generated code when debugging, though after a while you get used to this, and accept that whatever is in .NetTiers stays within .NetTiers!
How do I create a Web Application Project in VS 2008? How is it different from a "WebSite" project?
File--New--Project
instead of File--New--Web Site
It acts as a different container all together and the compile model is different.
ScottGu provided some details when they were first launched: http://weblogs.asp.net/scottgu/archive/2006/05/08/445742.aspx
The main difference is that Web application uses .csproj file which holds the information about all the files in the project. What difference does it make? Using web site model you can add new files without visual studio, since adding new files doesn't require csproj file modifications, but using Web application model you can not.
I personally prefer Web application type.
People have adequately identified many differences, but let me add this broader stroke:
Web Application Projects are architecturally consistant with the other project types in .Net, whereas WebSites deviate and really seem like a throwback to the VS 2003 days.
For this reason, my opinion is that WAP's are more elegant (especially when you have more than one project in a solution).