0

I've been involved in a project using Visual Studio 2012 that has multiple solutions and multiple projects. In most cases, one solution will have to refer to the library build in a different project. Since most projects have their own set of nuget repositories, we run into the issues of missing references even when we try to restore the packages from within VS.

Has anyone come across some best practices on that?

The system we are using are VS 2012 and our code is store in a GIT server.

aggietech
  • 1,082
  • 2
  • 11
  • 22
  • Just a thought, how about you setup a nugetserver on azure or so, that you need to authenticate to access? – Knerd May 01 '15 at 14:04
  • This is a desktop project, we're not hitting azure – aggietech May 01 '15 at 14:05
  • 1
    Asking for best practices is overly broad - there could be a multitude of answers. The Q&A format works best when you have a _specific_ problem to address. –  May 01 '15 at 14:07
  • Just to be clear you are pulling in assembly A via nuget that you built yourself, and it isn't pulling in assembly B that is a dependency of A? – Sign May 01 '15 at 14:08
  • @aggietech so? You can just setup a nuget server. Check this link https://docs.nuget.org/create/hosting-your-own-nuget-feeds – Knerd May 01 '15 at 14:09
  • @Sign, i'm pulling nuget packages that are not made by me. My team have different developers and we are using different libraries. We do refer to each other's project library though. – aggietech May 01 '15 at 14:15
  • @GlenH7 - this is a specific problem - though i mentioned best practices because it might not have an only way to solve it. – aggietech May 01 '15 at 14:53

1 Answers1

3

The issue you are encountering is weird. You may check twice the way NuGet dependencies are stored in source control.

What may help is:

  • To use one solution instead of several ones. Unless there are multiple teams in different departments of your company working on completely independent projects with a dependency on a common project, one solution may make things much easier, especially when it comes to dependencies.

    If you are afraid that Visual Studio will perform badly with a solution containing a few hundreds of projects, you may be interested by this answer.

  • To deploy each project in a form of a NuGet package and to let NuGet handle the dependencies. If you work on closed source software, you can set up your private NuGet server for that.

Agreeing on common versions of third-party NuGet libraries may make things easier as well. For instance, if a team is upgrading to a new version of Entity Framework, another team may do it at the same time to avoid potential issues with two versions being used side by side.

Community
  • 1
Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • The suggestion of deploying each individual project as an internal nuget package is an interesting solution, didn't see that coming. – aggietech May 01 '15 at 14:25