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.
Related
I'd like to add angular2 to a Visual Studio 2013 project, is it possible to do with nuget?
I found a codeproject article describing I need Node Package Manager to do this, dated 30 Nov 2015.
While it is possible that a NuGet project exists that simply wraps up Angular2 into a package and while it is possible that you could add this to your solution, I would HIGHLY recommend that you avoid this course of action.
Microsoft has made a very deliberate decision to redirect efforts into supporting and expanding web standards. Currently, the standard for Angular2 is to use npm to manage your scripts. There is built-in gulp task runner support for this in VS 2015 and you can certainly manage it via gulp or grunt plugins in VS 2013.
Finally, consider how quickly the web world is moving right now. Maintaining a NuGet package for every Angular2 version would be exhausting, if not disastrous. Embrace the direction that the web is moving and switch to managing your JavaScript libraries with NPM, not NuGet.
We are currently migrating our source control to Visual Studio Online. A feature we had in our old system (SourceGear Vault) was to share projects between solutions. Although this created a folder for our Framework project in each solution it kept it up to date when changes were checked in.
This is useful to us as it allows us to work on the Framework code in all the Solutions that are using it. I know its better practice to just compile the dlls and reference them - at this point in development we want to continue having full code access and debugging in all the solutions using this core framework.
Any help very much appreciated.
You have a few equally valid options for handling shared projects:
Reference the same project from each solution that needs it.
This gives you full control over the source code of the shared project while you work on the consuming solution, and may allow for easier debugging.
The downside here is that maintenance and releases may become trickier if Solution A is being released on Thursday, but Solution B is being released in 3 months and is in the middle of a huge refactoring cycle that has significantly modified Shared Component X, and Shared Component X isn't stable enough to be released.
Reference shared components from an internal NuGet repo.
You set up your release pipeline to push the shared components into NuGet as part of your release process (ideally, using a purpose-built release management tool... Microsoft Release Management is what I have in mind here) -- you check the code in, project gets built. Release process packages it up and pushes it into NuGet as a "prerelease" version. You reference the latest version in anything that needs the latest version.
If you need to reference a known-good, stable version, you just make sure your project is configured to pull a specific version from NuGet.
When you're done, you've tested the shared thing, and you know everything is good, you approve the prerelease version, and the same binaries are repackaged into a "stable" version.
The downside here is that there are some additional software requirements, configuration, and training for your team. This would be my recommended approach.
Check binaries into source control.
I don't recommend this one -- you end up bloating your source control repo (and if you're using Git, it's an explicitly stated anti-pattern -- never put binaries into Git, it causes long-term severe performance problems), and it's never exactly clear which projects are using which versions of which assemblies. It's a maintenance nightmare.
(1) is the best approach if you're releasing everything in lockstep and don't have to worry about maintaining separate versions.
(2) is the best approach if #1 is false.
(3) is the best approach if #1 is false and you're a time traveler who is posting from 2006.
Have you considered implementing Symbol Server and Source Server indexing with the check-in binaries or NuGet repo approach? This allows you to easily get back to the source while debugging and it's coming from a single known location. Visual Studio Online and Team Foundation Server have built-in support for helping you out with getting this setup during your build process. Here's more information in a write-up here: Source Server and Symbol Server Support in Team Foundation Server and Visual Studio Online
Thanks for the responses. We actually found a solution that works well for us. We branch our framework project into the implementation projects when we want access to the code base. If not we just use the DLLs
If it is then altered and checked into the implementation project it can be merged back with the other Framework branches easily when ready.
This probably wouldn't work well if the Framework code was being developed heavily, as it is now its only undergoing small additions and tweaks so wont be plagued with merge issues.
I have to agree with the majority. I just ran into the same issue. I implemented the Nuget Gallery Site on the internal network. It was a pain to implement, but once implemented, it's easy to use. I created a class library project that implements ADO.Net and the EntityFramework. I bundled it into a NuGet package and uploaded it to the internal NuGet gallery. From there I was able to add a package source to the internal NuGet gallery and grab the package that I uploaded. Very simple and convenient.
I set up the NuGet Gallery with Visual Studios 2017. FYI: Make sure that building the project isn't part of the Publish. It will not render with a ViewHelper.cshtml error.
I created the projects with Visual Studios 2015. I ran the command prompt as administrator. I also had to copy the NuGet.exe file into the directory where the project file existed.
Check out the below links for more information.
NuGet Gallery
Hosting NuGet Gallery
Create and Publish Package
Creating a Package
Create .Net Standard Package
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.
Currently most of the development in the company I work for is controlled via VSS. I've installed Team Foundation Server for the development at our site.
There is a future project that will involve new developement, but referencing older code bases hosted in VSS. My preference would be to use TFS for the new development, but I'm unsure if a VS2010 solution can have projects using different source control providers.
You'll need to change the source control provider manually (unbind - change SCC provider - bind) each time.
No Visual Studio does not allow for mixing source control providers within a solution at the same time.
I have decided to start using Team City as my continuous integration software and I am having some problems how I should handle my project references as the assemblies my projects depends upon are located at different locations in my developer solutions and the solutions in team city (I am using the vs2008 solution files option for the builds in team city). The problem is that the projects builds in development and fails in team city.
How should I handle the different project references in the project files?
ex. My MVC app references a common util assembly I use in other projects as well. In my developer solution I add this project to the solution but I do not want this in team city build so I have a different solution file there.
It sounds like you should split your code up into multiple solutions. When projects in one solution need to access binaries from projects in another solution, then they should not add those foreign projects into the solution. Instead of using project refrences, use file references.
This means that you need to deploy the results of completed builds to some common location, posisbly a share.
See patterns & practices: Visual Studio 2005 Team System Guidance. It's for TFS and 2005, butthe general concepts apply to many other source control systems.