EDIT:
I have an existig solution in visual studio (which is on TFS source control). In this solution, I have several projects too (under source control).
Now, I would like to add a project (for test purpose) to my solution, but I would like this project only on my local computer and not commit it on the source control, because all other team members doesn't need it!
I can obviously, remove the project of source control, but while it is in the solution, all others team members will be able to see the project even if they'll not be able to load it !
Anyway to avoid .sln to add the local project ? Is it possible to do this ?
Thanks.
Yes ofcourse. Easiest way would be to create your own local solution file with the test project and the other projects that you need.
You can't add the test project to the solution without adding it to the source control. The simple reason is that the project has to be declared in the SLN file which is on source control.
So you'll have to create another solution and add existing projects and the new one.
Related
I have a TFS project at $/src/main/MyProject/MyProject.csproj
It has a reference to a DLL at $/dependencies/dependency.dll.
The way I want things to work is that when my colleagues get MyProject, or open it in Visual Studio, I want TFS to go get the latest dependency.dll as well.
(In a similar way, I've actually bound MyProject to my solution in $/src/main/MySolution/MySolution.sln. So if a user gets MySolution and opens MySolution.sln then Visual Studio will go get MyProject as well. I just want to extend this to the next level, that of binding a file to a project.)
This is the perfect scenario to make use of NUGET and even though a little additional work, I would rather go this route :)
Now if you dont want to create the Nupkg etc, one easy way out is to make use of the VisualStudio Add link option.
"Add Link" is project specific and it will add a new entry to your project file specifying the location of your CS/Js/Dll etc file. As long as the file is available in the particular location TFS/VS will pull the latest copy of that file while opening the solution in VisualStudio. Make sure that the Add link creates a relative path to the file and not an absolute path.
ADD vs ADD link
Have you seen the recent announcement on package management for Team Services?
I wanted to add a solution to a project, but accidentally added a solution to the wrong Team Project.
Before adding the project, I made a copy locally. I then deleted the project in Source Explorer and ran a checkin. This deleted the code from the local drive.
I then restore the code from the local copy. Opened the solution and removed the bindings from the Change Source Control form.
The issue I have is every time I try to add the solution back to source control, it is automatically added to the first project. Is there a way to pick the project you add a solution to?
You didn’t completely remove TFS Bindings.
There is a tool to remove Source Control Bindings from Visual Studio Solutions and Projects from msdn: http://blogs.msdn.com/b/saveenr/archive/2012/08/11/a-tool-to-remove-source-control-bindings-from-visual-studio-solutions-and-projects.aspx
More ways and more information for you reference: How can I completely remove TFS Bindings
I have a solution under which there are 15 projects. This solution is on TFS. I want to create another solution in the same directory in TFS, however I want to use only 12 out of the 15 projects. Which means I don't want to duplicate the projects, but just selectively link a few of them to this second solution.
What I tried was to create a new solution on my local machine and add those projects from my checked out version and just move the .sln file over to TFS. But this didn't work when building on the server, for obvious reasons.
You will have better luck of you make the solution in the same folder as the other solution in your workspace.
Then add the projects and get it to build locally. You should then be able to add the solution to source inplace and build from it.
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.
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.