{"id":478,"date":"2026-10-14T16:41:20","date_gmt":"2026-10-14T16:41:20","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2016\/07\/02\/extension-used-in-dotnet-and-msbuild-projects\/"},"modified":"2026-10-14T16:41:20","modified_gmt":"2026-10-14T16:41:20","slug":"extension-used-in-dotnet-and-msbuild-projects","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/extension-used-in-dotnet-and-msbuild-projects\/","title":{"rendered":"MSBuild File Extensions Explained: .proj, .targets, .props, .tasks, and *proj Types"},"content":{"rendered":"\n

Originally published on 2016-07-02; fully revised and updated.<\/em><\/p>\n\n\n\n

MSBuild separates build logic into different file types so teams can reuse settings, tasks, and targets across many projects. If you work with .NET builds, this guide clarifies the role of each extension, shows how imports are typically layered, and provides practical examples you can adapt. This revision is based on the original post<\/a>.<\/p>\n\n\n\n

Extensions used in .NET and MSBuild projects<\/figure>\n\n\n\n

What each MSBuild-related extension is for<\/h2>\n\n\n\n
Extension or pattern<\/th>Primary purpose<\/th>Typical usage<\/th>Example<\/th><\/tr><\/thead>
.proj<\/code><\/td>Top-level or orchestrator build project<\/td>Calls targets, imports shared files, coordinates multi-project builds<\/td>build.proj<\/code>, main.proj<\/code><\/td><\/tr>
.targets<\/code><\/td>Reusable target definitions<\/td>Imported into other projects; usually provides build steps, not full standalone builds<\/td>Microsoft.Common.targets<\/code><\/td><\/tr>
.props<\/code><\/td>Shared properties and defaults<\/td>Imported early to set common values used later in evaluation<\/td>Microsoft.Cpp.props<\/code><\/td><\/tr>
.tasks<\/code><\/td>Task registration includes<\/td>Contains UsingTask<\/code> declarations for custom tasks<\/td>MSBuild.ExtensionPack.tasks<\/code><\/td><\/tr>
.settings.targets<\/code><\/td>Team naming convention for shared settings<\/td>Imported file for common build and deployment settings<\/td>EntityFramework.settings.targets<\/code><\/td><\/tr>
*proj<\/code><\/td>Language or project-type file<\/td>Main project definition consumed by MSBuild tooling<\/td>.csproj<\/code>, .vbproj<\/code>, .vcxproj<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Language-specific project extensions from the original reference<\/h2>\n\n\n\n

The original article also listed these project-type extensions. They identify the language or tooling ecosystem around a project file.<\/p>\n\n\n\n

Extension<\/th>Project type<\/th><\/tr><\/thead>
.csproj<\/code><\/td>C#<\/td><\/tr>
.vbproj<\/code><\/td>VB.NET<\/td><\/tr>
.vcxproj<\/code><\/td>Visual C++<\/td><\/tr>
.dbproj<\/code><\/td>Database project<\/td><\/tr>
.fsproj<\/code><\/td>F#<\/td><\/tr>
.pyproj<\/code><\/td>IronPython<\/td><\/tr>
.rbproj<\/code><\/td>IronRuby<\/td><\/tr>
.wixproj<\/code><\/td>Windows Installer XML (WiX)<\/td><\/tr>
.vdproj<\/code><\/td>Visual Studio Deployment Project<\/td><\/tr>
.isproj<\/code><\/td>InstallShield<\/td><\/tr>
.pssproj<\/code><\/td>PowerShell<\/td><\/tr>
.modelproj<\/code><\/td>Modeling project<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

How these files typically work together<\/h2>\n\n\n\n

Import order and file responsibility are the core ideas: shared properties are usually loaded early, reusable targets and tasks are imported where needed, and the entry project triggers execution.<\/p>\n\n\n\n

\nflowchart LR\n    A[Start build command] --> B[Load entry project file]\n    B --> C[Import shared props]\n    C --> D[Evaluate properties and items]\n    D --> E[Import tasks and targets]\n    E --> F[Execute requested target]\n    F --> G[Compile package deploy]\n<\/pre>\n\n\n\n
Practical examples<\/h2>\n\n\n\n
Example: orchestrator .proj<\/code> file that imports shared configuration and runs a project build.<\/p>\n\n\n
<Project<\/span> DefaultTargets<\/span>='Build'<\/span> xmlns<\/span>='http:\/\/schemas.microsoft.com\/developer\/msbuild\/2003'<\/span>><\/span>\n  <Import<\/span> Project<\/span>='build\/common.props'<\/span> \/><\/span>\n  <Import<\/span> Project<\/span>='build\/common.tasks'<\/span> \/><\/span>\n\n  <Target<\/span> Name<\/span>='Build'<\/span>><\/span>\n    <MSBuild<\/span> Projects<\/span>='src\/MyApp\/MyApp.csproj'<\/span>\n             Targets<\/span>='Build'<\/span>\n             Properties<\/span>='Configuration=Release'<\/span> \/><\/span>\n  <\/Target<\/span>><\/span>\n\n  <Import<\/span> Project<\/span>='build\/common.targets'<\/span> \/><\/span>\n<\/Project<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
Example: reusable .targets<\/code> file.<\/p>\n\n\n
<Project<\/span> xmlns<\/span>='http:\/\/schemas.microsoft.com\/developer\/msbuild\/2003'<\/span>><\/span>\n  <Target<\/span> Name<\/span>='PrintBuildInfo'<\/span> BeforeTargets<\/span>='Build'<\/span>><\/span>\n    <Message<\/span> Text<\/span>='Building $(MSBuildProjectName) in $(Configuration)'<\/span>\n             Importance<\/span>='high'<\/span> \/><\/span>\n  <\/Target<\/span>><\/span>\n<\/Project<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
Example: .tasks<\/code> include containing task registrations.<\/p>\n\n\n
<Project<\/span> xmlns<\/span>='http:\/\/schemas.microsoft.com\/developer\/msbuild\/2003'<\/span>><\/span>\n  <UsingTask<\/span> TaskName<\/span>='Company.Build.ZipDirectory'<\/span>\n             AssemblyFile<\/span>='tools\/Company.Build.Tasks.dll'<\/span> \/><\/span>\n<\/Project<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
Common commands:<\/p>\n\n\n
msbuild build.proj \/t:Build \/p:Configuration=Release\ndotnet build src\/MyApp\/MyApp.csproj -c Release<\/code><\/span><\/pre>\n\n\n
About the .settings.targets convention<\/h2>\n\n\n\n
.settings.targets<\/code> is a naming convention, not a special parser rule in MSBuild. In the original post, it is attributed to Sayed Ibrahim Hashimi (2009) as a way to centralize shared utility and deployment-related properties.<\/p>\n\n\n\n
Best practices<\/h2>\n\n\n\n
  • Keep .proj<\/code> files focused on orchestration, not deep reusable logic.<\/li>
  • Put reusable defaults in .props<\/code> and reusable build actions in .targets<\/code>.<\/li>
  • Use .tasks<\/code> (or equivalent imported files) to isolate custom task registration.<\/li>
  • Standardize naming so teams can quickly identify purpose from filename alone.<\/li>
  • Document import order explicitly, because MSBuild behavior is strongly order-dependent.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"
    Understand what common MSBuild-related file extensions do and how they fit together in real .NET build pipelines. This revised guide includes a comparison table, import-flow diagram, and practical XML examples.<\/p>\n","protected":false},"author":1,"featured_media":3184,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[51],"tags":[1235,1240,1241,1239,1234,1237,1238,366,1242,1236],"class_list":["post-478","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-msbuild","tag-dotnet","tag-dotnet-and-msbuild-projects-extension","tag-dotnet-extension","tag-dotnet-msbuild","tag-extension","tag-extension-used-in-dotnet-projects","tag-extension-used-in-msbuild-projects","tag-msbuild","tag-msbuild-extension","tag-projects"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/478","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=478"}],"version-history":[{"count":4,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/478\/revisions"}],"predecessor-version":[{"id":79361,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/478\/revisions\/79361"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/3184"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=478"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=478"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=478"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}