Directory.Build.targets

<Project>

	<!--
	  The build logic AOTrino ships lives in AOTrino\build\AOTrino.targets,
	  and it is imported here rather than copied: a consumer gets that file from the package (NuGet imports build\<PackageId>.targets on its own),
	  while the samples reference the project instead, so without this import they would be exercising build logic no consumer ever runs,
	  and the shipped copy would rot unnoticed.
	  What stays in this file is what only makes sense inside this repo.
	-->
	<Import Project="$(MSBuildThisFileDirectory)AOTrino\build\AOTrino.targets" />

	<!--
	  Where DirectN, DirectN.Extensions and WebView2 come from: the published NuGet packages, for every C# project here.
	  Override a version with -p:DirectNAotVersion=... or -p:WebView2AotVersion=... to try a different one.

	  C# projects only. The npm .esproj projects are in this solution too,
	  and handing them a PackageReference makes their JavaScript SDK try to restore packages,
	  and stop with "NU1012: Platform version is not present ... net6.0-none". The .csproj condition keeps them out of it.
	-->
	<PropertyGroup Condition="'$(AOTrinoReferencesDirectN)' != 'false' and '$(MSBuildProjectExtension)' == '.csproj'">
		<DirectNAotVersion Condition="'$(DirectNAotVersion)' == ''">1.6.6</DirectNAotVersion>
		<WebView2AotVersion Condition="'$(WebView2AotVersion)' == ''">1.5.2</WebView2AotVersion>
	</PropertyGroup>

	<ItemGroup Condition="'$(AOTrinoReferencesDirectN)' != 'false' and '$(MSBuildProjectExtension)' == '.csproj'">
		<PackageReference Include="DirectNAot" Version="$(DirectNAotVersion)" />
		<PackageReference Include="DirectNAot.Extensions" Version="$(DirectNAotVersion)" />
		<PackageReference Include="WebView2Aot" Version="$(WebView2AotVersion)" />
	</ItemGroup>

	<!--
	  Default application icon (the brand icon at the repo root) for every executable project, a project can override with its own <ApplicationIcon>.
	  Not in the shipped targets: a consumer's app has its own identity.
	-->
	<PropertyGroup Condition="'$(ApplicationIcon)' == '' and ('$(OutputType)' == 'WinExe' or '$(OutputType)' == 'Exe')">
		<ApplicationIcon>$(MSBuildThisFileDirectory)AOTrino.ico</ApplicationIcon>
	</PropertyGroup>

	<!--
	  Every sample can be published for any of the three architectures (publish.bat does all of them),
	  and this is what makes one restore cover all three: project.assets.json only carries the RIDs the project declares,
	  so without this,
	  publishing win-arm64 fails with NETSDK1047 ("assets file doesn't have a target for ../win-arm64") unless something restored for that exact RID immediately before,
	  which NuGet is free to skip when it decides the restore is up to date.
	  Set here rather than in Directory.Build.props because OutputType isn't known that early,
	  and set rather than defaulted because something upstream already leaves RuntimeIdentifiers as ";win-x64",
	  so a Condition="'$(RuntimeIdentifiers)' == ''" silently never fires and only x64 can be published.

	  Scoped to .csproj,
	  not to OutputType: the npm .esproj projects in this solution report OutputType=exe and TargetFramework=net6.0 (their JavaScript SDK's own defaults),
	  so keying off OutputType handed them three RIDs to restore and Visual Studio stopped with "Your project does not reference '.NETCoreApp,Version=v6.0'".
	  They are not something anyone publishes.
	-->
	<PropertyGroup Condition="'$(MSBuildProjectExtension)' == '.csproj' and ('$(OutputType)' == 'WinExe' or '$(OutputType)' == 'Exe')">
		<RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers>
	</PropertyGroup>

	<!--
	  The shipped targets install a project's front end themselves (AOTrinoNpmInstall).
	  This repo doesn't want that: node_modules is one workspace shared by every npm sample,
	  and installing it per project in parallel collided on the workspace symlinks (EEXIST). AOTrino.Npm.proj does it once instead, see below.
	-->
	<PropertyGroup>
		<AOTrinoNpmInstall>false</AOTrinoNpmInstall>
	</PropertyGroup>

	<!--
	  Replaces the shipped AOTrinoNpmBuild (a plain "npm run build") for this repo only: same target name,
	  defined after the import, so this one wins.

	  The difference is the workspace. The repo-root package.json declares npm workspaces,
	  which link @aotrino/* into node_modules as symlinks: no registry, no publishing, and the front end resolves "@aotrino/client" normally.
	  A consumer has no workspace, it installs the @aotrino/* tarballs like any other dependency,
	  so the shipped target only has to run their own build.

	  node_modules and the @aotrino/* libraries belong to the whole solution, not to one project, so they live in AOTrino.Npm.proj.
	  Calling it through the MSBuild task (rather than a ProjectReference) runs it at exactly this point in the build,
	  and MSBuild still caches the result per project+targets, so with several npm samples building in parallel it executes once.
	  Doing the npm work per-project raced: two installs collided on the workspace symlinks (EEXIST) and two compilers wrote one dist.
	-->
	<Target Name="AOTrinoNpmBuild"
			BeforeTargets="AOTrinoEmbedWebRoot"
			Condition="'$(AOTrinoNpmBuild)' == 'true'">
		<MSBuild Projects="$(MSBuildThisFileDirectory)npm\AOTrino.Npm.proj" Targets="Build" />

		<!-- ...and then only this project's own front end -->
		<Exec Command="npm run build"
			  WorkingDirectory="$(MSBuildProjectDirectory)\$(AOTrinoNpmDir)" />
	</Target>

</Project>