Want to Help? (Looking for Maintainers)

[christophwille]

The AvaloniaILSpy project was started by @jeffreye in his own GH in August 2018, and later transferred to the ic#code organization. As happens in open source (an example from close to home being icsharpcode/SharpZipLib#187) maintainers might no longer have time to support the project. This has now happened to AvaloniaILSpy, and we are looking for new maintainers.

As you can read in the SharpZipLib post, this means being the custodian of the project (dealing with issues and PRs from others), with a few notable differences in contrast to SharpZipLib: the AvaloniaILSpy app is not an entirely standalone project - it is "tied" to the Windows version of ILSpy, which it shares quite a lot of code with.

@jeffreye pulled out non-Windows code into .Core, rewrote stuff for Avalonia (eg SharpTreeView) - which are copies ILSpy source files. To alleviate this churn, on the ILSpy side we introduced in v8 the "intermediate" xplat library ILSpyX that would eliminate quite a few places of duplication and changes would flow more automatically to AvaloniaILSpy. However, the WPF bits in ILSpy(.csproj) itself will always be a copy/paste operation - or a manual sync for a nicer word, which we (ILSpy) strive to keep to a minimum, but simply cannot avoid.

What is the project looking for in a maintainer? First and foremost someone very familiar with Avalonia. Secondly, someone who is ok with keeping stuff in sync manually (yes, please tell us on the ILSpy side of the house what else we could/should provide in ILSpyX - it was built for alternate frontends just like AvaloniaILSpy). Last but not least: do not underestimate the amount of time an open source project will consume, and be willing to stick to it for a long-ish duration.

[DamianSuess]

I'm willing to assist 👍 ICSharpCode has been a pillar of the C# community and don't want to see your amazing projects fade away. As the maintainer of Prism.Avalonia, I can squeeze in time to help out around here.

[christophwille]

Given that we on the main line are very close to releasing v8.1, a good starting point might be moving the current code base of AvaloniaILSpy to the released version of Avalonia 11. Because after our 8.1, we are very, very likely to go on building out the next major release, which means you'd have months to a year to cherry-pick 8.1 from ILSpy to AvaloniaILSpy and enjoy a long stability. And also be able to provide us with feedback what to move to ILSpyX to make your life easier the next time a version sync is happening.

If that sounds like a plan, how about getting this started with a PR?

[DamianSuess]

