I have my own TFS (visual studio online) and work TFS. In my TFS located my own projects and, in particular, the project with useful utilities. I want to connect it to the work TFS solution, but keep getting an error, which essentially boils down to the fact that you can not connect a project in more than one TFS. Can I achieve the desired result?
No you cannot use multiple Team Foundation Server instances at one time. When you switch a project, you switch to the TFS server that it's stored in.
The recommended way to share utility code like you're talking about is by sharing only the binaries. This can be done using NuGet. You can setup your own NuGet repository and then let your utility project publish to your NuGet server. Other projects can include your NuGet packages just as you use external packages.
You can find a great overview of what NuGet can do here.
Related
We're just in the process of transitioning from VS2013&15/TFS2013 to VS2017/TFS2017 (on-site TFS, not VSTS) and the first test solution is a dotNet Core 1.1 based one (a multi-project web service).
The solution builds fine on the original developer's box and I've got it out of TFS and it builds fine on mine too. In keeping with our previous methodology the contents of the packages folder are checked in with the projects as this makes the packages locally available on the build box (no internet).
Building the solution on the build server is a different story, however, as I get multiple errors of the form...
..\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
This whole project.assets.json not found issue seems to be causing headaches all over. In my case the issue is that I'm trying to resolve it on our TFS 2017 Build Server, which does not and never will have internet access ('cos it's a server!).
All the solutions I've seen thus far seem to suggest running the Nuget Restore command but that can't work since the server cannot get to nuget.
This is nothing fancy yet, just a simple TFS 2017 Build definition with a Get sources and a Build solution step. I can't understand how something so simple has become so difficult.
Changing the Nuget Package Restore options makes no difference.
Since the project.assets.json files are generated on the fly in the obj folder, I can't even check them in to reuse. Can anyone please suggest a workaround, at the moment the test project is dead in the water.
Edit: trying the same process with a 4.6.1 web project created with VS2015 had similar results of unresolved references (e.g. System.Web) but didn't raise the same error, probably due to being an older, non-Core project.
According to I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
The issue seems not related to TFS build side since it also not work with local build through VS in the build agent machine.
Since this is a dotnet project. So, you could try to use “dotnet restore” and not “nuget restore”. Try using the dotnet core template (which uses dotnet restore).
If you are using authenticated nuget feeds, then you can use nuget restore but you also need to use nuget installer task. See https://github.com/Microsoft/vsts-tasks/issues/3762 for a discussion on that.
The Nuget version should be higher than 4.0.
Without dotnet restore and Nuget restore and only use get source/Visual Studio Build will not be able to build the dotnet core project. If your server do not have internet access, as a workaround you should use Local feeds.
I'm looking for suggestions on how best to share VS projects across Team projects in TFS (currently 2013 on-prem, but will soon upgrade to 2017 or VSTS). Our primary use case is for Request/Response models for Web API projects, but we've recently started trying to share more utility code and custom parsers across our development teams as well.
In our current setup we're using self-hosted NuGet packages, but this is a manual process and error prone. It also holds us back from moving to VSTS because Package Management isn't included in the Basic tier.
We could probably reduce the dependency on shared models by using Swagger to document our APIs, but that seems like a cop out.
Any suggestions?
It's not suggested to reference projects outside your solution root. You should make a project reference or create a NuGet package.
Since your projects are across Team projects, Nuget package is still the recommended option. In VSTS and TFS 2017, you can host your NuGet packages using Package Management feeds. Check: https://www.visualstudio.com/en-us/docs/package/overview.
I have downloaded 30+ TFS projects (containing close to 100 cs projects) from my Team Services (was TFS Online). I have modified many of those cs projects and would now like to check the changes into a different Team Services repository. Is there an easy way to do this in bulk?
I know I can add the "files" to new Team Services repository through source control explorer, however, that appears to screw up the nuget package restore when they are downloaded. The only way I have found that the nuget package restore works is if I open each project, disconnect it from source control, and change the source control on the open project and check it in.
You can use TFS Integration Tool to achieve Visual Studio Online migration (VSO-To-VSO)
Detail steps please see my answer in this question: Move Team Project to another Project Collection TFS 2013 (Just need to change the TFS to VSO)
Got 5 different TFS, is there a way to search in all TFS's? Visual studio plugin?
Right now I've downloaded all the source code to my local machine and turned on indexing on serveral filetypes (properties and inside files)..
If anyone has the same problem, how do you solve this kind of problem?
Never heard this kind of tools or plugin.
In a sense, there are different Application Lifecycle Management system. They have different servers, SQL servers, users, permission settings and so on. Searching between them, how could this be possible to achieve. Unless, you choose to migrate different projects to one instance of TFS.
OpsHub Integration Manager supports bi-directional synchronization between a wide variety of systems including Team Foundation Server and Visual Studio Online. It can be used for bi-directional sync between TFS and VSO. For more information please reach out to OpsHub at http://www.opshub.com/main/index.php/company/contactus
What is the best way to share dll libraries between projects, through VS2010? For example we have made a generic helper library that is useful in everything. However, we need more than one library to be included (which is a separate project in TFS) so branching is not suitable.
We are using Team Foundation Server 2010 for source control. Is there maybe a simple way to integrate these libraries into a new project, so the new project can come "fully buffed" very fast?
What we do now is go through each project, build them, store the dll files, add a new project then throw them in the Bin folder, which is tedious work when you have many libraries.
Have you thought about hosting your own NuGet feed? I use a pre-build script for NuGet for each of my projects which downloads packages for me before the project is built, and, I assume, keeps them up to date.
I don't think that there is some TFS-based solution for sharing binaries between projects. However you can use NuGet to do it for you. Create nuget package for each project (you can create TFS build definition to do it automatically) and publish it to network share. Than add this share as NuGet feed.