NuGet (anti-)patterns - Tales from the Trenches

#comdaybe
NuGet (Anti-)Patterns:
Tales from the Trenches
Xavier Decoster

Who am I?
Xavier Decoster
Founder of MyGet.org
NuGet contributor
Author of Pro NuGet
MEET member
http://www.xavierdecoster.com
@xavierdecoster

Agenda
• What is NuGet (not)
• Package versioning
• Package repositories
• Lessons learned

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!

What is NuGet not?
• Perfect
• Tool that magically fixes all
your problems
• Replacement for software
installers

Package versioning
A single dot can separate heaven from hell…

#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/

#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]

#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

#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.Core
1.0.1-alpha00001
MyGet.Core
1.0.1-alpha
MyGet.Core
1.0.1
MyGet.Core
1.0.1-alpha00256
…

#4 – The effects of tight coupling…
• Small packages > large packages
• Specific functionality > Multifunctional packages

Package repositories
As 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 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
…

#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

#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

Lessons learned
General 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…)

demo
Package sources, feeds, packages and their versions playing
along…
Package Promotion

Thanks!
http://www.xavierdecoster.com
@xavierdecoster
Come get your MyGet
stickers, you might get lucky!


NuGet (anti-)patterns - Tales from the Trenches

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

Recently uploaded

Recently uploaded (20)

NuGet (anti-)patterns - Tales from the Trenches

Editor's Notes