Successfully reported this slideshow.
Your SlideShare is downloading. ×

NuGet (anti-)patterns - Tales from the Trenches

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Intro to NuGet
Intro to NuGet
Loading in …3
×

Check these out next

1 of 25 Ad
Advertisement

More Related Content

Slideshows for you (20)

Similar to NuGet (anti-)patterns - Tales from the Trenches (20)

Advertisement

Recently uploaded (20)

NuGet (anti-)patterns - Tales from the Trenches

  1. 1. #comdaybe NuGet (Anti-)Patterns: Tales from the Trenches Xavier Decoster
  2. 2. Who am I? Xavier Decoster Founder of MyGet.org NuGet contributor Author of Pro NuGet MEET member http://www.xavierdecoster.com @xavierdecoster
  3. 3. In this session
  4. 4. Agenda • What is NuGet (not) • Package versioning • Package repositories • Lessons learned
  5. 5. What is NuGet? • Solution-level Package Management for .NET • Tools: – NuGet.Core – NuGet.exe – NuGet Gallery (nuget.org) – NuGet-Based Microsoft Package Manager • Your new search engine!
  6. 6. What is NuGet not? • Perfect • Tool that magically fixes all your problems • Replacement for software installers
  7. 7. Package versioning A single dot can separate heaven from hell…
  8. 8. #1 – Semantic Versioning Major Breaking changes Minor Backwards compatible API additions/changes Patch Bugfixes not affecting the API Prerelease Alpha, Beta, …, RC1, RC2, … Build Time stamp, VCS metadata, … 1 . 0 . 2 - alph a + 2013.06.20.143010 Read the full specification at http://semver.org/ Major Breaking changes Minor Backwards compatible API additions/changes Patch Bugfixes not affecting the API Prerelease Alpha, Beta, …, RC1, RC2, … Build Time stamp, VCS metadata, … Major Breaking changes Minor Backwards compatible API additions/changes Patch Bugfixes not affecting the API Prerelease Alpha, Beta, …, RC1, RC2, … Build Time stamp, VCS metadata, … Major Breaking changes Minor Backwards compatible API additions/changes Patch Bugfixes not affecting the API Prerelease Alpha, Beta, …, RC1, RC2, … Build Time stamp, VCS metadata, … Major Breaking changes Minor Backwards compatible API additions/changes Patch Bugfixes not affecting the API Prerelease Alpha, Beta, …, RC1, RC2, … Build Time stamp, VCS metadata, … Major Breaking changes Minor Backwards compatible API additions/changes Patch Bugfixes not affecting the API Prerelease Alpha, Beta, …, RC1, RC2, … Build Time stamp, VCS metadata, …
  9. 9. #1 – Semantic Versioning • NuGet versioning algorithm differs from SemVer SemVer NuGet v x SemVer Versioning Scheme major.minor.patch[-prerelease][+build] v v NuGet pre-release package major.minor.patch-prerelease v v NuGet release package major.minor.patch x v MSDN Versioning Scheme major.minor.build.revision[-prerelease]
  10. 10. #2 – Avoid 3-dots versioning schemes • Even though supported by NuGet – Not supported in SemVer – Not supported in combination with pre- release tag in patch… ergh.. build number • Instead use 2-Dots SemVer notation • Optionally with pre-release tag
  11. 11. #3 – Maintain a smooth upgrade path • Don’t change Package ID along the way! –Your packages will get stuck –So will your consumers
  12. 12. #3 – Maintain a smooth upgrade path • Version Precedence – 1.0.1-alpha00001 < 1.0.1-alpha00256 < 1.0.1-alpha < 1.0.1 – Question: Where does 1.0.1-alpha2 fit? MyGet.Core 1.0.1-alpha00001 MyGet.Core 1.0.1-alpha MyGet.Core 1.0.1 MyGet.Core 1.0.1-alpha00256 …
  13. 13. #4 – The effects of tight coupling… • Small packages > large packages • Specific functionality > Multifunctional packages
  14. 14. Package repositories As important as your VCS!
  15. 15. #5 – Package Restore • A package repository is for … packages – What’s a source repository for? • Impact of package restore – No more duplication of binaries – Less merge conflicts (no binary diff) – Maintain overview of consumed packages in single place – Less network I/O (NuGet cache) – Package source is now critical system (as is your source repository…) • Contra-argument: single point of failure – Good remark: now deal with it! – What if I’m disconnected from the package source(s)?
  16. 16. #6 – Split package repositories • Don’t pollute consumers’ repository with your internal DEV builds – MyGet.org is great at this: set up as many feeds as you want and promote packages from one to another (including nuget.org!) MyGet.Core 1.0.1-alpha00001 MyGet.Core 1.0.1-alpha MyGet.Core 1.0.1 MyGet.Core 1.0.1-alpha00256 … Different levels of support Different audience Different versioning scheme Different SLA? MyGet.Core 1.0.1-alpha00001 MyGet.Core 1.0.1-alpha MyGet.Core 1.0.1 MyGet.Core 1.0.1-alpha00256 …
  17. 17. #7 – Once published, don’t delete packages • Breaks package restore! • Forces consumers to upgrade! • Using own NuGet server or file share? – Remove user permissions to delete! • Maintains upgrade path • Still available through package restore • Supported by NuGet.org and MyGet.org “Attempting to force a user to do something is both an exercise in futility and a great way to guarantee that you have less users overall” - Rob Reynolds, creator of Chocolatey.org
  18. 18. #8 – Have a fallback repository • Backup consumed packages –Mirror them on MyGet.org –Download them • Especially when using Package Restore –From NuGet.org –From any external feed • Each consumer has local cache (incl. the build server!) –%LocalAppData%NuGetCache
  19. 19. Lessons learned General guidance & advise from the trenches…
  20. 20. #9 – Spot Binding Redirects • Mitigates potential risk for conflicts – During assembly resolution • Investigate why – Package versions not aligned? <configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="myAssembly" publicKeyToken="32ab4ba45e0a69a1" culture="neutral" /> <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration>
  21. 21. #10 – Use Sample Package or Readme.txt • Don’t pollute your actual packages • Provide a readme.txt – If you can’t automate the manual instructions – If you want to have your consumers read some specific info – Automatically presented to consumer during installation • Use a sample package when appropriate – Separate package  Different package ID – Convention: {packageID}.Sample • SignalR  SignalR.Sample – Sample package depends on actual package you want to ship
  22. 22. #11 – Uninstall Should Leave No Traces • Obvious, but often neglected/forgotten – Be a good citizen • Uninstall reverses installation + any side-effects – Unless modifications happened • Uninstall – Any files copied (binaries, sources, content, scripts…) – Tools package: any system modifications (PowerShell modules, registry keys, environment variables…)
  23. 23. demo Package sources, feeds, packages and their versions playing along… Package Promotion
  24. 24. Q&A
  25. 25. Thanks! http://www.xavierdecoster.com @xavierdecoster Come get your MyGet stickers, you might get lucky! 

