*.csproj<\/code> file to allow NuGet to fallback to using PCLs based on profiles:<\/p>\n<PropertyGroup> \n <PackageTargetFallback>portable-net451+win8<\/PackageTargetFallback>\n<\/PropertyGroup> <\/code><\/pre>\n<\/section>\n<\/article>\n<\/div>\nSee Using Visual Studio Team Services Libraries from .NET Core<\/a> for more details.<\/p>\n
As you can see here<\/a>, we\u2019ve released four packages. The descriptions aren\u2019t as helpful as I\u2019d like, and we are getting that fixed.<\/p>\n First, I need to give you some context. We started building Team Foundation Server more than 12 years ago. Back then, SOAP<\/a> was the primary protocol for building web services. So, everything in TFS used SOAP, including version control, work item tracking, build, test case management, etc. Then a few years ago REST<\/a> started taking over. Very few web services are being built using SOAP today (I\u2019d say none, but I\u2019m sure someone would point on one I missed!). Also, REST web services are easier to consume in everything from Javascript to iOS apps. So it made sense for us to start moving our web services to REST.<\/p>\n When we built SOAP web services, we declared them to be an internal implementation detail and that consumers would need to use our .NET client libraries or our Java SDK<\/a>. If you\u2019ve ever looked at the SOAP web services, you quickly see that they can be cryptic, and they were clearly designed by different teams given the dramatic differences between some of the different feature areas.<\/p>\n When we made the decision to start building REST APIs, we decided we wanted to follow a different process to produce REST APIs that are consistent and easy to consume. We decided we\u2019d have a set of guidelines and a review process. We didn\u2019t want to create guidelines from scratch, so we adopted the guidelines the Azure team uses and gave them some feedback, which they incorporated. There\u2019s now a broader effort across the company to standardize REST guidelines.<\/p>\n With an existing product like TFS, changing protocols is not a simple thing. The product contains lots of SOAP endpoints. All of the existing clients have to continue to work for years, as breaking changes become blockers for customers moving to newer versions of TFS or potential work stoppage issues with VSO since we update VSO constantly. REST is also very different than SOAP, so you can\u2019t just translate SOAP web services into REST (or you\u2019ll end up with something terrible). As a result, it\u2019s a gradual transition to move from SOAP to REST.<\/p>\n With that context, here\u2019s a description of each package of .NET client libraries. Applications that use a wide range of features are likely to need more than one of these packages.<\/p>\n Here\u2019s a diagram showing the dependencies among the packages. NuGet will automatically handle the dependencies for you. For example, if you choose to use TeamFoundationServer.ExtendedClient, NuGet will pull in the other three automatically.<\/p>\n <\/p>\n <\/p>\n NOTE<\/strong>: If you only need the REST APIs and choose to use TeamFoundationServer.Client, you\u2019ll want to use Services.InteractiveClient also if you need to allow users to log in interactively and thus add a reference to both NuGet packages (NuGet will then automatically get Services.Client for you).<\/p>\n We have a few samples<\/a> to get you going, and a REST API reference<\/a> in addition to the traditional TFS\/VSO client object model documentation<\/a>.<\/p>\n One thing we\u2019ve never had is support for the Portable Class Library<\/a> (PCL). I\u2019m happy to say that we are working on that and will start adding PCL-compatible libraries as they become available.<\/p>\n We are also working on adding a package for Team Explorer extensibility.<\/p>\n [Update 8\/18\/15]<\/strong> For using Git via an API, you\u2019ll need the LibGit2Sharp package<\/a>.<\/p>\n [Update 2\/27\/17]<\/strong><\/p>\n Using VSTS Libraries from .NET Core<\/strong><\/p>\n\n
Microsoft.TeamFoundationServer.Client<\/a> Here you\u2019ll find convenient .NET wrappers for our REST APIs for build, team rooms, version control, test case management, and work item tracking. You can of course call the REST APIs directly without using this library. You will encounter cases where an API is not available in this package and have to also use the ExtendedClient package.<\/div>\n<\/li>\nMicrosoft.VisualStudio.Services.Client<\/a> If you need to access account, profile, identity, security, or other core platform services, you\u2019ll need this package.<\/div>\n<\/li>\nMicrosoft.VisualStudio.Services.InteractiveClient<\/a> This package provides the library necessary to show a user an interactive prompt for credentials to sign in. If you are using basic authentication<\/a>, personal access tokens<\/a>, or OAuth<\/a>, you won\u2019t need this.<\/div>\n<\/li>\n<\/ul>\n![\"NuGetPackageDependency\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/39\/2019\/03\/3146.NuGetPackageDependency_thumb_4E789FC8.png\" "\\"NuGetPackageDependency\\"")
<\/a><\/p>\n\n