Apr 1, 2012 at 5:41 PM
Edited Apr 1, 2012 at 9:53 PM
When the NuGet Gallery was down, a discussion was raised on whether a mirror could help people out that do not commit their packages into their VCS. I'm in favor for such fallback solution as it would enable people to download those packages not yet available
in their local user cache.
However, a potential interesting alternative fallback came to mind when it comes (e.g. but not limited) to Continuous Integration in those scenarios. The idea of a centralized (e.g. company-wide) cache could mitigate build failures in case any external package
source is unavailable. This is achievable under one condition: that central cache should be in sync with the developers' local package caches. Hence the idea of a
local package cache synchronization feature, allowing to decouple CI environments from external, non-controlled dependencies. This enables people (and build servers) to continue to work, probably even without noticing the downtime if set up properly
(central cache == fallback package source for all).
Enough chatter, here's what I had in mind (and in my
- Package Sources from the Package Sources options tab are displayed (except official NuGet source, Local User Cache and Aggregates)
- Shared PackageSourceOptionsContext between Package Cache Sync and Package Sources options pages, keeping their state in sync as long as the dialog is open
- New CacheSynchronizationConsent (similar to the new PackageRestoreConsent)
- New bool PackageSource.IsCacheSynchronizationTarget property
- New NuGet.Config section "cacheSyncPackageSources", elements refer to package source (by name) defined in "packageSources"
<add key="My Remote Cache" value="true" />
- Manually synchronization using the Invoke-PackageCacheSync cmdlet in the console (supporting cancellation & currently doesn't require a solution to be opened)
- Option to auto-sync upon new package installation
<add key="enabled" value="true" />
- Auto-sync is logged into the ProgressReportDialog and VisualStudio Output windows, as shown below
------- Installing...AutoMapper 2.1.265 -------
Added file 'AutoMapper.dll' to folder 'AutoMapper.2.1.265\lib\net40'.
Added file 'AutoMapper.xml' to folder 'AutoMapper.2.1.265\lib\net40'.
Added file 'AutoMapper.dll' to folder 'AutoMapper.2.1.265\lib\sl4'.
Added file 'AutoMapper.XML' to folder 'AutoMapper.2.1.265\lib\sl4'.
Added file 'AutoMapper.2.1.265.nupkg' to folder 'AutoMapper.2.1.265'.
Successfully installed 'AutoMapper 2.1.265'.
Syncing package 'AutoMapper 2.1.265' to 'http://www.myget.org/F/myremotecache'...
Synced package 'AutoMapper 2.1.265' to 'http://www.myget.org/F/myremotecache'.
Added reference 'AutoMapper' to project 'ClassLibrary3'
Added file 'packages.config'.
Successfully added 'AutoMapper 2.1.265' to ClassLibrary3.
- Ability to quickly create an online remote using the
create a remote feed link (which navigates to
- Created a RemoteCacheTargetPackageRepository (which is a composite of DataServicePackageRepository) and supports pushing to remote feeds using an API key
- All existing tests are green (and adjusted where necessary)
- PackageSource now supports ApiKey (and so does the Package Sources options page)
- Rename the Package Cache Sync options page to Package Cache and move the cache-related stuff from the General options page to this one.
- Extend the Invoke-PackageCacheSync cmdlet, e.g. to scope by solution or project level pkgs
- Improve test coverage
- Add a contextmenu entry in Solution Explorer to sync packages from sln/proj (reusing underlying scope logic of extended Invoke-PackageCacheSync cmdlet for instance, and only enabled if PackageCacheSyncConstent.IsGranted = true)
- Probably there's still room for some performance improvements
I prefer triggering a discussion before sending a pull request of this size :) Do you think this would be a good addition to the NuGet vsix?
Note that building this as a separate optional vsix is not that straightforward because integration with the NuGet vsix would be harder to accomplish and maintain (there's not really an official release of the NuGet VisualStudio libraries for instance, not
to mention the integration with NuGet.Config).