You are thinking about this in reverse I think. Any long running tasks or actions can report using IProgress.

However, the ProgressBar itself isn't a long running action. It is just a representation of progress and doesn't have any values of its own. It isn't doing any work, only displaying other work.

So ProgressBar can consume IProgress information. However, it doesn't report it itself, it needs to come from a lower layer.

If you application is pulling progress back out of a ProgressBar and using it elsewhere you have something designed wrong. There should be a common task in a lower layer that all code can consume progress information for. One of the consumers being the ProgressBar.

@robloo the IProgress is to be implemented in the controls displaying it, and consumed by the tasks.

the pseudocode would look like this:

View:

class ProgressBar : IProgress<int>
{
   // update the progress value of the progress bar
   public void Report(int value) { this.Value = value; }
}

MVVM

class SomeMVVM
{
   public async Task DoSomeExpensiveJob(IProgress<int> progressFeedback)
   {
       for(int i=0; i < 100; ++i)
       {
            progressFeedback.Report(i);
            await Task.Pause(1000);
       }
   }
}

that way, I can call DoSomeExpensiveWork, passing the ProgressBar control directly, to update the progress bar as the job progresses.

that way, I can call DoSomeExpensiveWork, passing the ProgressBar control directly, to update the progress bar as the job progresses.

First of all, accessing visual element inside VM is bad practice.
Secondly you just need

class SomeMVVM
{
   public async Task DoSomeExpensiveJob(ProgressBar bar)
   {
       for(int i=0; i < 100; ++i)
       {
            bar.Value = i;
            await Task.Pause(1000);
       }
   }
}

DoSomeExpensiveJob(ProgressBar bar)

To do that you have to reference Avalonia in your MVVM project, with IProgress, you don't need to.

passing the ProgressBar control directly

Hmm, that's you said passing the ProgressBar control directly, we usually update a number in ViewModel, and bind progressbar value to that value, no direct access.

I will also add that using a progress bar itself to track progress rather than the underlying value is very odd. As mentioned it also breaks MVVM by having the progress bar be passed to the view model, giving the view model knowledge of the view. Even if it's only an interface, it's still not great. Typically the view reads the view model, not the other way around.

@vpenades why not having a property Percentage which you update from your task and which is bound to the Progressbar as any other value?