benvillalobos

[5/21 4:03 PM] David Kean The format is; [Identifier], Version=v[Version], Profile=[Profile] where profile is optional.

Valid identifier values off the top my head:

Silverlight

CompactFX

.NETFramework

benvillalobos

<UsingTask TaskName="Foo.Bar" TaskFactory="RoslynCodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll">
    <ParameterGroup>
      <AnnotatedProjects ParameterType="Microsoft.Build.Framework.ITaskItem[]" Required="true" />
      <ParentProjectPlatform ParameterType="System.String" Required="true" />
      <PlatformLookupTable ParameterType="System.String" Required="false" />
      <AssignedProjectsWithPlatform ParameterType="Microsoft.Build.Framework.ITaskItem[]" Output="true" />
    </ParameterGroup>
    <Task>
 

benvillalobos

Turning chars into its integer hex representation: https://github.com/dotnet/msbuild/pull/6227/commits/abdbd9f0eef87c0904166900617fa378b636ec60
More insight on how MSBuild logging works: https://github.com/dotnet/msbuild/pull/6326
Comment explaining default excludes in sdk-style projects: https://github.com/dotnet/msbuild/issues/6899#issuecomment-932462170

benvillalobos

The Output Dll (regular builds)

$(TargetPath) The full path to the main dll $(TargetFileName) (TargetPath without the path) `$()

The Output Exe (apphost)

$(TargetDir)$(AssemblyName)$(_NativeExecutableExtension) is the canonical construction of the shipping executable. Verified this in a build using /p: SelfContained=true. Crtl+f through SDK targets for <RunCommand, which was suggested to me as the canonical way the SDK constructs it.

benvillalobos

Say you want to modify each project reference once you know what platforms it can build as, the only place to do it (before PlatformNegotiation kicks in) is...

BeforeTargets=_GetProjectReferencePlatformProperties AfterTargets=_GetProjectReferenceTargetFrameworkProperties

_GetProjectReferenceTargetFrameworkProperties is the target that calls MSBuild on a project reference to gather its information (and see what it would build as). Only AFTER this target you can mess with ProjectReferences while understanding what they can build as.

If you target runs between the two above, you should have an _MSBuildProjectReferenceExistent item you can mess around with.

benvillalobos

Debugging An MSBuild Build

MSBuild is open-source, which means you should be able to step through the execution of a build by following these steps.

Sync Up With Your Installed MSBuild

1. Developer Command Prompt: msbuild --version You should see something like MSBuild version 17.3.1+362d18ee6 for .NET Framework
   • Everything after the + is the hash. Copy that
2. git clone https://github.com/dotnet/msbuild
3. git checkout 362d18ee6
4. VS -> MSBuild.Dev.slnf
5. VS -> Tools -> Options -> Disable Just My Code

benvillalobos

Stop MSBuild From Locking Files

Stop MSBuild from locking your files! Also, consider that the problem could be MSBuild or something your build is doing.

Note: Use Visual Studio Developer Command Prompt.

In Visual Studio

1. set MSBUILDDISABLENODEREUSE=1
2. devenv yourproject.csproj

In CLI

benvillalobos

Custom MSBuild Task Can't Find System.Memory?

Why is this happening?

Your task is probably on .NET Core, meanwhile you're building with the net472-targeted MSBuild.exe. To fix this: either switch from using MSBuild.exe to using dotnet build, or change the TargetFramework of your task.

The long answer

Workarounds

• Set the TargetFramework property in your task's project to net472.

benvillalobos

Debugging Node Communication in MSBuild

To capture logs of how MSBuild nodes talk to each other:

1. Set MSBUILDDEBUGCOMM=1
2. Set MSBUILDDEBUGPATH=<some_folder_path>
3. Run your scenario
4. The node communication traces should exist in the folder you specified.

benvillalobos

Spelunking Through Binlogs

This stuff ain't easy, so here's a WIP "get you up to speed" doc.

Setup

• Install the MSBuild Log Viewer or use the online viewer.

• File->Start Page, make sure this box is checked