[build] Stop producing Xamarin.Android.Cecil.dll

[pjcollins]

Fixes: #3132
Context: https://github.com/xamarin/monodroid/commit/b9349491a141b5265e3d48eec9af589c8c5cc793

The Xamarin.Android.Cecil.dll assembly was created to to avoid potential
conflicts and versioning issues with the copy of Cecil that Xamarin
Studio was using at the time. Considering our migration to .NET, and
how infrequently we change our Mono.Cecil reference these days, these
potential issues are likely no longer a concern.

Our unique Xamarin.Android.Cecil.dll copy has been removed in favor of
Mono.Cecil package references in all projects that depend on it.

[pjcollins]

Adding the do-not-merge label as we will likely want some more external validation in the IDEs before merging this.

[dellis1972]

@pjcollins the main concern around this was not our extensions, but other third party extensions like that Refectoring one. If they used a Cecil and were loaded first it would break out builds.
It would be useful to see if that is still an issue. It might not be.

@tondat any thoughts on this?

[jonathanpeppers]

My first concern was that MAUI ships Mono.Cecil, will we conflict?

So, I downloaded the package and inspected it: https://www.nuget.org/packages/Mono.Cecil/0.11.4

It looks to be strong named and appropriately versioned:

So, what may happen is that if MAUI ships Mono.Cecil, we may use theirs or vice-versa if the version & strong name key match. Although, it will likely "just work" if the version is identical.

I don't think there is a problem here -- it should work.

[dellis1972]

The problem used to be with VS extensions. It was never with other products like iOS etc.

[jonathanpeppers]

.NET framework should know how to respect strong named + versioned assemblies and load new instances of them.

VS Mac would have had an issue on Mono, but I believe it will be out of support and never be able to build .NET 9 projects. VS Mac also made it to .NET 6, in its latest version?

[jpobst]

Agreed that this feels like it could potentially conflict with other copies of Mono.Cecil.dll loaded into the VSWin process.

But it also feels like strong naming should protect us from that? Unless someone else makes local changes to their copy and doesn't change the version number?

[jpobst]

Related: #3132

[pjcollins]

I spent some time testing in a Windows VM today and had no issues with some somewhat trivial build, deploy, debug, and hot reload scenarios with Android and MAUI apps using a VS 17.9 preview and WSA. I think we should be able to merge this, but am wondering if it makes sense to wait for the .NET 9 PR to land first @jonathanpeppers ?

[jonathanpeppers]

I don't think we should wait on the .NET 9 PR to merge this.

It might be better to merge sooner than later, to find out if find any possible issue loading different Mono.Cecil.dll files.

[jonpryor]

@pjcollins: please also try removing $(CecilSourceDirectory): https://github.com/xamarin/xamarin-android/blob/d4e92108cad94e9714b3c764981f806efe2ff986/build-tools/scripts/Configuration.Java.Interop.Override.in.props#L5

$(CecilSourceDirectory) is used in Java.Interop to get the Java.Interop builds to use Xamarin.Android.Cecil.dll:

• https://github.com/xamarin/java.interop/blob/320636df084d377e1fdabef6fa6d28feb9ede6f2/TargetFrameworkDependentValues.props#L16
• https://github.com/xamarin/java.interop/blob/320636df084d377e1fdabef6fa6d28feb9ede6f2/build-tools/scripts/cecil.projitems#L9-L11

It doesn't look like removing $(CecilSourceDirectory) is required -- the Exists() check in TargetFrameworkDependentValues.targets will work properly if it's set and Xamarin.Android.Cecil.dll doesn't exist -- but I think it would be useful cleanup.