Our company is planning to start a large new WinForm project, it will be written in c#-4.0 using Visual Studio 2010.
This project will have many modules (Production, Accounting, Service and etc...) and each module with have lots of possible forms. So we are testing the idea of create multiple projects inside a single solution and have each module be it's own project rather then having a single very large project.
I created a test solution with two projects A and B, next I added each project as a reference to the other project, when adding one project as a reference to the other, I right clicked on Reference>Add Reference>Browsed to the other projects bin/Debug folder and added the other project's .exe as the reference. Next, using the other project as a namespace I was able to do things like form inheritance and opening forms or calling methods between my two test projects.
But I accidently clicked Clean Solution which cleaned the bin/Debug folder for my two projects, and all of my references between the two projects were broken.
What is a proper and reliable way to add permanently references between projects inside a single solution? I was thinking I could physically copy each project's .exe into the other projects bin, then add it as a reference. But that means I'll have to manually re-copy it every time the other project get's updated.
Related
I want to add a bunch of existing projects to the solution in Visual Studio 2017. Those projects aren't originally intended to work in VS, so I am using File --> New --> 'Project From Existing Code' to make them usable there.
VS creates a new solution for every project during the creation of "Project From Existing Code". Can I change it so it will add such project to the existing solution at the time of creation?
The process I am using to add created from existing code projects to the solution:
I initially work with VS solution (which can contain projects).
I create a new project from my existing code (File --> New -->
Project From Existing Code).
VS builds up its specific project files as well as solution file in the new project folder, closes currently opened solution and opens newly created one.
I repeat for every project I want to include in one solution.
I reopen the solution I was originally working on in VS and I add the projects to the existing solution (native VS projects I just created).
I go to the each project's folder in File Explorer and delete solution in each of them to reduce the clutter.
The simplest would be:
Create a new solution.
Remove the project that was part of the template.
Import the existing projects one at a time (right click on the solution --> Add --> Existing Project)
I have a VS solution with multiple projects, and I'm using Nuget to obtain external references. However, it's important that the package files for one project Not be in the same folder as the packages for the rest of the solution. As such I would like to put them into their own, seperate folder.
It would also be acceptable if all of the packages went into one folder, and then only the ones used by other projects were copied into the folder that they need them to be in. But I don't know of any way to achieve this behavior either.
If it helps, the specific scenario is a Unity project referencing a standard .NET class library project. The solution contains the .csproj file for the library DLL and also the ones generate by Unity. Because unity regenerates those project files every time the Unity project is changed, any packages to be used by those projects need to be inside the Unity project's Assets/ folder, or else the references won't be added to the generated .csproj files.
However, ALL dlls contained anywhere in the Assets/ folder are added to the generated projects, unless manually marked as not to include on a per-file basis. Which is why I don't want the packages referenced by the Library project to end up in that folder, as manually going through and marking every single .dll in every single package not to be used by the Unity project will become very tedious very fast. Especially since some packages download numerous dlls for many different versions of .net.
We need to create a new project in Visual Source safe. This project is actually a newer version of an existing project. Following is what we want.
All files of existing project are copied to new project.
Files in both projects are not shared. (Changing a file in one project should not affect the same file in other project)
All Visual Studio solutions and projects are bound to new project in source safe.
Whats is the best and easiest way of doing this?
You should use the share and branch option...
MSDN help (works with folders as well as files)
This will break the link between the two copies meaning that you can change files in one project without affecting the other one.
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.