Preview builds: The FrameworkReference 'Microsoft.AspNetCore.App' was not recognized

[staff0rd]

I'm trying to pull in 1.1.0-preview1-10442 into the latest version of Crankier, but when I use any of the preview packages it fails on build:

C:\Program Files\dotnet\sdk\3.0.100-preview7-012821\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(274,5): error NETSDK1073: The FrameworkReference 'Microsoft.AspNetCore.App' was not recognized [c:\git\aspnetcore\src\SignalR\perf\benchmarkapps\Crankier\Crankier.csproj

Using 1.0.12 builds but fails at runtime with:

System.MissingMethodException: Method not found: 'System.Threading.Tasks.Task Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.DisposeAsync()'

Any pointers to unblock me here appreciated - branch here.

[JialinXin]

@staff0rd It seems some version conflict between ASRS and this project. The first exception can be resolved by adding the FrameworkReference in this project like this:

<ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    ...
</ItemGroup>

But even server connection is setup successfully, clients seems not able to connection correct. Would you share more information about how you get detail exceptions like second one.

Besides, if you're looking for a perf test solution towards ASRS. Please have a look on our perf github repo: https://github.com/Azure/azure-signalr-bench/

Installation:

dotnet tool install --global Microsoft.Azure.SignalR.Benchmark --version 1.0.0-preview1-10001

Quick start:

Launch application with Azure SignalR connection string
dotnet signalr-bench application --connection-string " Endpoint=https://xxx” -t 1

Launch controller with built-in agent for echo. It runs 10 seconds and stop.
dotnet signalr-bench controller -u 1 -d 10000 -S echo

For a real perf test, I suggest launch standalone agent:
dotnet signalr-bench agent

[staff0rd]

This commit shows that change but the result is the same error on build of Crankier.csproj;

C:\Program Files\dotnet\sdk\3.0.100-preview7-012821\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(274,5): error NETSDK1073: The FrameworkReference 'Microsoft.AspNetCore.App' was not recognized [c:\git\aspnetcore\src\SignalR\perf\benchmarkapps\Crankier\Crankier.csproj]

The second exception can be achieved using the original commit and running the following command under src/SignalR/perf/benchmarkapps/Crankier:

dotnet run -- server --azure-signalr-connectionstring Endpoint=https://xxx.etc --log Information

Thanks for the link the benchmarking tool, i'll check it out, however i'm looking for a way to benchmark netcoreapp3.0.

[ccic]

netcoreapp3.0 has not yet been officially released. So, the benchmarking tool has not yet supported it. But it is our target.

Anyway, my suggestion is if you have not evaluate the Azure SignalR performance, the benchmark tool can be used for your baseline, because netcoreapp3.0 is supposed to be better than 2.1 or at least will not drop on performance, otherwise it is our perf regression.

That benchmark tool is our recommended tool for both SignalR and Azure SignalR service since it gives customers details numbers for many scenarios on latency and throughput.

See the perf guide: https://docs.microsoft.com/en-us/azure/azure-signalr/signalr-concept-performance

[JialinXin]

@staff0rd I think this is due to version conflicts in AspNetCore. And refer to the workaround here https://github.com/dotnet/cli/issues/11378, I make it work with Crankier. Add below configuration in the csproj. Besides, it requires AspNetCore 3.0 preview9 and Azure SignalR SDK 1.1.0-preview1-10442 which targeting AspNetCore 3.0.

SDK version 1.0.12 is targeting netstandard while there's a break change in the HttpConnnection from 2.2 -> 3.0 as you've met. And since Crankier is targeting netcoreapp3.0. So require to use our preview version.

  <Target Name="WorkaroundNetStandard" AfterTargets="ResolvePackageAssets">
    <ItemGroup>
      <TransitiveFrameworkReference Remove="Microsoft.AspNetCore.App" />
    </ItemGroup>
  </Target>

[JialinXin]

@staff0rd Want to check how's it going with your tests?

[staff0rd]

@ccic, that perf guide is most informative, thanks for pointing it out.

Thanks @JialinXin, the workaround with TransitiveFrameworkReference worked for me - is that reference type documented anywhere?

[staff0rd]

Ah, I see the PR. It seems as though

<DisableTransitiveFrameworkReferences>true</DisableTransitiveFrameworkReferences>

solves this also.