Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Using nu get the way you should svcc

1,199 views

Published on

Using NuGet the way you should
Consuming NuGet packages, that’s what everyone does. Open source projects create NuGet packages and post them on NuGet.org. Meanwhile, all of us are still working with shared projects and fighting relative paths, versioning and so on. In this talk, we’ll use Visual Studio, NuGet and TeamCity to work with NuGet the way you should. Project references must die! Add Package Reference and good continuous integration is everything you will ever need.

Published in: Technology
  • Be the first to comment

Using nu get the way you should svcc

  1. 1. Using NuGet the way you should Maarten Balliauw @maartenballiauw
  2. 2. Who am I? • Maarten Balliauw • Antwerp, Belgium • Developer Advocate, JetBrains • Founder, MyGet • AZUG • Focus on web • Big passion: Azure • http://blog.maartenballiauw.be • @maartenballiauw Shameless self promotion: Pro NuGet - http://amzn.to/pronuget2
  3. 3. Agenda • NuGet • File | New Project… • The state of NuGet • Every project is a package • Creating packages • Distributing packages • Consuming packages
  4. 4. NuGet
  5. 5. A brief NuGet introduction... • Package management system for .NET • Visual Studio extension, command line, console • Simplifies incorporating 3rd party libraries • Developer focused • Free, open source • Use packages from the official feed • Publish your own packages • Create & use your own feed
  6. 6. File | New Project...
  7. 7. Demo File | New Project...
  8. 8. That was trouble! Dependency hell •Dependencies on NuGet packages •Dependencies on projects •Dependencies on file system layout • Breaking changes in dependencies
  9. 9. “Dependencies, also in real life, are trouble. Have you ever had to depend on a plumber showing up?” - Maarten Balliauw
  10. 10. Dependencies before NuGet • Projects in solution •Reference in-house projects: • Either the assemblies (typically unversioned / all 1.0.0.0) • Either the actual project / linked files (unversioned by design) •Reference third party assemblies (e.g. JSON.NET)
  11. 11. Dependencies with NuGet • Projects in solution •Reference in-house projects: • Either the assemblies (typically unversioned / all 1.0.0.0) • Either the actual project / linked files (unversioned by design) •Reference third party packages (e.g. JSON.NET) • Semantic Versioning to announce breaking changes (happy times as long as package authors respect that)
  12. 12. The state of NuGet
  13. 13. The state of NuGet Where are we, 3 years in? •We are consumers! • Even quite some overconsumption I dare say… •We sort of know about Semantic Versioning • If the mayor version changes, we’re doomed •Are we producing? • Some are, e.g. OSS and some companies • Did we solve our dependency issues?
  14. 14. .NET is late to the party! •Others have been doing package management for decades • Perl (CPAN.org) • Linux (RPM/YUM/APT-GET/...) • PHP (PEAR, Composer) • Node (npm) • Ruby (Gems) •We can learn a great deal from these!
  15. 15. What are the others doing? { "name" : "IniTech.Framework.Formatters", "version" : "1.0.0 ", "author" : "Maarten Balliauw", "bugs" : { "url" : "https://github.com/initech/framework-formatters/issues" }, "description" : "Formatters specific to the IniTech organization.", "homepage" : "https://github.com/initech/framework-formatters", "keywords" : [ "framework", "formatters", "initech" ], "license" : "Proprietary", "main" : "index.js", "repository" : { "type" : "git", "url" : "https://github.com/initech/framework-formatters" }, "scripts" : { "test" : "echo "Error: no test specified" && exit 1" }, "dependencies" : { "date-format" : "0.0.2", "format" : "~0.2.1", "moment" : "~2.5.1" } }
  16. 16. What are the others doing? What was in that package.json? •Name and version of the project •Dependencies (and version range) of the project • Every project is a package! • It can have dependencies • It can be depended on
  17. 17. Every project is a package
  18. 18. Supporting componentization • Every project is a package • Clearly identifyable • Proper Semantic Versioning • Every project becomes discoverable • Nice description, release notes, ... • Add it to a private feed so developers can find it •Dependencies (can) stay out of source control •Dependencies are versioned
  19. 19. But… NuGet only has packages.config! •Nodejs: packages.json •Composer (PHP): composer.json •NuGet: • packages.config: dependencies • <projectname>.nuspec: package description • NuGet.config: other settings • It’s 2-3 files in our world, but it is all there. • Let’s become producers!
  20. 20. Creating packages
  21. 21. All we need is one file <projectname>.nuspec • XML file which can be generated • nuget.exe spec • Install-Package NuSpec && Install-Nuspec •Run nuget.exe pack to create package
  22. 22. Demo Creating packages
  23. 23. Think about versioning! Enforce Explicit Semantic Versioning • www.semver.org Major Breaking changes Minor Backwards compatible changes e.g. API additions Patch Bugfixes not affecting the API • SemVer states intentions • It’s the only way to avoid dependency versioning hell. But not bullet-proof. <dependency id="ExamplePackage" version="1.3.2" /> 1.0 = 1.0 ≤ x (,1.0] = x ≤ 1.0 (,1.0) = x < 1.0 [1.0] = x == 1.0 (1.0) = invalid (1.0,) = 1.0 < x (1.0,2.0) = 1.0 < x < 2.0 [1.0,2.0] = 1.0 ≤ x ≤ 2.0 empty = latest version
  24. 24. Distributing packages
  25. 25. Which medium? We will need a “package source” or feed • In source control (please don’t) • Local / network folder (slow > ~50 packages) • NuGet.Server (slow > ~50 packages) • NuGet Gallery (clone of www.nuget.org) • MyGet (www.myget.org, SaaS) • ProGet (www.inedo.com/proget) • TeamCity NuGet artifacts (www.jetbrains.com/teamcity) • Sonatype (www.sonatype.com/nexus) • Artifactory (www.jfrog.com)
  26. 26. How do they get there? •Manual upload • As part of our continuous integration process • All benefits of CI (e.g. testing) • Plus reporting on which packages we are using • Plus publishing packages for consumption
  27. 27. Demo Continuous Integration & Distributing Packages with TeamCity
  28. 28. What did we just see? •Creating packages using .nuspec •NuGet configuration inheritance •Continuous Integration on TeamCity • How to run package restore • How to build a package • How to see packages that are being used •How to consume a package
  29. 29. NuGet configuration inheritance •Make settings common to projects! • NuGet walks up the directory tree to find NuGet.config files • Or even push them to developer machines • %AppData%NuGetNuGet.config • %ProgramData%NuGetConfig*.config • ... •See http://bit.ly/nuget-config-inheritance • Configure feeds, proxy, credentials, ...
  30. 30. More recommendations… • Don’t just update blindly • Not everyone respects SemVer… • It would take us back to the original problem • Don’t autoupdate during builds • Continuous Integration: Same Input = Same Output • Be explicit about versioning
  31. 31. Deploying from NuGet packages •Using a simple, handcrafted script • Using a tool like OctopusDeploy.com • Which is even cooler combined with Chocolatey.org •TeamCity supports various ways of deploying (e.g. WebDeploy)
  32. 32. Demo Deploying packaged applications with a handcrafted script
  33. 33. Considerations •TeamCity internal NuGet feed • Only build artifacts • No way to add external packages that are being used • May not be a problem for your setup • But maybe it is: a feed is much like source control for dependencies • Add dependencies that are being used, NuGet.org, component vendors, ... • If it is, create your own feed, e.g. MyGet.org
  34. 34. Create a package source / feed For your team or the entire organization • That’s a cool library! And that one too! • Avoid overconsumption by limiting packages • May not block developers but at least the build will fail • Your own feed will only contain packages you know • Keep versions under control • Keep licensing under control • Easy way to audit external packages in use
  35. 35. Demo Pushing packages from TeamCity
  36. 36. But I’m using NuGet. It’s broken!!! http://blog.nuget.org/20141010/nuget-is-broken. html • Tied to Visual Studio •Merging sucks (XML merge, yuck!) •Updating fails often • Disk space pollution • Project re-targeting •Pessimistic package version picker / fixed versions
  37. 37. Demo ASP.NET vNext approach is the way forward!
  38. 38. Conclusions
  39. 39. Conclusions What have we learned? • NuGet • File | New Project… • The state of NuGet • Every project is a package • Creating packages • Distributing packages • Consuming packages
  40. 40. “Project references must die. Embrace NuGet by consuming and creating packages. It’s a logical evolution.” - Maarten Balliauw
  41. 41. Thank you! http://blog.maartenballiauw.be @maartenballiauw http://amzn.to/pronuget2

×