In Eclipse, I have a workspace that contains all of my projects. Each project builds and compiles separately. A project does not interact with another project.
How does this relate to Visual Studio and Projects/Solutions there?
A VS project is it's own entity. It will build and compile by itself. A Solution is just a way to contain multiple projects. The projects don't necessarily need the other projects to compile (though, they can depend on the other projects).
This just lets you conceptually group projects together into one Big Project. For instance, you can have a separate testing project. It depends on the code from the actual project, and should be kept together with the actual project, but it does not need to be in the same exe/dll.
Each VS project builds a single EXE or DLL. The solution is just a collection of related projects.
So VS project:Eclipse project::VS solution:Eclipse workspace.
Another way to look at it is, a solution is a container for projects. For most of my work , I create each tier as a project within a solution so my tree looks like:
My Web App or Win App
Presentation Layer
files...
Business Layer
files...
Data Access
files
Your mileage may vary
#Thomas Owens:
Yes, some (most?) people using Eclipse have more than one workspace. It's what surprised me the most when I first started using Eclipse, so I'm replying here to make this comment more visible.
The thing that may be throwing you off is the following:
In VS2003, everything had a Project file and a Solution file. If you had a Solution with one Project, you could open the Solution and see the one Project. If you opened the Project, it would try and create a new Solution file to contain the Project. But web projects and Winform projects all had Projects and Solutions.
In VS2005 this changed a bit - by default now, Web projects no longer had Project files. They had received feedback from some web developers that didn't like Project files - their take was that if a file is in the directory, it's part of the app. After VS2005 shipped, they got more feedback from developers who did like the Project file notion, so they patched it back in. This is "Web Site" versus "Web Application" in VS2005 (and I can't remember which is which now).
In addition, in VS2005, if you have a Solution open with only one Project, you won't see in the Solution Explorer that there's even a Solution at all, you'll only see the Project (as if it was not in a Solution). Only after adding the second Project will you see that there's a Solution containing them both.
So basically you were on the right track - Solutions and Projects work the same in Visual Studio as they did in Eclipse, it's just some quirks that make things confusing.
A Solution has 0 or many Projects...
There are way too many kinds of web projects in Visual Studio 2008. There are Web Site Projects vs. Web Application Projects and they limit you in different ways. It's a good example of Microsoft providing too many choices instead of focusing on one strong solution. Even within the Web site Project option, there are at least 3 different ways to compile your application.
I found that not always seeing the solution in the Solution Explorer to be irritating. There is a setting in Options->Projects and Solutions->General called "Always Show Solution" which was handy.
Related
I have a ASP.NET project that consists of many C# libraries in addition to the web project. The problem (for some reason) is that all projects that make up the web application are NOT added into one solution within a same visual studio. Instead, most projects are separated within individual visual studio. All projects are stored in source control, and shared by other developers.
Thus, the question is that how to find usage of any code, like "Find Usage" via Resharper. Is there any tools or tricks that allows me to do that like Resharper's Find Usage.
Any advice?
It looks like you're in something of a bind. My suggestion would be to simply make your own source control branch, and in that branch, you can create a new SLN file, add all of the projects, replace their binary project references by project references and then call Find Usages. Then, if you need to do any changes on the basis of Find Usage info, simply merge those in without merging PROJ or SLN files.
If these library projects are referenced as DLL files rather than the project references the only way is to open all the one-project solutions and search there by 'text'. There are some tips/tricks, which could simplify navigation a bit.
P.S. The situation you described looks far from convenient. I agree with Dmitri - you might consider to discuss with your team to switch onto referencing projects rather than using binaries. Once you switch each developer will be able to create local either solutions with the projects involved, or maybe you will agree on new common source controlled solutions.
In every tutorial and HowTo site (like here) about WiX I read I should add reference to my other project, but when I select Add Reference I have nothing on Project list in Project tab. I try this on Visual Studio 2012, earlier with WiX 3.7 and now on 3.8.
If there is solution simply not using "Add Reference" function how can I build this other way? I'm a beginner so I don't really know how to use WiX without this feature, if I published my C# application in Publish Wizard I should add all produced files to Component Group with every file in <Component> tag?
It could be this simple...
In Visual Studio, Add Reference's Project tab only lists projects in the same solution. You just need to Add Project to the solution and go back to the Add Reference's dialog.
A solution is just a set of zero or more projects that can be built together. You can have a project in more than one solution. The only limitation is that if project B references project A (B is downstream of A), A should be in every solution that contains B. If the universe of projects is small, it is typical to have only one solution for them all. On the other hand, if one developer works only on upstream projects, that developer might find it easier to work with a solution that doesn't have downstream projects.
Setup projects tend to be downstream but note that they probably don't depend on library test projects.
[Stream is not the best technical term. The universe of connected projects is a directed acyclic graph.]
Sometimes I've seen a solution that includes up to three .csproj files for each project in the solution. Something like this:
Project.UI.2005.csproj
Project.UI.2008.csproj
Project.UI.2010.csproj
and the same with .sln files:
ProjectSolution.2005.sln
ProjectSolution.2008.sln
ProjectSolution.2010.sln
So if you copy the solution and want to open it using VS2005, you just need to open Project.UI.2005.csproj or ProjectSolution.2005.sln.
What is the best way of creating those 3 (or 2) files, in order to be able to open the same solution in multiple versions of Visual Studio?
Maybe the only way of doing this is modifying manually the .sln/.csproj. If so:
How can I modify those files correctly so I won't crash the solution?
I want to do this because sometimes I develop applications using VS2010 and when deploying the source code to my customers, they can't open it in VS2008, and then I have to do some tweaks.
Note:
I know there will be referencing and compiling problems if I use features only included in .NET Framework v4.0, or similar. Let's suppose all the projects in the solution are compiling under .NET Framework 2.0 (specified in the project properties).
I finally ended developing a small application do to this.
I'm still testing it, but it is working good so far.
All you need to do is, select the .sln file you want to convert, and specify the versions involved in the conversion, and it will do all the work for you.
If you have a VS 2010 project:
Solution (Solution.sln)
Project_1 (Project_1.csproj)
Project_2 (Project_2.csproj)
and you want downgrade the version (to 2008), it will keep those files, and also create:
Solution.2008.sln
Project_1.2008.csproj
Project_2.2008.csproj
And you will be able to open Solution.2008.sln with Visual Studio 2008 without problems.
As soon as I finish it, I'll share executables and sources here.
We are finally getting a source control system in place at work and I've been in charge of setting it up. I've read that it's usually good practice to not include binaries in source control so I haven't. However, we have two all-purpose utility projects (each in their own solution) that generate utility .dll's which are included in almost all of our other projects (all each in their own separate solutions). We add references to the utility dll from our projects.
I would like to have our solutions set up in such a way that if the reference dll isn't built, the solution will build the dll for itself, much in the same way a make file checks for its dependencies and builds them when they're out of date or missing.
I'm new to build processes with VS so try to keep the answers simple. Any links to general build process overview tutorials would be great too. Googleing for VS references returns a bunch of how-to add references links which is not exactly what I want.
Answer: (3 step process) Add a project reference, not a binary reference by right clicking on the solution, and adding an existing project. Then under the project tab, select project dependencies and modify the project so that one project depends on another. Finally, delete any old reference to the binary and re-add the reference using the project tab in the Add references dialog box.
Where I work we typically have project references rather than binary references (as we used to a while ago). When you include a project reference, the dll will build along with the rest of your app.
The only time we go back to binary references is when we are in between Visual Studio releases (e.g. 1 project is in 2010 and everything else is in 2008. The 2010 project will have to use a binary reference for a couple of months until everyone else catches up... Project incompatibility seems to be a Visual Studio limitation that shouldn't exist).
EDIT
To add a project reference right click the solution and click Add and finally "Existing Project." Make sure that the utility projects are also under source control, and make sure that the workspaces are set up correctly or other people will not be able to open up the projects correctly!
Can someone briefly explain to me the difference between Visual Studio's solution file (.sln) and project file (.vcproj).
It seems to me opening either one open the correct solution/project in Visual Studio. Is one the super-set of the other?
Note: I am currently using Visual Studio 2008 working on a project that was brought forward from Visual Studio 2005 (I believe).
A solution is a set of projects. If you need more than one project in your software, then go with solutions. I.E.: A Class Library Project + A Web Application Project.
A project file typically corresponds to a single module: EXE or DLL or LIB. A solution manages a collection of project files.
A solution is a collection of projects. Visual Studio is made so that it cannot function without a solution, so if you open a bare project, it will generate the solution automatically (or try to find one).
One solution can contain zero or more projects. Everything is in projects, so a solution with zero projects doesn't contain anything at all besides the solution properties.
Visual studio keeps track of where the projects are used, so if you open a project file, it will open (IIRC) the last solution where it was used.
When you create a project from scratch, a solution is also created, but it's not shown until you add another project to it. It looks like you have only the project open, but it's actually a solution containing the project that is open.
Specifically project files are intended to contain the data required to build the files in the project into an exe or dll. This file is utilized by the local compilers or with systems such as Team Foundation system and server side build agents.
Solutions are a client (IDE) construct designed to manage collections of projects, which in effect is a collection of different build definitions and associated files.
Solution files are typically made up of multiple project files.