Add support for referencing SignalR C++ client via vcpkg
analogrelay opened this issue · 9 comments
Let's see about getting this done in Preview 8
Moving the C++ stuff out to the backlog to properly reflect 3.0 work.
This is now completed. You can use vcpkg install microsoft-signalr with the latest vcpkg.
I'm going to keep this open to track updating the vcpkg port as we do releases until we can find a better way of doing that.
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
I would recommend updating the installation instruction on the main repo with a) information about the vcpkg work and b) correct installation instructions for linux. I literally stumbled upon this issue while trying to research why the installation instructions have failed.
It's worth noting that the setup/use/config instructions seem like they are a little all over the place. I originally tried the windows manual setup. Then I realized that it would be possible to open in VS as a folder (which is not mentioned). The build times are quite large (range anywhere from 20-25+ minutes) for what seems a relatively small library. Is everything needed (i.e. i would be perfectly fine just using the library and not incorporating the dependencies for any tests)?
The build times are quite large (range anywhere from 20-25+ minutes) for what seems a relatively small library
The long build time comes from the cpprestsdk (which provides the networking stack). The actual client takes less than 2 minutes to build if you exclude that, but then becomes unusable :D
If you want, you can bring your own networking stack and plug into the provided API. with_websocket_factory and with_http_client on the hub_connection_builder.
The current vcpkg port is port busted. It behaves like a package without native cmake support.
We should fix the behavior of the port to behave like a port with native cmake support
Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
We should fix the behavior of the port to behave like a port with native cmake support
Done.
Think this issue can be closed.