Merge core libraries.

[grokys]

What does the pull request do?

We have too much separation of concerns in the Avalonia assembly layout, which has caused (and is causing) various problems with developing Avalonia. Some examples:

• Hard to write features which animate classes in the Avalonia.Visuals assembly as that assembly was lower than Avalonia.Animation
• Impossible to unify VisualChildren and LogicalChildren into a single collection as they're defined in different assemblies

This PR merges all assemblies below (but not including) Avalonia.Controls into Avalonia.Base.

Open questions:

• Should we also put Avalonia.Markup in there?
• Should we also put the base control classes (Control, TemplatedControl) in there (moving the actual controls to e.g. Avalonia.Controls.Standard maybe?)

Breaking changes

Pretty big ABI breaking change: a lot of classes have moved and assemblies have been deleted.

[robloo]

My two cents:

Should we also put Avalonia.Markup in there?

Markup makes sense to keep separate IMO. It's entirely possible within 10 years this layer needs to change independently anyway.

Should we also put the base control classes (Control, TemplatedControl) in there (moving the actual controls to e.g. Avalonia.Controls.Standard maybe?)

It seems to make sense to move base classes into the unified base project. Then these base classes would be available from all 'controls' projects. However, I wouldn't then call the controls project Avalonia.Controls.Standard it should remain Avalonia.Controls as the standard part is strongly implied. Any additional controls packages would then be Avalonia.Conrols.WinUI etc.

[maxkatz6]

Another question, do we have plans to change nuget packages? Right now we have couple of dlls merged into one "Avalonia" package. Do we want to drop that merging tool and publish simplified nuget packages?

[rstm-sf]

Hi, what is the status of this PR and in what order will it be merged?

[maxkatz6]

@rstm-sf it was planned to be merged when we will be ready to with doing 0.11.0 branch with breaking changes instead of backporting everything to 0.10.x.

[robloo]

Will this make Avalonia.Base internal members visible to Avalonia.Controls? Access to things such as KnownColors isn't possible otherwise. Internals need to be made available IMO. I already have found a few places it's needed/useful and haven't done much in the code base.

[robloo]

I see lots of potential issues with a massive commit like this.

First, is there any way you can do it project-by-project first rather than all at once?

Secondly, this change should be done immediately or it's just going to get worse. I would also notify all developers of a hard-stop in submitting PRs until this is done.

Third, all existing PRs are going to need to be re-done. (This is a good reason why the PRs list shouldn't be allowed to get so long)

[grokys]

Ok, this should be ready to go. Will be merged shortly.

[grokys]

I see lots of potential issues with a massive commit like this.

Definitely, which is why we've been holding off - it's potentially going to make backporting fixes a lot more difficult.

First, is there any way you can do it project-by-project first rather than all at once?

I'm not sure that would make it any less painful. The plan is to merge this as a squashed commit so that the painful changes are all in one place.

Secondly, this change should be done immediately or it's just going to get worse. I would also notify all developers of a hard-stop in submitting PRs until this is done.

Like I say, we've been holding off until towards the end of the end of the 0.10 maintenance period, but now we're coming up to 11.0 we're ready to merge it.

Third, all existing PRs are going to need to be re-done. (This is a good reason why the PRs list shouldn't be allowed to get so long)

Possibly, yes, though git does cope surprisingly well with these types of moves.

Will this make Avalonia.Base internal members visible to Avalonia.Controls? Access to things such as KnownColors isn't possible otherwise. Internals need to be made available IMO. I already have found a few places it's needed/useful and haven't done much in the code base.

Avalonia.Base's internals are made visible to Avalonia.Controls, yes.

[grokys]

This PR currently disables ApiCompat. This is because even though git handles merges with file moves pretty well, it does not handle changes to ApiCompatBaseline.txt well, and these files are going to be the main cause of merge conflicts after this change.

Should we leave this disabled until 11.0 (because breaking changes are expected at this point)?

[robloo]

Well, the only issue I can think is its harder to make a breaking change summary for the release.

[avaloniaui-team]

You can test this PR using the following package version. 0.10.999-cibuild0019913-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

[MarchingCube]

Let's get this merged!

[grokys]

Anyone: if you're annoyed that your PR now has merge conflicts, ping me and I'll fix it ;)

[Mrxx99]

I think this does not have to be a breaking change when using the TypeForwardedTo Attribute, which is used very often in dotnet runtime itself for exactly that purpose