Clean-up and finalization of data set support

[dennisdoomen]

fluentassertions/fluentassertions#2002

IMPORTANT

• If the PR touches the public API, the changes have been approved in a separate issue with the "api-approved" label.
• The code complies with the Coding Guidelines for C#.
• The changes are covered by unit tests which follow the Arrange-Act-Assert syntax and the naming conventions such as is used in these tests.
• If the PR changes the public API the changes needs to be included by running AcceptApiChanges.ps1 or AcceptApiChanges.sh.

[dennisdoomen]

@jnyrup completely forgot about the PR. Thanks for the keen eye.

[jnyrup]

This is my final review on the essentials, i.e. the public parts.

[jnyrup]

Is this needed?

<ItemGroup>
  <None Include="InitializeDataSetSupport.cs" >
        <Pack>true</Pack>
      <PackagePath>contentFiles\any\any\</PackagePath>
    </None>
  </ItemGroup>

[dennisdoomen]

Yes, because this .cs is added to the project that uses this package and will allow this package to add the specific implementations of IEquivalencyStep needed for working with DataSet.

[jnyrup]

Isn't that done in FA core via assembly scanning?
I've tried removing this inclusion of InitializeDataSetSupport.cs in the nuget package, creating a nuget package of this project and then referencing that nuget package from a separate solution.
From that other solution I could successfully run When_data_sets_are_identical_equivalence_test_should_succeed.

[dennisdoomen]

1. This package will inject InitializeDataSetSupport.cs to the test project that adds a [AssertionEngineInitializer] to the test project that ensures DataSet support is configured correctly.
2. Before the first assertion happens, the new assembly scanning feature introduced in v7 searches for the [AssertionEngineInitializer] and causes the

Without this, it all depends on when the FluentAssertions.DataSets package is loaded. With all the lazy-loading .NET is doing, this results in a very unpredictable behavior.

[jnyrup]

Roger 👍
So because GetAssemblies only loads at currently loaded assemblies, we might miss FluentAssertions.DataSet.
https://github.com/fluentassertions/fluentassertions/blob/aff3f7829056083c5280f7c0f530df5645d83dc0/Src/FluentAssertions/Common/Services.cs#L83-L88

Then how about adding <Visible>false</Visible> to hide it?

In cases of transitive inclusion, e.g. TestProject -> MiddleProject -> FluentAssertions.DataSet, do you know if this adds InitializeDataSetSupport to TestProject and/or MiddleProject?

[dennisdoomen]

So because GetAssemblies only loads at currently loaded assemblies, we might miss FluentAssertions.DataSet.

Exactly. And GetReferences only gets the assemblies that are needed by the code currently loaded.

Then how about adding false to hide it?

What do you mean? To hide it from the solution explorer when opening FluentAssertions.DataSets

In cases of transitive inclusion, e.g. TestProject -> MiddleProject -> FluentAssertions.DataSet, do you know if this adds InitializeDataSetSupport to TestProject and/or MiddleProject?

It'll be added to MiddleProject

[dennisdoomen]

This is my final review on the essentials, i.e. the public parts.

What does that mean? You don't want to review it again?