In most scenarios, your programming peers only need the features that your library offers, not the burden that comes with constantly adding your project(s) to their solution and keeping the copies of same up to date.
Of the numerous advantages, packages give versioning and dependency management, while encouraging a distribution model made of small, self-contained files.
- The Case for the Private Nuget feed option
There are three local feeds options, namely, the local feed, the Nuget.Server feed and the Nuget.Gallery feed.
For the purpose of this article, the Nuget.Server option is advantageous because of its ease of implementation and the provision of Nuget.Server packages being made available through a server via HTTP(S) – which can then be easily consumed by other projects having access to the package source (via Nuget sources).
The processes involved are enumerated below;
- Create a project application on Visual Studio
- Create a new project in Visual Studio.
- Add some class files (web forms, etc) as sample files to be consumed later.
- Create a Nuget Server in Visual Studio
This is accomplished by:
- Installing the “Server” package by navigating to “Tools” -> “Nuget Packet Manager” -> “Manage NuGet Packages for Solution”
2. Search for “Nuget.Server” in the “Nuget – Solution” window pane
- Select the project you initially created (in this case, “ProjectServer”).
- Click on “Install”.
- Build the project to generate the (in this case) “ProjectServer.dll” file.
1.2.2 Edit the “Web.config” file
After installing the “Nuget.Server” package, several configurations are added to the “web.config” file.
- Most importantly, is the “<add key=”apiKey” value =” “ />” element that is in Line 55 below – used to set the agreed-upon API Key, that facilitates the pushing of packages to the package feed. This key is shared among project members and is the means of authenticating “push” actions to the server source.
This is not entirely necessary if the project is hosted in a secure environment. Which in effect precludes the danger of sharing a single API Key among multiple users.
184.108.40.206 Setup IIS
This will be where the Nuget.Server feed will be hosted for the project.
To do so:
- Launch the “Internet Information Services (IIS) Manager.
- Right-click on “Sites” and Click on “Add Website”.
- Give your site a name in the “Site name” textbox.
- Select your target path in the “Physical path” option.
This is a folder create on any part of the hard disk that will serve as the IIS host path.
- Click on “Ok”.
- Publish to IIS/Azure
The project being used for this simulation was published to IIS in the author’s local machine, but the process remains the same when publishing to a site on Azure.
This can be done by:
- Clicking on “Build”
- Clicking on “Publish ProjectServer”. This gives you the screenshot below;
- Click on “IIS, FTP, etc” and click on “Publish”.
- Click the “Publish method” dropdown below and select “File System” as the publish method.
- Input the “Target Location” – that is, the folder you created as the IIS Host path – the path to the site configured through IIS (shown below)
3. Click on “Save”.
After publishing, the list of files shown in the “HostedSiteExample” target path shows the publishing to IIS was successful.
- Run the Nuget.Server through IIS
To run the Nuget.Server,
- Select the Site on the IIS Manager homepage (“TestWebServerSite” in this case) and click on “Browse *:80 (http).
The page below displays as proof that the NuGet.Server is operational.
- Making use of the Nuget.exe Client
This client can be downloaded from the Microsoft software distribution and is necessary for pushing a given package to the IIS hosted site.
The process of creating and pushing packages to the local server (IIS in this case) involves three steps:
- Create a “spec” or specification of the file (mostly an assembly.dll – created from the initial project build). This outputs a file with a “.nuspec” extension.
- Create the “package” of the file. This is the version that can be pushed to the local server.
- Configuring Nuget.exe
After downloading the Nuget.exe file, it is of import to configure the environmental variables to make the file accessible for use system-wide.
To do this;
- Navigate to “System Properties”.
- Click on “Environment Variables”.
- Click on “Path” and Click on “Edit…”.
- Insert the path of the downloaded Nuget.exe application above among the list of members of the “path” system variables.
5. Launch the command prompt.
6. And type in “nuget” in the prompt.
The screen below appears with the various actions that can be performed with the nuget command.
It should be noted once again that to push a package to the local server (or Azure), we need to create the file specification and package.
- Create spec
This is the first step involved in pushing a package (in .dll) to a local server in this case.
- Navigate to the the “~\bin\debug” directory (which is according to Microsoft standards) by making use of the command below:
- Copy the .dll file from the ProjectServer directory generated from the initial build and run the following command: “Nuget spec ProjectServer.dll”, so:
C:\Users\Johnmark\Documents\NugetDemo\NugetServerApp\ProjectServer\ProjectServer\bin\debug> Nuget Spec ProjectServer.dll
Created ‘ProjectServer.dll.nuspec’ successfully.
This will create a .nuspec extension file which needs to be edited based on some parameters.
The screenshot below shows a preview of the .nuspec file.
- Edit the .nuspec file
- Click on the .nuspec file and open with notepad. The following screenshot can be viewed.
Take note of several parameters including “Version”, “tags” and so on and edit those like the file below:
You may need to add the <files> element above to point the .dll file to the target source defined when we created our application.
- Push to local server
This is the climax of the process. After generating the .nupkg file, the following command can be run in the following format:
[Nuget push ProjectServer.dll.1.0.4.nupkg -Source C:\Users\Johnmark\Documents\HostedSiteExample\Packages -ApiKey MyAPIKey123]
The list of packages added to the nuget feed (via the localhost) reflects as a .xml document.
In the next blog post, we will look into consuming packages from our Nuget.Server feed. Let me know if you have any question(s).