Or if I'm going about this wrong can you explain the expected way I should be setting up the assembly's objectdatasource services so that I can call to injected data services (which themselves inject httpfactory clients) and eventually make REST calls out to get data?

In previous projects before .core and DI, it wasn't as much of a problem because implementations were all concrete. We are just running into this now because our projects are all moving to .NET6/7 and utilizing the DI framework.

Thanks for the update.

As for the DI, report execution binds to a compiled assembly to access the ObjectDataSource component and services. Right now the services have to be parameterless. The report services that are called during execution eventually have to make calls to services (ideally injected) which use a httpfactory (ideally injected) to make the calls out to our report data api. The parameterless constructor makes it hard to have the asp.net core DI system inject the services we need. Right now I think I have to hard code the bindings between the service interfaces and concrete implementations. 

It would be nice if either we could let DI fill in non-parameterless service methods for the reports or somehow have access to the IServiceProvider which I could get services from.

I honestly don't know how it would work. It's different since the report is starting execution on that request pipeline. Similarly to the way you can currently hit asp.net core controller actions from a REST call to start a request pipeline and the controller allows you to put injectable interfaces as parameters in the constructors.

Thanks for the update Todor. Good to hear something is in development. When I've asked before I just kept getting the response that there was no plans for this and the web designer should be used instead.

In the current standalone designer it was possible to add some things like appSettings and reference our assembly. Do you know if the .NET 6 standalone designer will allow us to also reference our assembly, use appSettings.json values, execute some startup code like DI registrations and then allow the designer to resolve services from the DI container?

I had the same issues and found a workable solution. Our production app is targeting .NET6. I ended up having to make 3 projects for TelerikReporting. As a note, we are also using ObjectDataSources in our reports and our reportservices in the referenced assembly make REST calls to our APIs to get their data. No direct DB access for reports.

(1) a .NET6 reporting project that my app would reference. It has:

• DataSource Components
• The Report Services that the report executes against (with DataObject and DataObjectMethod annotations
  

(2) a .NET Standard 2.0 designer project. It would have a mirror of #1 project items. Currently we have our report services dataservice tied directly to our Mock data service. I haven't spent time trying to get this one working against our REST data services.

(3) a .NET Standard 2.0 core project that both #1 and #2 share containing report models, constants, data service interfaces, mock data services

When we compile the designer project (#2), VS does a post build event to copy the bin to a folder in the standalone report designer's installation directory. The designer exe.config references that bin folder and has an assembly reference to our designer assembly there.

Our reports are stored in the TRDX format (XML based) because we encode the reports to string and store them in our database. When we need to use them for execution or to edit with the report designer they are extracted from the DB. For editing in the standalone designer we convert the string back to bytes and pass back as a trdx file. When editing is done we upload the trdx file and it converts it back to a string and stores it in the DB.

The one hiccup was that the TRDX contents has a <ClrType /> XML node pointing to the referenced report service and assembly. For report execution this needs to be the .NET6 report service and assembly. For editing in the standalone designer, this needs to be the .NET Standard 2.0 report service and assembly. When we extract the TRDX from the database if used for execution we string replace the ClrType node in the XML with the references for the .NET6 project. If we extract the TRDX from the database for the purpose of downloading as a trdx file for use in the standalone designer then we string replace the ClrType with the .NET Standard 2.0 project references. 

I still have to do more testing on the execution. I'm not sure if the report executing against the .NET6 project will be able to make use of the DI system for injecting data services and may have to hard code in the data services when DI isn't there to fill in the interfaces.

Hopefully this helps others running into the same issue. I went forward with this solution because I felt there was a 0% chance Telerik would release a standalone designer built on .NET6+ in the next couple years.