Introduction
In a company with more than one development project sometime it happens that someone says: Hey, we need a common logging component shared across all projects.
Now the solution could be to develop such a logging component and share the assembly with all projects. However, if there is some code that should/must be unique to each project it is a bit more complicated. If you want to do that with SharePoint 2010 and build a logging component on top of the ULS log and want each project to be configurable in the Central Administration you need to know all future projects and categories or you need some unique code.
Note: The logging component is only a very easy example and might not be the best one.
NuGet
Microsoft created NuGet. A package manager for Visual Studio. Quote of the official site:
NuGet is a Visual Studio extension that makes it easy to install and update open source libraries and tools in Visual Studio.
You can add it easily to Visual Studio 2010 by Tools->Extension Manager. Search for “NuGet”. After it is installed, you can add packages to a project by right clicking on a project in the Solution Explorer and click “Add Library Package Reference…”
Now as a company you don’t want your super-fancy code to show up for everyone as open-source. Therefore, NuGet can have more than one package source. You can even use a file share. Open Tools->Library Package Manager->Package Manager Settings:
Bring it together
To get rid of “each project copy the source from the source of the other project from the source of the source of the source from another project” you can now use NuGet.
The idea is:
- Create the Logger.cs file
- Add TODOs to the code where the developer need to change something
- Make a NuGet package from it
- Let the project teams use the NuGet package (and distribute updates to the source automatically as well!)
Advantage: There is only one source! And if the owner of the NuGet package updates it, all project teams will be automatically notified about an update!
Create the NuGet package
In my example I talk about the comon logger component. A single Logger.cs file. However, NuGet can handle even more complex packages with PowerShell code, etc.
So download the NuGet command-line tool and create a new folder where all the stuff for the package will go to.
Open a command prompt and enter:
nuget spec
This will automatically create an empty package specification file called Package.nuspec. Open this file in notepad and modify the required values. Also rename the file to match the id property.
Now create a folder called “content”. Everything in this folder will be merged into the solution on installation of the package. So I put the file Logger.cs in this folder.
However, I don’t want that all users are required to use the same namespace, so you can change the file extension to “.cs.pp” to let NuGet “pre-process” the file.
Within the file you can then set some tokens to be replaced on installation. You can find a list of available properties here on MSDN.
The folder structure looks like this:
And the Logger.cs.pp in the content folder:
As you can see, I used the token $rootnamespace$. That one will be replaced by the root namespace of the target project.
Ok, lets make a package:
nuget pack
The output is a file called SPLogger.1.0.nupkg. You can publish it to the official NuGet package server or use it only internally by copying it to a file share.
Now open Visual Studio add the file share as a package source and search for it in the “Add Library Package Reference” window or open the NuGet console in Visual Studio (View->Other Windows->Package Manager Console) and type:
Install-Package SPLogger
That’s it. If you change the version number in your .nuspec file, create a new package and copy it also to your file share, the project team can decide to update to the latest version in the “Library Package Reference” dialog. You can even uninstall the package and everything will be removed from the project without leaving anything behind.