Update build project to .net 8

[Romfos]

changes:

• Update build project to .NET 8

note: no changes in product, no need to release new nuget package

[alexandrnikitin]

Let's also bump the framework in our generate project that tests code from the docs

Actually let's keep it as is because we ship for net6.0 version.

[Romfos]

Yea, in general, we have 2 options:

1. use minimal supported versions in documentation as examples
2. use the latest version in documentation as examples

both are possible

[Romfos]

about build.fxproj project:

This is very strange project, as for me, with following targets:

    Target.create "-T" <| fun _ ->
        printfn "Optional config options:"
        printfn "  configuration=Debug|Release"
        printfn "  benchmark=*|<benchmark name>  (only for Benchmarks target in Release mode)"
        printfn ""
        Target.listAvailable()

    "Clean" ?=> "Build"             |> ignore
    "Clean" ?=> "Test"              |> ignore
    "Clean" ?=> "Restore"           |> ignore
    "Clean" ?=> "Documentation"     |> ignore
    "Clean" ?=> "TestCodeFromDocs"  |> ignore
    "Clean" ?=> "Package"           |> ignore
    "Clean" ?=> "Default"           |> ignore

    "Build"         <== [ "Restore" ]
    "Test"          <== [ "Build" ]
    "Documentation" <== [ "TestCodeFromDocs" ]
    "Benchmarks"    <== [ "Build" ]
    // For packaging, use a clean build and make sure all tests (inc. docs) pass.
    "Package"       <== [ "Clean"; "Build"; "Test"; "TestCodeFromDocs" ]

    "Default"       <== [ "Restore"; "Build"; "Test" ]
    "All"           <== [ "Clean"; "Default"; "Documentation"; "Package" ]

actually I would recommend don't reinvent the wheel and use standard dotnet cli commands:

1. dotent restore for restore
2. dotent build for build
3. dotent test for testing
4. dotnet pack for packaging

single value from this project, from my point of view, is documentation verification

make sense to remove it and create project for documentation verification in main solution but it will require to make changes in nuget package release CI, that is not on github as i see

[alexandrnikitin]

@Romfos I'm sorry for the late response. I agree with your last message. I also prefer to use dotnet CLI tool for those. It didn't exist when we used FAKE for our build.

Now regarding the PR, I tend to think that it's better to keep the TargetFramework as is (net6.0) because it's the version we release and it needs to be present in the system anyway. I'm sorry I stopped working with .NET and may not see benefits of upgrading. Please convince me otherwise.

[Romfos]

@Romfos I'm sorry for the late response. I agree with your last message. I also prefer to use dotnet CLI tool for those. It didn't exist when we used FAKE for our build.

Now regarding the PR, I tend to think that it's better to keep the TargetFramework as is (net6.0) because it's the version we release and it needs to be present in the system anyway. I'm sorry I stopped working with .NET and may not see benefits of upgrading. Please convince me otherwise.

I have following logic:

1. This build project has dependency conflicts:
2. When I started investigate - update nuget packages is the easiest way to fix it
3. New nuget packages target .NET 8 and then I decided update build project to .NET 8

In any case it will be updated today or tomorrow. I will not affect target framework for package

[Romfos]

hm, looks like github actions no longer build for PR's in this repo. Is it expected?

[alexandrnikitin]

hm, looks like github actions no longer build for PR's in this repo. Is it expected?

It is expected. It was set to "Require approval" for all fork PRs. I think for security reasons but we don't store any secrets in GH actions. I set it back to "Require approval for first-time contributors". It should build now.