Sharing Custom Libraries Using NuGet
Javier shares a technique he uses with NuGet by defining custom packages on a local share or common folder. Instead of downloading source code from the internet, you become responsible for maintaining the assemblies to manage using NuGet. This method may be used for your own common assemblies.
Javier writes:
I am a silent reader of your colums since a while now and with this latest post I thought it could be handy to write you about the solution we use in our job.
We also had to struggle with the references being overriten as the developers were opening the project and checking in stuff. Some of them would put the project in their own preferred folder (…but freedom comes with a cost !) and then bang, it would break.
One solution is to simply put all the dependencies (e.g. DLLs) on a folder separated from the solution and point the solution to that, usually 1 level up will do the job. Arguably, the solution is not that elegant and I agree.
For me the most interesting part of NUget is the fact that you can instruct it to check your own network share.
You would put all the dependencies in that single place (provided that every developer can see that location !). Then, as erybody gets the project and checkin and checkout, you will never experience the problem again.
To work with this NUget "advanced feature" go in VS 2010 to Tools — Library package manager — Package manager settings. You will see a popup named Options. Expand the Package Manager node and click on Package Sources.
Then you will see a list of the available sources (default is the microsot official source).
And as you can see you can add your own sources 🙂
All you need to do is to create a .nupkg file on the share with a special format (check the NUGet readme and docs for this).
The last step is on VS 2010. Whenever you want to include your references, click on Manage NUget packages,
and under the Online header (left portion of the popup window) you will see a list of: All Your custom source provider
Nuget official package sources.
Select your custom source provider (the one that maps to your share !) and you are up & running and happy as a dog with a bone.
Happy coding and good luck !
There has been a lot of other feedback regarding the difficulty I am having with the integration of NuGet. Here is some info some have requested. I am using Visual Studio 2012, Team Foundation Server 2012, and the latest version of NuGet. It seems to be this combination of tools and the way we have configured our source repositories that is causing some of the issues such as inconsistent GET; especially after deleting a repository. For a continuous build it is a common practice to clean the build directory, get completely new bits, and build the code.
I’m not on a rant against any of the products. My question is, they are all Microsoft Product Code based; they are supposed to be made to work together; we are using them in a standardized way. This isn’t rocket science. I haven’t had this kind of difficulty in 30 years. So, I’m simply asking, is the combination of these three products working for others, and with how many developers? Share your experience by dropping a note to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Tips for using views in SQL Server 2012
In this article, you can find some tips to performance tune and optimize SQL Server 2012 views.
Featured White Paper(s)
Extending the Value of SCOM with Spotlight on SQL Server
read more)