• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
NuGet (anti-)patterns - Tales from the Trenches
 

NuGet (anti-)patterns - Tales from the Trenches

on

  • 925 views

 

Statistics

Views

Total Views
925
Views on SlideShare
903
Embed Views
22

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 22

https://twitter.com 20
https://web.tweetdeck.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 "close" isn'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

NuGet (anti-)patterns - Tales from the Trenches NuGet (anti-)patterns - Tales from the Trenches Presentation Transcript

  • #comdaybeNuGet (Anti-)Patterns:Tales from the TrenchesXavier Decoster
  • Who am I?Xavier DecosterFounder of MyGet.orgNuGet contributorAuthor of Pro NuGetMEET memberhttp://www.xavierdecoster.com@xavierdecoster
  • In this session
  • Agenda• What is NuGet (not)• Package versioning• Package repositories• Lessons learned
  • What is NuGet?• Solution-level PackageManagement for .NET• Tools:– NuGet.Core– NuGet.exe– NuGet Gallery (nuget.org)– NuGet-Based Microsoft PackageManager• Your new search engine!
  • What is NuGet not?• Perfect• Tool that magically fixes allyour problems• Replacement for softwareinstallers
  • Package versioningA single dot can separate heaven from hell…
  • #1 – Semantic VersioningMajor Breaking changesMinor Backwards compatible API additions/changesPatch Bugfixes not affecting the APIPrerelease Alpha, Beta, …, RC1, RC2, …Build Time stamp, VCS metadata, …1 . 0 . 2 - alpha+ 2013.06.20.143010Read the full specification at http://semver.org/Major Breaking changesMinor Backwards compatible API additions/changesPatch Bugfixes not affecting the APIPrerelease Alpha, Beta, …, RC1, RC2, …Build Time stamp, VCS metadata, …Major Breaking changesMinor Backwards compatible API additions/changesPatch Bugfixes not affecting the APIPrerelease Alpha, Beta, …, RC1, RC2, …Build Time stamp, VCS metadata, …Major Breaking changesMinor Backwards compatible API additions/changesPatch Bugfixes not affecting the APIPrerelease Alpha, Beta, …, RC1, RC2, …Build Time stamp, VCS metadata, …Major Breaking changesMinor Backwards compatible API additions/changesPatch Bugfixes not affecting the APIPrerelease Alpha, Beta, …, RC1, RC2, …Build Time stamp, VCS metadata, …Major Breaking changesMinor Backwards compatible API additions/changesPatch Bugfixes not affecting the APIPrerelease Alpha, Beta, …, RC1, RC2, …Build Time stamp, VCS metadata, …
  • #1 – Semantic Versioning• NuGet versioning algorithm differs from SemVerSemVer NuGetv x SemVer Versioning Scheme major.minor.patch[-prerelease][+build]v v NuGet pre-release package major.minor.patch-prereleasev v NuGet release package major.minor.patchx v MSDN Versioning Scheme major.minor.build.revision[-prerelease]
  • #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.. buildnumber• Instead use 2-Dots SemVernotation• Optionally with pre-release tag
  • #3 – Maintain a smooth upgrade path• Don’t change Package ID along the way!–Your packages will get stuck–So will your consumers
  • #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.Core1.0.1-alpha00001MyGet.Core1.0.1-alphaMyGet.Core1.0.1MyGet.Core1.0.1-alpha00256…
  • #4 – The effects of tight coupling…• Small packages > large packages• Specific functionality > Multifunctional packages
  • Package repositoriesAs important as your VCS!
  • #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)?
  • #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 promotepackages from one to another (including nuget.org!)MyGet.Core1.0.1-alpha00001MyGet.Core1.0.1-alphaMyGet.Core1.0.1MyGet.Core1.0.1-alpha00256…Different levels ofsupportDifferent audienceDifferent versioningschemeDifferent SLA?MyGet.Core1.0.1-alpha00001MyGet.Core1.0.1-alphaMyGet.Core1.0.1MyGet.Core1.0.1-alpha00256…
  • #7 – Once published, don’t delete packages• Breaks package restore!• Forces consumers to upgrade!• Using own NuGet server or fileshare?– Remove user permissions to delete!• Maintains upgrade path• Still available through packagerestore• Supported by NuGet.org andMyGet.org“Attempting to force a user to do something is both an exercise in futility and agreat way to guarantee that you have less users overall”- Rob Reynolds, creator of Chocolatey.org
  • #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 buildserver!)–%LocalAppData%NuGetCache
  • Lessons learnedGeneral guidance & advise from the trenches…
  • #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>
  • #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
  • #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…)
  • demoPackage sources, feeds, packages and their versions playingalong…Package Promotion
  • Q&A
  • Thanks!http://www.xavierdecoster.com@xavierdecosterCome get your MyGetstickers, you might get lucky!