UPDATE: A better solution I think is to use VSTS’s new package Management feature if you are using VSTS already.
Nuget is a great way to share packages around, but a lot of the LOB apps I work on we need a private solution that isn’t open to the public. I’ve setup Klondike (https://github.com/themotleyfool/Klondike) a couple of times now and find it to be light weight and dumb enough not to give any problems.
I even used it for my octopack nuget files (instead of the built in nuget server in octopus) as I find it handy just to have all your nuget in the one place.
Installation is easy, just extract it to a folder and point an IIS webroot at it. Supports self-hosted in OWIN as well if that is more your flavor.
To get everything setup i generally set this value in the web.config, it treats all request from the local server as admin. So using a web browser on the local server I get everything setup.
<add key="NuGet.Lucene.Web:handleLocalRequestsAsAdmin" value="true" />
I’ve dropped this on servers on a domain before and used windows auth as well for authentication at an IIS level, which works fine. You could also use Basic Auth and create user accounts on the local server to manage access which I’ve done as well without any complaints.
In general terms, most projects in private sources that I work on, if you have access to the source control you should have permission to read from the nuget server, so I leave the credentials for the nuget server in my nuget.config at the root of each project in source.
Example configuration below from one of my projects:
<?xml version="1.0" encoding="utf-8"?> <configuration> <activePackageSource> <add key="All" value="(Aggregate source)" /> </activePackageSource> <packageRestore> <add key="enabled" value="true" /> </packageRestore> <solution> <add key="disableSourceControlIntegration" value="true" /> </solution> <packageSources> <add key="MyNugetServerInAzure" value="https://MyOctopusServer.cloudapp.net:88/" /> <add key="nuget.org" value="https://nuget.org/api/v2/" /> </packageSources> <packageSourceCredentials> <MyNugetServerInAzure> <add key="Username" value="MyUserAccount" /> <add key="ClearTextPassword" value="XXXXX /> </MyNugetServerInAzure> </packageSourceCredentials> </configuration>
And then create the User Account in the Computer Manager on the server and setup IIS Authenticaiton on the Klondike website like so:
And you are away. I have had odd issues using the above with the role mappings, so i generally leave these settings alone
<roleMappings> <add key="PackageManager" value="" /> <add key="AccountAdministrator" value="" /> </roleMappings>
The only thing to point out in the config I change generally for Klondike is is
<add key="NuGet.Lucene.Web:localAdministratorApiKey" value="XXX" />
And drop in an API key to use when updating packages, I don’t always give this out to all the developers working on it, but instead save the API key in the build server to force check-in to update packages via the build system.
One last issue i have with Klondike is this error “The process cannot access the file ‘C:\inetpub\wwwroot\App_Data\Lucene\write.lock’ because it is being used by another process.”
If you recycle the worker process this happens, touch the web config file and it will fix it up.