0

I am reviewing our TFS access code after we upgraded to VS 2017 and VSTS Online.

I found out from another question on this site that the recommended way to access the TFS libraries is via a NuGetPackage.

Great, that's surely better than referencing from the Team Explorer installation folder.

However, the NuGet package in question added over 45 references to my project.

I believe I am only using 4-6 of them.

I found this question which discussed the fact that the package files do not have to go into source control.

That's good to know.

However, the references have been added as "Copy Local" and so they are all currently being copied to my output directory. This has caused my application to more than treble in size. It just doesn't seem like good practice.

Do people usually just ignore this and trade off against the fact they are getting great dependency management?

Or manually remove the non-required references...? Do future updates put the references back?

Or have I incorrectly consumed the package in some way...?

There are a lot of NuGet questions on this site. I did search but please accept my apologies if this is a duplicate.

Community
  • 1
  • 1
J M
  • 1,877
  • 2
  • 20
  • 32

1 Answers1

1

Do people usually just ignore this and trade off against the fact they are getting great dependency management?

Add all dependencies to the project is the default behavior of NuGet. At this moment, there is not such option so that we could choose some of those dependencies.

Although all dependencies are added to the project as "Copy Local", when we publish our application, we could exclude those unneeded dependencies by changing the Publish Status from Include (Auto) to Exclude:

enter image description here

In this case, those non-required references are not included into the application.

Or manually remove the non-required references...? Do future updates put the references back?

Yes, you can manually remove those non-required references, but when you update the package next time, those removed references would be re-add again.

Besides, as you said, you are only using 4-6 of them. You can try to custom a nuget package only including those 4-6 references.

Create nuget package from dlls

Hope this helps.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • Thank you very much for your reply. I'm attempting to persuade the rest of my team that creating a local NuGet feed would solve a lot of our dependency problems. We have huge solutions that should be split. I was going to showcase the idea by making our source control library available via a local NuGet feed. However, my team aren't going to touch that library if it adds 45+ references to every project we have that needs source control access. I could create a custom package. But that defeats the whole point of NuGet as I'll have to manage the dependencies of the custom package manually. – J M Jan 03 '18 at 08:57
  • I did a lot of reading around last night and think that the fault really lies with the package creators. My understanding is that packages are supposed to be smaller than this one is. The creators appear to have dumped everything in one package where smaller packages would have been more optimal (I assume due to time constraints). Ideally, there would be multiple smaller packages e.g. one for version control, one for builds, one for work items, one for tests. I will probably create these myself manually for now from dlls. – J M Jan 03 '18 at 09:11
  • @JM, Indeed. But the author of the package, could not to know everyone's requirement, you only use 4-6 of them, others may use 6-8 of them, so this package including all references. Users can add the required dll file according to individual needs. So custom package should be a option. Besides, on the nuget.org, you can also find some custom package about VSTSApi, for example, TfsTestAPI. – Leo Liu Jan 03 '18 at 09:30
  • I thought Resharper was my saviour but it apparently treats NuGet packages as atomic units. I can see I am referencing 2 dlls from the package but the tool only allows the removal of the whole package (makes sense, partial packages can't be ideal). There are other extensions but they have bad reviews so I think I am stuck and will have to go back to referencing dlls from the Team Explorer folder (or from a package attached to another dummy project or something like that). – J M Jan 03 '18 at 09:41
  • OK, I will have a look at existing custom packages as well :) – J M Jan 03 '18 at 09:42
  • I do understand that package authors don't know everyone's requirements but that wouldn't have stopped them from creating more atomic deployment units... Instead they have bundled source control, builds, tests, lab, work items, etc all in the same package. You wouldn't do that for dlls and so in my opinion it shouldn't be done for packages either especially as it apparently so hard to clean up afterwards. – J M Jan 03 '18 at 09:44