So what practical things might you do with `-getProperty` and `-getTarget`?

Say you have some logic to dynamically set the `Version` during a build. If you wanted to check the version you could build the whole project with `dotnet build` and then find and crack open the resulting .dll... or you could run just the target that computes the version and output the result:
```
dotnet build -getProperty:Version -target:ComputeVersion
```
Alternatively you might want to compile a list of your top-level NuGet dependencies. In this case you can loop over all your .csproj files and run:
```
dotnet build -getItem:PackageReference <path_to_csproj>
```

This is potentially useful in any situation where you want to extract structured information from a build that isn't included in the build output, or you don't want to pay the cost of a full build.

#dotnet #msbuild #csharp

So far we've just used `-getProperty` and `-getItem` to query the "evaluation" phase of MSBuild--basically, the step where MSBuild finds and understands all the inputs to your project's build. To actually *do* anything we need to go a step further and execute one of the build targets:

```
> dotnet build -getItem:Compile -target:Compile
{
"Items": {
"Compile": [
{
"Identity": "Program.cs",
...
},
{
"Identity": "obj\\Debug\\net10.0\\TestConsole.GlobalUsings.g.cs",
...
},
{
"Identity": "obj\\Debug\\net10.0\\.NETCoreApp,Version=v10.0.AssemblyAttributes.cs",
...
},
{
"Identity": "obj\\Debug\\net10.0\\TestConsole.AssemblyInfo.cs",
...
}
]
}
}
```
(Don't get confused by "Compile" appearing twice. We're running the "Compile" *target* and then retrieving the "Compile" *items*; these are two distinct things that just happen to share a name in this example.)

We can see here that in the course of running the target the build created three new "Compile" items to hold the global "usings" and various assembly-level attributes.

#dotnet #msbuild #csharp

What if you want to see the actual code files involved?

```
> dotnet build -getItem:Compile
```

For a new console application this will show a single item:

```
{
"Items": {
"Compile": [
{
"Identity": "Program.cs",
"FullPath": "C:\\Users\\me\\source\\repos\\TestConsole\\TestConsole\\Program.cs",
"RootDir": "C:\\",
"Filename": "Program",
"Extension": ".cs",
"RelativeDir": "",
"Directory": "Users\\me\\source\\repos\\TestConsole\\TestConsole\\",
"RecursiveDir": "",
"ModifiedTime": "2026-06-14 19:57:18.0522787",
"CreatedTime": "2026-06-14 19:57:18.0492830",
"AccessedTime": "2026-06-14 19:57:19.2281805",
"DefiningProjectFullPath": "C:\\Program Files\\dotnet\\sdk\\10.0.204\\Sdks\\Microsoft.NET.Sdk\\targets\\Microsoft.NET.Sdk.DefaultItems.props",
"DefiningProjectDirectory": "C:\\Program Files\\dotnet\\sdk\\10.0.204\\Sdks\\Microsoft.NET.Sdk\\targets\\",
"DefiningProjectName": "Microsoft.NET.Sdk.DefaultItems",
"DefiningProjectExtension": ".props"
}
]
}
}
```

And Program.cs is of course the one file in the project directory.

However, Program.cs is *not* the only C# file that is passed to the compiler when you build!

#dotnet #msbuild #csharp

Similarly, you can get project items with `-getItem`:

```
> dotnet build -getItem:PackageReference
{
"Items": {
"PackageReference": [
{
"Identity": "Errata",
"Version": "0.16.0",
"FullPath": "C:\\Users\\me\\...",
"RootDir": "C:\\",
"Filename": "Errata",
"Extension": "",
"RelativeDir": "",
"Directory": "Users\\me\\...",
"RecursiveDir": "",
"ModifiedTime": "",
"CreatedTime": "",
"AccessedTime": "",
"DefiningProjectFullPath": "C:\\Users\\me\\...\\beta\\beta.csproj",
"DefiningProjectDirectory": "C:\\Users\\me\\...\\beta\\",
"DefiningProjectName": "beta",
"DefiningProjectExtension": ".csproj"
},
{
"Identity": "RadLine",
"Version": "0.10.0",
...
},
{
"Identity": "Spectre.Console",
"Version": "0.55.1",
...
}
]
}
}
```

This gets you all the PackageReference items in your project, including their metadata.

#msbuild #dotnet #csharp