@christophwille, spinning up a branch. Oh yea, this is a walk down memory lane for sure upgrading from 0.10 to v11 (didn't say it was 100% joyful).

BTW, I'm tossing in the EditorConfig to maintain code consistency. Check out, PR #129 as a reference

[christophwille]

Yes, I saw your PR after I wrote my reply (was checking up on loose ends).

I can help validating Windows and Mac (Linux - I'd have to spin up VMs, and quite frankly I am not very versed in distributions and UI stacks). Also, I can help with Action workflows, but when it comes to publishing and distributing Mac apps (you will see a couple issues), I am drawing blanks .

[DamianSuess]

Sounds great! On the Linux front, I'm pretty much good to go, as that is my daily test machine. It's the Mac side of the fence that I usually have to tap co-workers on the shoulder. Pretty sure my wife would be annoyed if I bought another laptop 😆

[christophwille]

Moving the "roadmap" from #142 - we want to build a "stopgap" release with

• Create DMG for MacOS x64/arm64 #98 - MacOS deliverables as dmg instead of zip. With the known problems of Cannot run release on Mac #63
• Minimal update to decompilation engine 8.0.0.7345 #142 - basically only taking the 8.0 decompilation engine without the respective UI changes
• Upgrade Avalonia v11 #141 - the Avalonia 11 update
• Triage of PRs and issues to see if anything can be immediately closed by Avalonia upgrade, add low-hanging fruit to release. @DamianSuess that would be your call.

Past that release, take the time to actually fully sync AvaloniaILSpy with ILSpy 8.1. That would mostly mean #127

• Use ILSpyX NuGet instead of ICSharpCode.Decompiler, because of that
• Move everything to net60
• Remove now duplicated code (eg PdbProvider is now part of ILSpyX)
• Sync UI code (note that as far as I am aware, none of the DEBUG user interface was ever copied - and it is OK for that to be the case, the DEBUG affordances are mostly for us working on the decompilation engine). Note that from ILSpy 7 to 8 we moved from netfw472 to net60. That means there could be subtle changes all over the place.

[christophwille]

8.1 is out and you can https://github.com/icsharpcode/ILSpy/tree/v8.1 for syncing.

[maxkatz6]

@christophwille I can complete Avalonia 11.0 upgrade and do some cleanup of the code to fit newer Avalonia version better. And close some old issues as well.
I am not really familiar with ILSpyX to do detailed changes there, but depending on the free time I might take a look at that.

Ideally, I would like to re-port WPF projects to Avalonia from scratch, as there are many places where we made gap between frameworks smaller, and there are also many places where stuff can be ported more efficiently.

[christophwille]

The ILSpyX effort was triggered by AvaloniaILSpy to extract as much as possible from WPF-ILSpy to a common shared library to reduce the code duplication - not only the decompilation engine itself that was factored into a library long ago, but also some higher level functionality that would be useful to share with others. So really you should find a lot 1:1 matches in ILSpyX with existing code.

[christophwille]

@maxkatz6 regarding "re-port" - you really would start from scratch?

[DamianSuess]

Hi @christophwille, sorry I was unable to dedicate the time as anticipated. Last quarter at work became a bit of a rat-race (aka: reduction in staff) and a lot of overtime, leaving little time for OSS projects. If the branch I started for AvaloniaILSpy is still of use, by all means use it. If i can free up some time after hours, I'll try to hop back on it.

[christophwille]

So maybe @maxkatz6 look at the current main vs Damian's in-the-works PR and decide what the best way forward would be (given that you are the person with the most Avalonia experience around here)

[maxkatz6]

@christophwille when I picked up @DamianSuess branch, I noticed there are many parts of the Avalonia related code that could be reverted to the original ILSpy implementation for WPF. Something like https://github.com/icsharpcode/AvaloniaILSpy/blob/master/ILSpy.Core/Images/Images.cs#L324-L348 for example. Or non-SVG images everywhere. Or usage of Style Selectors where ControlTheme with TargetType can be used (which is the closest equivalent to WPF Styles).

For now, I have started with re-porting SharpTreeView control from WPF version, with some changes from @DamianSuess branch. In other words, my strategy was to start with working WPF code and apply Avalonia v11 specific changes on top. Overall, I don't think this project is very big to be afraid of such experiments.

Since I am also busy with daily job, I won't be able to do any changes quickly. But I am interested in trying.

[christophwille]

Glad about all the help we get, especially making this a good Avalonia example.

[christophwille]

@maxkatz6 Got a chance to look at it already?

[maxkatz6]

@christophwille yes, you can find my branch here: https://github.com/maxkatz6/AvaloniaILSpy
Just pushed couple of more commits.

It is partially ported, there is still a lot of relatively simple files to port.
But there are also more complicated cases like Avalon.Dock (can be replaced with https://github.com/wieslawsoltes/Dock), and all the DataGrid especially these that need cell selection (another control - TreeDataGrid - can do it, but would require more changes). In general, dealing with DataGrid might be a lot of work, including replacing DataGridExtensions, but I haven't looked deep into this part.

I also haven't touched most of XAML files yet. Lots of Style can be simply replaced with ControlTheme (new in 11.0), but there are also bigger problems, list CommandBindings everywhere (need AvaloniaUI/Avalonia.Labs#21), toolbar/statusbar needs to be revisited (possibly copy pasted from old port). Also, Dispatcher.UnhandledException requires Avalonia 11.1, on which I was mostly working last month.

I didn't want to make any promises about timelines, but I am slowly pushing it in my free time.

[christophwille]

Hopefully, we didn't do too many strange WPF things that create insurmountable roadblocks. But yes, over the years we accrued a few dependencies like the DataGridExtensions and especially around themeing (which was entirely driven by the community).

[christophwille]

We released P1 with a few changes that relate to porting - https://github.com/icsharpcode/ILSpy/releases/tag/v9.0-preview1 - notably:

• all code related to analyzers that can be used x-plat moved to ILSpyX
• the BAML decompiler was split into x-plat and WPF UI. Turns out only very little code ever was platform-specific
• IFileLoader in Add IFileLoader API ILSpy#3191 - that might impact a few places here and there.

[maxkatz6]

@christophwille thank you. For now, I paused progress on my branch, as it might be better to continue with XPF approach discussed separately.
I am not working on it directly, but helping with what I can.

[christophwille]

I told @MikeCodesDotNET that we have no intention of replacing AvaloniaILSpy with the XPF version of ILSpy simply because AvaloniaILSpy is end-to-end open source whereas the XPF port can't be because of XPF. Also, we talked that it might make for a nice showcase in terms of effort / optionality if the two approaches are demonstrated with an OSS project.

[christophwille]

@maxkatz6 will you pick up your branch again?

[maxkatz6]

@christophwille yes, I will try to get it at least buildable this month.

But in general, once we have XPF version, I don't see too many reasons for Avalonia version. It would be interesting to compare in a long run though.

Primarily because, to get an efficient Avalonia implementation, including proper support for browser without hacks, it would require much more changed including core project. Mass migration to async APIs everywhere (especially file IO), using sandbox aware APIs, avoiding threading (possibly, conditionally), and more. Doing so would result in a better size and performance efficiency in Avalonia version, comparing to XPF or even WPF. Additionally, replacing some older controls with new one also might help.

[christophwille]

@maxkatz6 if you have / keep a list of things that should change in ILSpy please do let us know. We'd be happy to improve our codebase as we have done already based on Jumar's input.

[christophwille]

@maxkatz6 with respect to improving our story for xplat - icsharpcode/ILSpy#3240 assuming this would allow us to move just about all tree nodes to ILSpyX, would that be a good thing, would our abstractions fly with Avalonia properly?

[maxkatz6]

@christophwille just answered on that thread. Sorry for wait.
It will work with Avalonia using DispatcherFrame to sync-wait on async operations. That's what I was using in my branch so far without rewriting any sync functions to async (keeping it out of scope for now).