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...
_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.
- MSBuild reads your project, imports everything, creates Properties, expands globs for Items outside of Targets, and sets up the build process.
- 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|
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
Foo.resx will get passed to a few tasks in different forms throughout the build.