The 'await' operator can only be used within an async method. Consider marking this method with the 'async' modifier and changing its return type to 'Task'.

The 'await' operator can only be used within an async method. Consider marking this method with the 'async' modifier and changing its return type to 'Task'.

The 'await' operator can only be used within an async method. Consider marking this method with the 'async' modifier and changing its return type to 'Task<ISet<string>>'.

Cannot implicitly convert type 'System.Threading.Tasks.ValueTask<EFCoreSecondLevelCacheInterceptor.EFCachedData?>' to 'EFCoreSecondLevelCacheInterceptor.EFCachedData'

ValueTask instances returned from method calls should always be used, typically awaited. Not doing so often represents a functional bug, but even if it doesn't, it can result in degraded performance if the target method pools objects for use with ValueTasks. (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca2012)

Observe the awaitable result of this method call by awaiting it, assigning to a variable, or passing it to another method (https://github.com/Microsoft/vs-threading/blob/main/doc/analyzers/VSTHRD110.md)

Observe result of async calls (https://github.com/meziantou/Meziantou.Analyzer/blob/main/docs/Rules/MA0134.md)

ValueTask instances returned from method calls should be directly awaited, returned, or passed as an argument to another method call. Other usage, such as storing an instance into a local or a field, is likely an indication of a bug, as ValueTask instances must only ever be consumed once. (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca2012)

ValueTask instances returned from method calls should always be used, typically awaited. Not doing so often represents a functional bug, but even if it doesn't, it can result in degraded performance if the target method pools objects for use with ValueTasks. (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca2012)

ValueTask instances returned from method calls should always be used, typically awaited. Not doing so often represents a functional bug, but even if it doesn't, it can result in degraded performance if the target method pools objects for use with ValueTasks. (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca2012)

The annotation for nullable reference types should only be used in code within a '#nullable' annotations context.

'IQueryableBatchExtensions.BatchDelete(IQueryable)' is obsolete: 'As of EF 7 there are native method ExcuteDelete.'

'IQueryableBatchExtensions.BatchUpdate<T>(IQueryable<T>, Expression<Func<T, T>>, Type?)' is obsolete: 'As of EF 7 there are native method ExcuteUpdate.'

'ConfigExtensions.With(IConfig, params IAnalyser[])' is obsolete: 'This method will soon be removed, please start using .AddAnalyser() instead.'

'ConfigExtensions.With(IConfig, params IExporter[])' is obsolete: 'This method will soon be removed, please start using .AddExporter() instead.'

'ConfigExtensions.With(IConfig, params IDiagnoser[])' is obsolete: 'This method will soon be removed, please start using .AddDiagnoser() instead.'

'ConfigExtensions.With(IConfig, params IColumn[])' is obsolete: 'This method will soon be removed, please start using .AddColumn() instead.'

'ConfigExtensions.With(IConfig, params IColumn[])' is obsolete: 'This method will soon be removed, please start using .AddColumn() instead.'

'ConfigExtensions.With(IConfig, params IColumn[])' is obsolete: 'This method will soon be removed, please start using .AddColumn() instead.'