Private corporate batches, live online cohorts and 1-on-1 mentoring in the .NET build engine in depth — properties, items, targets, batching, incremental builds and binlog-driven diagnostics — 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 MSBuild as a language rather than a configuration file — the evaluation and execution phases that explain most surprising behaviour, properties and items with metadata, targets with inputs and outputs that make incremental builds correct, and item batching, which is where most engineers stop and most build bugs begin. Sessions are driven by binary logs rather than trial and error: reading a real slow build in the structured log viewer, finding the target that never skips, diagnosing evaluation-order and import problems, writing custom and inline tasks, packaging build logic for reuse, and converting legacy project files to SDK-style projects that build on a Linux agent.
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 MSBuild that means a trainer who has run it in production — the .NET build engine in depth — properties, items, targets, batching, incremental builds and binlog-driven diagnostics — 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 MSBuild batchMSBuild is the build engine behind .NET. Every .csproj, .vbproj and .fsproj file is an MSBuild project, and every build started from an IDE, from dotnet build or from a CI agent ultimately runs the same engine over the same XML. Most .NET developers have edited a project file without ever learning the language it is written in, which is why build problems in .NET estates tend to be diagnosed by trial and error rather than by reading.
MSBuild has four concepts and they are worth learning precisely. Properties are scalar values. Items are lists whose entries carry metadata. Targets are named, ordered units of work that can declare inputs and outputs so the engine can skip them when nothing has changed. Tasks are the executable units inside a target — Copy, Exec, Csc, MSBuild itself, or a class you wrote. On top of those sit conditions, item transforms and batching, which is the feature that lets one target run once per distinct metadata value and is simultaneously the most powerful and least understood part of the language.
A build also has two distinct phases that explain most confusing behaviour: evaluation, where the engine reads properties and items in order and imports .props and .targets files, and execution, where targets actually run. Directory.Build.props and Directory.Build.targets let you set policy for an entire repository without editing every project. The binary log — msbuild /bl — records the whole of both phases and turns build debugging from guesswork into reading a structured trace, which for most teams is the single highest-value thing in this syllabus.
.NET estates are large, long-lived and, for the most part, undocumented at the build layer. The people who wrote the original project files have moved on, builds have accumulated targets nobody dares delete, and a full build takes fifteen minutes where it should take three. Somebody has to own that, and the skill is genuinely scarce because MSBuild is treated as an implementation detail rather than something to learn.
Migration is the other driver, and it is the reason most teams book this training. Legacy project files to SDK-style projects, packages.config to PackageReference, .NET Framework to modern .NET, and Windows-only builds to something that runs on a Linux CI agent. All four require reading and rewriting MSBuild, and doing it without a working knowledge of evaluation order, imports and conditions is how a migration turns into a quarter of unexplained build failures.
The third is cost. Build time is paid for in CI minutes and in developer waiting. Real reductions come from correct incremental targets, restoring properly, avoiding redundant project references, and understanding where time is actually going — which requires a binary log and someone who can read it. Teams that guess at build performance usually make it worse.
The mental model that everything else depends on. What happens between invoking a build and code being compiled: evaluation order, imports, the SDK implicit imports, target graph construction and execution. This module alone resolves most long-standing confusion in a .NET build.
Topics: Understanding the MSBuild execution model · Evaluation phase versus execution phase · Import order and implicit SDK imports · Directory.Build.props and Directory.Build.targets · Reserved and well-known properties · How the target graph is built · msbuild, dotnet build and the IDE compared · Where the engine reads configuration from
The data model. Scalar properties and their precedence, item lists and the metadata every item carries, well-known metadata, property and item functions, and the difference between defining items during evaluation and inside a target.
Topics: PropertyGroup and property precedence · Command-line properties and response files · Environment variables as properties · ItemGroup, Include, Exclude and Remove · Well-known metadata: Identity, Filename, Extension, RecursiveDir · Custom item metadata · Property functions and item functions · Items inside targets versus at evaluation time
The unit of work. Target ordering with DependsOnTargets, BeforeTargets and AfterTargets; the built-in task library that covers most needs; returning values from targets; and calling other projects with the MSBuild task.
Topics: Target definition, Name and Condition · DependsOnTargets, BeforeTargets and AfterTargets · Built-in tasks: Copy, Exec, MakeDir, Delete, WriteLinesToFile · ReadLinesFromFile, XmlPeek and XmlPoke · The MSBuild task and building other projects · CallTarget and why it is usually the wrong answer · Target Returns and Outputs · Extending the standard build with hook targets
The part where most engineers stop, and where the most valuable capability lives. Condition syntax and evaluation, item transforms with separators, and task and target batching — running the same work once per distinct metadata value.
Topics: Condition syntax, operators and string comparison · Conditions during evaluation versus execution · Item transforms and custom separators · Task batching with %(Metadata) · Target batching and its differences · Batching pitfalls and empty batches · Combining batching with conditions · Reading someone else's batched target
Making builds fast and keeping them correct. Inputs and Outputs on targets, up-to-date checks, why a target never skips, the cost of assembly reference resolution and restore, parallel builds, and node reuse behaviour on a CI agent.
Topics: Target Inputs and Outputs · Up-to-date checks and target skipping · Diagnosing a target that always runs · Incremental correctness versus incremental speed · Parallel builds with /m and project-level parallelism · Node reuse and why CI should disable it · ResolveAssemblyReference cost · Restore cost and when to skip it · Static graph and isolated builds
The module that changes how attendees work. Verbosity levels and what each exposes, the console and file loggers, the binary log and the structured log viewer, writing a custom logger, and the systematic method for troubleshooting a slow or misbehaving build.
Topics: Logging and verbosity levels · Console logger and its parameters · File logger and multiple log files · The binary log and structured log viewer · Reading evaluation and execution from a binlog · Custom loggers and the ILogger interface · Distributed loggers in parallel builds · Troubleshooting a slow build methodically · Filtering and interpreting build events
Making builds fail correctly and only when they should. The error and warning model, warnings as errors and selective suppression, ContinueOnError and its risks, Exec exit codes, and the flaky-build patterns that waste the most engineering time.
Topics: Handling errors: the Error and Warning tasks · MSBuild error and warning codes · TreatWarningsAsErrors and selective suppression · WarningsAsErrors and WarningsNotAsErrors · ContinueOnError modes and when each is legitimate · Exec exit codes and IgnoreExitCode · Validating inputs early with conditions · Diagnosing intermittent build failures · Failing fast in CI versus locally
Writing your own build logic properly. Custom tasks in C#, ToolTask for wrapping executables, inline tasks for small jobs, and packaging shared build logic as .props and .targets inside a NuGet package so every repository consumes the same rules.
Topics: Writing a custom task with the Task base class · ToolTask for wrapping command-line tools · Task inputs, outputs and Required parameters · Inline tasks with UsingTask and RoslynCodeTaskFactory · Targeting both .NET Framework and .NET runtimes · Packaging .props and .targets in a NuGet package · Build/buildTransitive package conventions · Versioning and rolling out shared build logic · Testing build logic
MSBuild where the money is. Multi-targeting and inner and outer builds, deterministic and reproducible builds, publishing, and the migration work most teams actually need — legacy project files to SDK-style, packages.config to PackageReference, and Windows-only builds onto Linux agents.
Topics: TargetFrameworks, inner and outer builds · Restore, build and publish in CI · Deterministic builds and SourceLink · Publishing profiles and output layouts · Central Package Management with Directory.Packages.props · packages.config to PackageReference migration · Legacy project files to SDK-style projects · Making a Windows-only build run on Linux · Versioning artifacts from the build
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a project nobody fully understands and trace evaluation, imports and target execution end to end until every value and every target has a known origin.
Replace a block of copy-pasted near-identical targets with a single batched target, then fix the empty-batch case that silently produces nothing.
Profile a slow solution from a binary log, identify the target that breaks incrementality, fix its Inputs and Outputs and measure the difference.
Given a failing build and no ability to edit the project, capture a binary log and identify the root cause purely by reading it.
Write a custom task that enforces a build policy, package it with .props and .targets in a NuGet package, and consume it from two separate repositories.
Convert a legacy project file to SDK-style, migrate packages.config to PackageReference, and get it restoring and building deterministically on a Linux CI agent.
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
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| 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.