Editor's Notes

  • As a developer, we allhate friction. It’s the thingthatannoysus the most in ourday-to-day job. Low bandwidth, slow builds, mergeconflicts, anddependencyconflicts, justto name a few.The introduction of a package manager into the .NET world has been one of the most excitingthings in years: every decent programming stack has a package management system to deal withdependencies. NuGet has been aroundfor over 2 years, andmanydevelopersand open source projects have found there way towards the NuGet Gallery. However, whenitcomestousing NuGet in the organizationyouquicklyfind a lack of strategy. I oftenfind a situationwhich is “grownorganically”, causing more problemsthanitsolves. Andthentheyfindthemselvesquitefrustrated.
  • Thissession is goingto cover some common pitfalls in terms of package versioning. I’llalsohighlight the importance of package repositoriesand share a few lessonslearnedalong the way.
  • Package versioning is almost the first instant roadblockwhenyou start creating NuGet packages.A single dot can separate youfromdependencyhell or a smooth package management experience.The package version is also part of the combinedkeythatmakes a NuGet package unique: the package ID and the package Version.
  • This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that &quot;close&quot; isn&apos;t good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, flexible (but not too flexible) dependency specifications can finally be made.
  • DEMO: package restoreDisable internet connectivityand show how the cache canbeused as a fallbackExplain a fallbackrepositoryshouldbemaintainedifusingprimarilyexternal package sources

×