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!
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.]
So I am working on a solution with a lot of projects with multiple developers using SVN. There are some projects that are specific for me that I want loaded but for others they might not be relevant.
So my question is, where does Visual Studio store information about a project begin loaded and what is the proper way to commit project/solution settings with out ruining it for others?
An example could be that I just added a new project to the solution and I want to commit these changes, but I don't want to commit whether or not a project is loaded/reloaded (Since other developers have to reload them again).
EDIT: I found the answer here When I unload projects in visual studio, where does VS save this setting?
When you add projects to a solution, they will get loaded when the solution opens.
If using source control, if such a solution is updated and contains new projects, they will get loaded.
One way of dealing with this is to create multiple solutions - solutions that only have relevant projects. These solutions can be part of source control, but don't have to, though if you don't add them to source control you risk having projects in source control that only you have a solution reference to.
How can I make a solution in visual studio so that the .dll dependencies that reside in some other directory totally different from where the solution itself is affected by "get latest".
What I've tried is creating a Dependencies solution folder within the solution itself and added the dlls to it, that way they belong to the solution even though they don't belong to the directory structure of the solution.
So for example the .sln file is in:
D:\tfs\repository\main\SolutionA\solution.sln
and the dlls are in:
d:\tfs\repository\main\SolutionX\Dependencies\Binaries
What I really want to achieve is to have a foolproof way to build the solution, including the following scenario:
1- Have a brand new installation of windows, visual studio, etc.
2- open visual studio
3- find solution.sln on TFS, double click on it so that visual studio gets every project and files in the solution, and opens the solution
4- successfully build
What happens when I try the Dependencies solution folder approach and repeat the scenario above, it will get all the projects within the solution, opens it, but the dependencies solution contents won't be pulled from TFS (although Visual Studio shows them on Solution explorer), which I think is flawed.
Some suggestions that don't involve creating pre/post build scripts are appreciated.
When you attempt to open a solution for the first time using the TFS Source Control Explorer, you may find that not all of your dependencies will be retrieved - the squiggly line may be highlighting some of your missing References.
One work around is to...
SOLUTION SETUP
Checkout all of your source code from TFS (i.e. Main and all of the sub-directories)
Open your solution in Visual Studio (i.e. MyApplication.sln)
In the solution explorer, create a New Solution Folder called ThirdPartyDll, and then add the appropriate assembly references (i.e. Assembly1.dll, Assembly2.dll,...)
Check-in your solution to TFS
SAMPLE FILE STRUCTURE
Main
MyApplication.sln
Source
MyProjectA
MyProjectA.csproj
MyProjectB
MyProjectB.csproj
Dependencies
Assembly1.dll
Assembly2.dll
You've run into a limitation of the "Open from Source Control" functionality. If you added the solution to source control from Visual Studio you should have seen the following message:
"The project that you are attempting to add to source control may cause other source control users to have difficulty opening this solution or getting newer versions of it. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution."
Open from Source Control will create a workspace mapping for the solutions root directory (D:\tfs\repository\main\SolutionA) but not a separate one for the SolutionX folder which is a peer to SolutionA. On the "new" machine you will need to manually create a workspace mapping to d:\tfs\repository\main in order to get both the SolutionA and SolutionX folder.
Create a solution folder and add the dependencies to it, that way when VS gets latest for the solution it will download these files. A bit brittle as people will need to maintain that folder but it works.
Alternatively create a nuget package and use restore packages on build. It will require a couple of extra steps when you create a new developer box (your nuget package repo will need to be added) but it will work for all projects going forward and is less brittle than the solution folder method.
In Visual Studio there is a way to have a file in another project that is a shortcut to the first so that it builds in both. How do I do that?
Right-click the project, select Add > Existing Item, and in the dialog drop down the Add button and select Add As Link.
This is not a direct answer but an alternative that may be worth considering in some cases.
You can create a specific kind of project which can "include" a set of files in another project when it is added by reference. This is called a Shared Project which is one of the 'new project' options:
(Since at least Visual Studio 2015 - maybe earlier).
One advantage of this type of project over individual shortcuts is that it includes a set of things as a bundle. So if you have a large # of items, this may be easier and less error prone.
Also it uses the familiar "reference" metahphor in the context of the solution and in that way functions quite similarly to other project references; the difference is that in a shared project the items in the project are added into each referring project, but in a normal project the assemblies (DLLs) end up owning the reference at runtime. Shortcuts may be less familiar to other developers than the reference pattern.
More information: What is the difference between a Shared Project and a Class Library in Visual Studio 2015?
Are you talking about a solution with multiple projects? In that case answer would be using Project Dependencies (within Project menu).