polecat/Directory.Build.props at main · JasperFx/polecat · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
<?xml version="1.0" encoding="utf-8"?>
<Project>
    <PropertyGroup>
        <TargetFrameworks>net9.0;net10.0</TargetFrameworks>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>enable</Nullable>
        <!--
          Kept in step with the released line by hand. This is NOT what decides a package's version:
          publish.yml derives that from the tag name (v5.26.0 -> 5.26.0) and passes it to `dotnet
          pack` as -p:Version, so this property is overridden on every tagged publish and cannot
          make a release wrong. What it does set is the assembly and file version of a LOCAL build,
          and anything reading Assembly.GetName().Version at runtime — including Polecat's own
          EventStoreUsage descriptor, which reports the store's version to CritterWatch.
          It had drifted two releases behind (5.22.0 while 5.24.0 shipped) precisely because nothing
          in the publish path reads it, so a stale value is invisible until someone asks a running
          store what version it is.
        -->
        <Version>5.47.0</Version>
        <LangVersion>latest</LangVersion>
        <Authors>Jeremy D. Miller</Authors>
        <PackageIcon>logo.png</PackageIcon>
        <!--
          nuget.org renders this on the package page, and pack/push warn without it. Set per-project
          rather than repo-wide: each packable project carries its OWN README.md so the three package
          pages describe the three packages, and only projects that actually have one opt in. The
          root README.md is deliberately NOT reused here — it links ./docs/polecat-logo.png
          relatively, and relative paths do not resolve on nuget.org.
        -->
        <PackageReadmeFile Condition="Exists('$(MSBuildProjectDirectory)/README.md')">README.md</PackageReadmeFile>
        <PackageProjectUrl>https://polecat.netlify.app/</PackageProjectUrl>
        <PackageLicenseExpression>MIT</PackageLicenseExpression>
        <NoWarn>1570;1571;1572;1573;1574;1587;1591;1701;1702;1711;1735;0618</NoWarn>
        <RepositoryUrl>https://github.com/JasperFx/polecat</RepositoryUrl>
    </PropertyGroup>

    <!--
      Microsoft Testing Platform. These are repo-wide rather than per-test-project on purpose:
      TestingPlatformDotnetTestSupport changes how `dotnet test` invokes a project, so a solution
      where only some projects answered to MTP would leave `dotnet test polecat.slnx` in a mixed
      mode. They are inert in projects that don't reference xunit.v3.

      UseMicrosoftTestingPlatformRunner makes xunit v3 build its MTP entry point instead of the
      VSTest bridge; TestingPlatformDotnetTestSupport makes `dotnet test` run that executable
      directly rather than going through testhost. Neither Microsoft.NET.Test.Sdk nor
      xunit.runner.visualstudio is referenced anymore.
    -->
    <PropertyGroup>
        <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner>
        <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport>
        <!--
          Without this, a failing test prints only

            error run failed: Tests failed: '.../TestResults/Polecat.Tests_net9.0_x64.log'

          and the test name, assertion and stack trace go to that file. CI never publishes it, so a
          red build would carry no indication of what broke — strictly worse than the VSTest bridge,
          which printed failures inline. This restores that.
        -->
        <TestingPlatformShowTestsFailure>true</TestingPlatformShowTestsFailure>
        <!--
          Every database-backed suite here shares schemas between target frameworks, so running the
          net9.0 and net10.0 suites concurrently makes them drop each other's schemas mid-test. This
          repo has long documented that as unexplained local flakiness on a bare `dotnet test`
          (duplicate-object and deadlock errors that look like real failures); CI never hit it
          because each job names a single framework explicitly. Serializing the frameworks fixes it
          at the source.
        -->
        <TestTfmsInParallel>false</TestTfmsInParallel>
    </PropertyGroup>

    <ItemGroup>
        <None Include="$(MSBuildThisFileDirectory)logo.png" Pack="true" PackagePath="" Visible="false" />
        <None Include="$(MSBuildProjectDirectory)/README.md" Pack="true" PackagePath="" Visible="false"
              Condition="Exists('$(MSBuildProjectDirectory)/README.md')" />
    </ItemGroup>
</Project>