Directory.Build.props

<Project>

    <PropertyGroup>
        <Product>NeonKUBE</Product>
        <Authors>NEONFORGE Team</Authors>
        <Company>NEONFORGE LLC</Company>
        <Copyright>Copyright © 2005-2024 by NEONFORGE LLC.  All rights reserved.</Copyright>
        <PackageReadmeFile Condition="Exists('README.md')">README.md</PackageReadmeFile>
        <GenerateDocumentationFile>true</GenerateDocumentationFile>
        <LangVersion>latest</LangVersion>
        <Deterministic>true</Deterministic>
        <DeterministicSourcePaths>false</DeterministicSourcePaths>
        <Nullable>disable</Nullable>
        <ImplicitUsings>disable</ImplicitUsings>
        <EnableNETAnalyzers>true</EnableNETAnalyzers>
        <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
        <PackageRequireLicenseAcceptance>true</PackageRequireLicenseAcceptance>
        <TreatWarningsAsErrors>false</TreatWarningsAsErrors>
        <NoWarn>1701;1702;NETSDK1138;CS8892;ASP0014;IDE0063;IDE0090;IDE0017;IDE0079;IDE0066;NU1605;MSB3026;MSB3061;IDE0055</NoWarn>

        <!--
        Specifies the NeonSDK nuget package versions to be referenced
        by solution projects when we're building with nugets as opposed to using
        binaries generated by the the NeonCLOUD multi-solution build.
        -->
        
        <NeonSdkPackageVersion>0</NeonSdkPackageVersion>

        <!-- Debugging -->

        <DebugType>embedded</DebugType>
        <DebugSymbols>true</DebugSymbols>
        <PublishRepositoryUrl>true</PublishRepositoryUrl>
        <EmbedUntrackedSources>true</EmbedUntrackedSources>

        <!-- 
        Our nuget publication scripts will set the environment variable [NEON_PUBLIC_SOURCELINK=true]
        when the source code has been or will be commited to GitHub with the expectation that we'll
        enable sourcelink to reference source code from our GitHub repos.
        -->

        <ContinuousIntegrationBuild Condition="'$(NEON_PUBLIC_SOURCELINK)' == 'true'">true</ContinuousIntegrationBuild>

        <!-- Publish defaults -->

        <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>

        <!-- $hack(jefflill): Looks like the Operator SDK analyzers are holding DLLs open? -->

        <CopyRetryCount>200</CopyRetryCount>
        <CopyRetryDelayMilliseconds>10</CopyRetryDelayMilliseconds>

    </PropertyGroup>

	<PropertyGroup Label="Dotnet versions">
		<DotNet6Version>6.0.*</DotNet6Version>
		<DotNet7Version>7.0.*</DotNet7Version>
		<DotNet8Version>8.0.*</DotNet8Version>
		<DotNet9Version>9.0.0-*</DotNet9Version>
	</PropertyGroup>

    <!--
    Set this to version of the NeonSDK nuget packages to be referenced by solutuon projects,
    or to 0 to disable NEONFORGE related package references.
    -->

    <PropertyGroup Condition="'$(NeonSdkPackageVersion)' == ''">
        <NeonSdkPackageVersion>0</NeonSdkPackageVersion>
    </PropertyGroup>

    <!-- Build configuration related settings -->

    <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
        <DefineConstants>$(DefineConstants);TRACE;DEBUG</DefineConstants>
        <Optimize>false</Optimize>
    </PropertyGroup>

    <PropertyGroup Condition="'$(Configuration)' == 'Release'">
        <Optimize>true</Optimize>
    </PropertyGroup>

    <!-- 
    We have a somewhat complex build environment.  The NeonCLOUD repo is private and
    our solution there actually includes references to all NeonSDK and NeonKUBE projects
    so we can build everything at once in the NeonCLOUD solution without having the mess
    with publishing private nuget packages like we used to do (and really slowed down the
    inner developer loop).
    
    This is nice for maintainers, but non-maintainers will also need to be able to 
    build NeonKUBE normally, where NeonKUBE projects reference NeonSDK nuget packages.
    
    We handle both the maintainer and non-maintainer scenarios by munging our NeonCLOUD and
    NeonKUBE [.csproj] files so they can reference either nuget packages from other repos
    or reference projects from the other repos via relative project file path references.
    
    We're going to use the NEON_BUILD_USE_NUGETS environment variable to manage this.  This
    will be missing, blank, or "false" when the builds should use nuget package references
    or "true" to use the relative project references.
    
    We also need to handle another important scenario: the [neonkube-builder.ps1] and
    [neoncloud-builder.ps1] scripts will need to be able to control whether we're 
    using nuget references or not and eventually be able configure projects to reference
    specific nuget versions for NeonSDK and NeonKUBE nugets.

    This is tricky because MSBUILD doesn't initialize the $(SolutionName) variable.
    We're going to handle this by having these scripts pass a custom $(NeonSolutionName)
    property on the MSBUILD command line.  The property group below will 

    IMPORTANT: You'll need to define the solution name property within any scripts
               building the solution or a specific project, like:

        dotnet build -p:SolutionName=SOLUTION-NAME ...
        msbuild -p:SolutionName=SOLUTION-NAME ...
    -->

    <Choose>
        <When Condition="'$(NEON_BUILD_USE_NUGETS)' == 'true'">
            <PropertyGroup>
                <NeonBuildUseNugets>true</NeonBuildUseNugets>
            </PropertyGroup>
        </When>
        <Otherwise>
            <PropertyGroup>
                <NeonBuildUseNugets>false</NeonBuildUseNugets>
            </PropertyGroup>
        </Otherwise>
    </Choose>

    <!--
    Set the nuget package version to non-existent version "0" to ensure that we're
    not referencing nugets when we're not supposed to be building with nugets.
    -->

    <PropertyGroup Condition="'$(NeonBuildUseNugets)' != 'true'">
        <NeonSdkPackageVersion>0</NeonSdkPackageVersion>
    </PropertyGroup>

    <!-- Telerik JustMock settings -->

    <PropertyGroup Condition="'$(JUSTMOCK_ENABLED)' == 'true'">
        <DefineConstants>$(DefineConstants);JUSTMOCK</DefineConstants>
    </PropertyGroup>

    <ItemGroup Condition="Exists('README.md')">
        <None Include="README.md" Pack="true" PackagePath="" />
    </ItemGroup>

    <!--
    These constants are used to control the retry behavior of the MSBUILD
    <Copy.../> tasks.  This helps mitigate transient issues when files may
    be locked during Visual background operations.
    -->

    <PropertyGroup>
        <CopyRetries>10</CopyRetries>
        <CopyRetryDelayMilliseconds>50</CopyRetryDelayMilliseconds>
    </PropertyGroup>

    <!-- $hack(jefflill):
    
    We've had a lot of trouble with auto generated source files for:
    
        * GitInfo
        * AssemblyInfoAttribute
        * TargetFrameworkAttribute
        
    The problem is that these are all generated in [obj/CONFIGURATION] or
    [obj/CONFIGURATION/TARGETFRAMEWORK] but the build system compiles all
    C# files it sees under the project directory, and it's very easy to 
    end up with multiple source files defining the same classes.
    
    We tried precleaning these files early in the build, but that didn't 
    work because we may end up building multiple build targets for the
    same project in parallel and it also prevented us from publishing
    nuget packages via scripts because we're typically running Visual
    Studio in the DEBUG build configuration but publishing as RELEASE.
    
    We also tried messing with the source input globbing rules, but
    that didn't work either.
    
    So here's what we're going to do:
    
        * Create a local [BuildInfo] library that has only one
          build configuration and target framework.
            
        * Have [BuildInfo] reference the GitInfo nuget package
          and then write a drop-in replacement for the [ThisAssembly]
          class that returns the values from the local GitInfo generated
          class.
            
        * Disable generation of the [AssemblyInfoAttribute] and 
          [TargetFrameworkAttribute] classes for all projects.
            
        * Manually add [AssemblyInfo.cs] and [AssemblyAttributes.cs]
          classes to [BuildInfo] and reference these from other projects as
          shared links.  This code will include #IFDEFs to compile the correct
          code for the the current target framework, etc.
    -->

    <PropertyGroup>
        <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
        <GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>
    </PropertyGroup>

    <!-- Figure out where the [neon-modelgen] tool is located -->

    <Choose>
        <When Condition="'$(NeonBuildUseNugets)' == 'true'">
            <PropertyGroup>
                <ModelGeneratorPath>$(PkgNeon_ModelGenerator)\contentFiles\any\netstandard2.0\$(RuntimePath)\neon-modelgen</ModelGeneratorPath>
            </PropertyGroup>
        </When>
        <Otherwise>
            <PropertyGroup>
                <ModelGeneratorPath>$(NF_ROOT)\Tools\neon-modelgen\bin\$(Configuration)\net8.0\win-x64\neon-modelgen</ModelGeneratorPath>
            </PropertyGroup>
        </Otherwise>
    </Choose>

    <!-- Build breaks for some reason without this, since the .NET 8.0 upgrade -->

    <ItemGroup Condition="'$(TargetFramework)' == 'net6.0'">
        <PackageReference Include="Microsoft.Bcl.AsyncInterfaces" Version="6.0.0" />
    </ItemGroup>

    <ItemGroup Condition="'$(TargetFramework)' == 'net7.0'">
        <PackageReference Include="Microsoft.Bcl.AsyncInterfaces" Version="7.0.0" />
    </ItemGroup>

</Project>