Private corporate batches, live online cohorts and 1-on-1 mentoring in the .NET package manager end to end — package sources, restore, authoring and publishing, private feeds and reproducible dependency management — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches NuGet from both directions: consuming packages predictably — source configuration and its precedence rules, restore behaviour, transitive resolution and lock files — and producing them, from nuspec and package layout through versioning, symbols, signing and publication to public or private feeds. Sessions cover the operational edges most .NET courses skip entirely: why a build restores differently on an agent than on a laptop, how to run an internal feed, and how to make a package a consuming team can upgrade without fear.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For NuGet that means a trainer who has run it in production — the .NET package manager end to end — package sources, restore, authoring and publishing, private feeds and reproducible dependency management — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private NuGet batchNuGet is the package manager for .NET. A NuGet package is a zip archive with a .nupkg extension containing a nuspec manifest, compiled assemblies laid out by target framework, and optionally content files, MSBuild targets, native runtime assets and analyzers. The manifest declares the package's identity, its version, its dependencies — expressed as version ranges that vary per target framework — and the licence and metadata that consumers see.
On the consuming side, NuGet resolves that dependency graph at restore time. Modern projects declare dependencies with PackageReference in the project file rather than a separate packages.config, and restore walks the transitive graph, applies nearest-wins conflict resolution, and writes a project.assets.json describing exactly what the compiler and the runtime will see. Packages themselves are cached globally rather than copied per project, which is why a clean build on a fresh agent behaves differently from one on a developer machine.
On the producing side, NuGet is how .NET code moves between teams. Packages are built with dotnet pack or nuget.exe, inspected with the Package Explorer, and pushed to a feed — nuget.org for public libraries, or a private feed for internal code. Where the feed lives matters more than it looks: package sources are configured through a hierarchy of NuGet.config files, and getting that hierarchy wrong is behind a large share of "it restores on my machine" incidents.
Almost every .NET codebase of consequence is now assembled rather than written. The application team owns perhaps a fifth of the assemblies it ships; the rest arrive through NuGet from nuget.org, from vendor feeds and from internal libraries. That makes dependency management a first-order engineering concern rather than a tooling detail.
Three pressures have sharpened this. Supply-chain scrutiny means organisations now have to know what is inside their packages and where each one came from, which pushes teams onto private feeds and proxies they control. Reproducibility requirements mean floating versions and unlocked restores are no longer acceptable in regulated pipelines. And the migration from packages.config to PackageReference, and from nuget.exe to the dotnet CLI, has left many organisations with build systems that half-work in two idioms at once.
The hiring demand follows that. Consuming packages is a five-minute skill. Designing an internal package strategy — feed topology, versioning, central package management, restore determinism, publication and deprecation — is what teams actually need and rarely have.
What NuGet is responsible for and what it is not. Package identity and versioning, the difference between PackageReference and the legacy packages.config, where the tooling lives across Visual Studio, the dotnet CLI and nuget.exe, and how the moving parts fit together before any of them are used.
Topics: Introduction — the problem NuGet solves and the vocabulary · Online Resources — official documentation, the gallery and protocol references · Installing NuGet — dotnet CLI, nuget.exe and Visual Studio tooling · Package identity, versioning and SemVer as NuGet interprets it · PackageReference versus packages.config, and migrating between them · Where packages actually go: the global packages folder and the HTTP cache
The configuration layer that decides where packages come from, and the layered NuGet.config hierarchy that explains why a restore behaves differently on a build agent than on a developer machine. Includes authenticated feeds, credential providers and source mapping.
Topics: Package Sources — declaring, ordering, enabling and disabling · Navigating to Different NuGet Package Sources in tooling and on the command line · The NuGet.config hierarchy: machine, user, solution and repository level · Ensuring your Environment is Properly Configured — diagnosing effective configuration · Authenticated feeds, credential providers and CI service connections · Package source mapping to pin which source may serve which package
The interface most .NET developers use daily, taught in terms of what it does to the project file underneath. Browsing and filtering sources, install and update semantics, pre-release handling, and reading the changes a dialog action makes so they can be reviewed rather than trusted.
Topics: Overview of Visual Studio Integration · Nuget Package Manager Dialog — browse, installed, updates and consolidate · Overview and Review of the NuGet Package Manager Dialog options · Installing, Uninstalling and Updating NuGet Packages · Pre-release packages and version selection in the dialog · What each action writes to the project file, and reviewing it before commit
Everything the dialog can do, plus everything it cannot. The console for scripted and repeatable operations, and the command-line tooling that CI actually runs — restore, add, list, pack and push — including where dotnet and nuget.exe differ.
Topics: NuGet Package Manager Console and its PowerShell cmdlets · Introducing and Publishing with the NuGet Command Line Tool · dotnet restore, add package, list package and remove package · dotnet CLI versus nuget.exe — capability differences that matter in CI · Scripted and repeatable dependency operations · Reading verbose restore output to diagnose resolution
Opening packages up. What is really inside a nupkg, how target frameworks and asset folders determine which assembly a consumer gets, and how to inspect a third-party package before trusting it — including the ones that behave strangely because of MSBuild targets you never read.
Topics: Downloading and Installing the Package Explorer · Introduction to the Package Explorer · Anatomy of an Existing Package — nuspec, lib, ref, runtimes, build, contentFiles · Target framework monikers and asset selection rules · MSBuild props and targets shipped inside packages · Advanced Features in the Package Explorer — editing, validating and signing views · Examining the Data Feed of the Official NuGet Package Source
Producing packages other teams can rely on. Metadata that makes a package discoverable and legally clear, dependency ranges that neither over-constrain nor float freely, multi-targeting, and the symbol and source-link work that makes debugging a consumed package possible.
Topics: Creating a Simple Package — nuspec and SDK-style project properties · Creating a Package with Dependencies, and choosing version ranges deliberately · Multi-targeting and per-framework dependency groups · Licence expressions, README, icon and repository metadata · Symbol packages, snupkg and SourceLink for debuggable dependencies · Deterministic and reproducible pack output · Versioning strategy: stable, pre-release and CI-generated versions
Getting packages to consumers and managing them afterwards. Account and API key handling, publication paths through tooling and the command line, package signing, and the lifecycle operations — deprecation, unlisting, delisting — that matter once a package has real consumers.
Topics: Publishing Packages — the publication workflow · Establishing a NuGet account and managing API keys and scopes · Publishing via the NuGet Package Explorer · Publishing from CI with scoped, short-lived keys · Author and repository signing, and verifying signatures on restore · Deprecation, unlisting and the fact that packages cannot truly be deleted · Vulnerability disclosure and shipping a fixed version
Running the feed rather than depending on someone else's. Options from a simple local server to a full gallery to a repository manager, the protocol differences that determine what works, and the proxying and offline scenarios that regulated environments require.
Topics: Hosting Your Own NuGet Feed — the available options and their trade-offs · Installing NuGet.Server for a lightweight internal feed · Working with the local NuGet.Server and its limitations · Using the Command Line Tool in Conjunction with NuGet.Server · Installing and Hosting Your Own NuGet Gallery · Feeds inside a repository manager — proxy, hosted and grouped sources · The V2 and V3 protocols, service indexes and why clients behave differently · Folder feeds, offline mirrors and fully air-gapped restore · NuGet Community and Advanced Topics — governance, conventions and where to follow changes
Making dependency resolution deterministic and keeping it that way. Lock files, central package management, transitive pinning, and the audit and upgrade practices that keep a large solution from drifting into an unresolvable state.
Topics: Lock files: packages.lock.json and locked-mode restore in CI · Central Package Management with Directory.Packages.props · Floating versions and where they are and are not acceptable · Transitive pinning and resolving diamond conflicts explicitly · Vulnerability auditing and the NuGet audit report · Upgrade strategy for large solutions, including framework transitions · Restore performance: caching on agents and in containers
We rebuild the agenda around the tools you actually run.
Request a custom agendaReproduce a restore that works locally and fails on a build agent, then fix it properly through the NuGet.config hierarchy and source mapping rather than by adding a flag.
Open real packages in the Package Explorer, work out which assembly a consumer gets on each target framework, and find one that injects MSBuild targets.
Pack a multi-targeted library with correct dependency ranges, licence metadata, symbols and SourceLink, then debug into it from a separate consuming solution.
Stand up an internal feed, push from a pipeline with a scoped key, restore from a clean machine, and add a proxy source so public packages arrive through your infrastructure.
Enable lock files and central package management across a multi-project solution, then prove that two clean agents produce identical dependency graphs.
Design and implement the full path for internal .NET libraries: versioning, packing, signing, publishing, consumption, deprecation and vulnerability response.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.