mirror of
https://github.com/wiremock/WireMock.Net.git
synced 2026-01-11 21:10:32 +01:00
WireMock 1.4.34 does not work in a .net Framework project once AspNetCore.SignalR.Client is added as dependency #402
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MikeOnTea on GitHub (Feb 4, 2022).
Steps to reproduce:
Create an empty .net Framework 4.8 console app that just starts a WireMock Server and Thread.Sleep()s after that. You can connect to WireMock's Kestrel server via telnet fine.
Now add AspNetCore.SignalR.Client 6.0.1 as a new dependency to the project. After rebuilding and restarting, WireMock's Kestrel does not respond anymore.
This example works fine when done in .net 6.0, the problem only occurs with .net Framework. I've seen that SignalR depends on a lot of new 6.0 versions of assemblies whereas WireMock still depends on 4.0 versions of some of those assemblies, maybe that's a problem here?
@StefH commented on GitHub (Feb 20, 2022):
@MikeOnTea
Can you provide a full working example app?
@MikeOnTea commented on GitHub (Feb 23, 2022):
SignalRWireMock.zip
Yep, here's a minimal zipped project. Notice that i don't actually set up wiremock because it's not required to reproduce the problem. Kestrel just hangs on connection with SignalR present, while it responds just fine to telnet requests if you remove the SignalR reference and rebuild.
@StefH commented on GitHub (Feb 27, 2022):
@MikeOnTea
I noticed that when I run WireMock.Net on port 12345, it fails to respond. So I usually use 9091 or 9090 or something like that.
And I checked signalr, if I use version 5.0.14, it seems to work fine.
But I don't think I can solve your issue.
I would suggest to upgrade your project to .net 6 instead of full 4,8 or just include signalr version 5.0.14
@MikeOnTea commented on GitHub (Feb 27, 2022):
I thought that maybe it could be easy to solve by upgrading some dependencies, but i guess we will be able to work around this issue by better splitting up our projects until we can fully migrate to .net 6.
Thanks for looking into it!