Source-generated, NativeAOT-clean fluent server API with event-source publish #3765
Annotations
11 warnings and 1 notice
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L797
Change return type of method 'WaitAsync' from 'System.Threading.Tasks.Task' to 'System.Threading.Tasks.Task<bool>' for improved performance (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1859)
|
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L704
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)
|
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L797
Change return type of method 'WaitAsync' from 'System.Threading.Tasks.Task' to 'System.Threading.Tasks.Task<bool>' for improved performance (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1859)
|
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L704
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)
|
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L797
Change return type of method 'WaitAsync' from 'System.Threading.Tasks.Task' to 'System.Threading.Tasks.Task<bool>' for improved performance (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1859)
|
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L704
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)
|
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L797
Change return type of method 'WaitAsync' from 'System.Threading.Tasks.Task' to 'System.Threading.Tasks.Task<bool>' for improved performance (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1859)
|
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L704
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)
|
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L797
Change return type of method 'WaitAsync' from 'System.Threading.Tasks.Task' to 'System.Threading.Tasks.Task<bool>' for improved performance (https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/ca1859)
|
|
Build Solution:
Tests/Opc.Ua.Server.Tests/Fluent/PublishTests.cs#L704
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)
|
|
Initialize CodeQL
Cannot build an overlay database because build-mode is set to "undefined" instead of "none". Falling back to creating a normal full database instead.
|
|
|
background
wait
wait-all
cancel
Loading