Updated version numbers to 10.0.0-pre01. + net 10

[DocSvartz]

No description provided.

[DocSvartz]

@andrerav @stagep @DevTKSS If #622 is relevant?
First step, need to retarget mapster.core and mapster.sourceGenerator to netstandard2.0 and do not change the TFM for these solutions.

[DevTKSS]

@DocSvartz added comment on the issue.

Side Note for you: if you link to an issue or PR or similar, did you know that when your current line is a list (-) github will not just link it like you see it now, then show it with:

• Status of the linked item (open/closed)
• Title of the issue

I myself favorite to use this, since I get to know this. Perfectly suitable for e.g. "EPIC" Issue lists that are meant to collect multiple issues as links with status on one place. For example:

• Source Generators with IMapper Interface #622

[DocSvartz]

@DevTKSS It was more of a short explanation of why two files had different changes than the others and that this is not a misprint. :)

[DocSvartz]

@andrerav @stagep @DevTKSS
Regarding features, this is already a release, I don't plan to add anything.

The only thing I'm thinking about is moving the temporary configuration work into a separate project Mapster.Experemental Mapster.Experimental:

• Add Adapt extensions with temporary TypeAdapterConfig and TypeAdapter… #828
• Add an overload to the Adapt method to allow using a local, temporary configuration. #833

It will be able to accept new features as candidates for the main Mapster project. Let me know if this is a good idea. :)

In relation to:

• Mapster.Fluent
• Source Generators with IMapper Interface #622

I wanted to combine the work on these two projects (both would involve changes to the API configuration).
But so far, it's not working out very well.
It will likely be two steps with two API configuration changes. 😒

[stagep]

@docs FYI Experimental is the correct spelling :)

[DocSvartz]

@stagep yes.
I decided to brush up on how Mapster works again. And it seems I've gone crazy again.🤣 🤪

[DevTKSS]

@DocSvartz @andrerav Is there a specific reason to use a LangVersion in here?

[DevTKSS]

@DocSvartz @andrerav Seeing all the repeating of Properties here I would like to suggest to:

• use Directory.Packages.props -> introduce CPM

  • only one place we need to update
  • Configurable along with the Variables of Directory.Build.props if you want to ensure to use specific versions of packages for projects like Source Generators or Test Projects (which by the way are missing the common IsTestProject Tag, which I added as suggestion to this PR directly)

• use Directory.Build.props

  • Define NuGet Package Information Centrally - e.g. I found this here and copied it to my own Repo + adjusted the Properties (Name, License etc.) I dont use it by now, so adding some other references:

    • First Example
    • Second Example

  • source regular Project Props we need repentantly using Variables for example:

    • Directory.Build.props

      <Project>
        <PropertyGroup>
          <ImplicitUsings>enable</ImplicitUsings>
          <Nullable>enable</Nullable>
          <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
          <DefaultTargetFrameworks>net10.0;net9.0;net8.0</DefaultTargetFrameworks>
          <Authors>Some Name;Some OtherName</Authors>
        </PropertyGroup>
      </Project>

    • Regular *.csproj

      <Project Sdk="Microsoft.NET.Sdk">
         <PropertyGroup>
           <TargetFrameworks>$(DefaultTargetFrameworks)</TargetFrameworks>
           <RootNamespace>Mapster</RootNamespace>
           <AssemblyName>Mapster</AssemblyName>
           <Authors>$(Authors)</Authors>
           <OutputType>Library</OutputType>
         </PropertyGroup>
       </Project>

• Update the Authors Entries?

  Never seen those Names recently and @andrerav mentioned in the discussion, he is the only Maintainer except from @DocSvartz and @stagep (potentially missed one 😄 but you get what I mean hopefully) which I did not see in one of those Lists.

[DocSvartz]

@DevTKSS

use Directory.Packages.props -> introduce CPM

This already exists.
But there are a number of problems with this:

1. It just doesn't seem to work due to some properties being overridden in the projects themselves.
2. If auto-generation is used (benchmark projects), such projects may not build, at least in IDE. Because projects require a signature.

IsTestProject

I've seen issue in NUnit that in certain CI/CD pipelines, tests don't run without it. But tests work for us. Now I'm wondering if the tests will run twice.
@DevTKSS Have you seen any problems associated with this?🤔😅

[DocSvartz]

@DevTKSS
It's strange that after adding <IsTestProject>true</IsTestProject>, the tests passed, but the build failed.
Try add the Suggested again, but only to one file.

-- Update
Suggested not build
Perhaps some protection against third-party commits is configured in PR 🤔
If I add it myself, the build passes.

[DevTKSS]

@DocSvartz I did only run tests locally so far and not had to work with signing 🤔 and I am using xUnit v3 for testing which has support for many CI CD testing setups with predelivered worflows/samples

[DocSvartz]

@DevTKSS If this is important, please move these to separate issues:

• Updated version numbers to 10.0.0-pre01. + net 10 #841 (comment)
• Updated version numbers to 10.0.0-pre01. + net 10 #841 (comment)

This is not entirely related to the version number change and the addition of a new TFM. Moreover, this issues can be resolved independently.