Ben Villalobos 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.
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.
Including Generated Files Into Your Build
In any given build, files that get generated during the build behave differently from static files (eg. source files). For this reason, it's important to understand How MSBuild Builds Projects. I'll cover the main two phases here at a high level.
Evaluation Phase
- MSBuild reads your project, imports everything, creates Properties, expands globs for Items outside of Targets, and sets up the build process.
Execution Phase
- MSBuild runs Targets & Tasks with the provided Properties & Items in order to perform the build.
Key Takeaway: Files generated during execution don't exist during evaluation, therefore they aren't included in the build process.
<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>
| 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 |
Debugging Node Communication in MSBuild
To capture logs of how MSBuild nodes talk to each other:
- Set
MSBUILDDEBUGCOMM=1 - Set
MSBUILDDEBUGPATH=<some_folder_path> - Run your scenario
- The node communication traces should exist in the folder you specified.
[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
Manifest Resource Names and You!
For explicit information on how resource names are chosen, see this dotnet docs issue.
This gist is meant to be a slightly higher level explanation on how resource names are used. Mostly I'm just documenting as much context as possible before I forget.
So we start with some Foo.resx
That Foo.resx will get passed to a few tasks in different forms throughout the build.