doghappy / socket.io-client-csharp

socket.io-client implemention for .NET
MIT License
721 stars 124 forks source link

Breaking changes in 3.0.7 #304

Closed silentdiverchris closed 1 year ago

silentdiverchris commented 1 year ago

Hi, on accidentally using the 3.0.7.0 dll in a release that should have been referencing 3.0.6 I had problems whereby the SocketIOOptions.EIO / EngineIO property has changed from an int to an enum, which is good in general of course, and an easy fix, but a breaking change.

More fundamentally, the SocketIO.Namespace and SocketIO.ServerUri properties seem to have disappeared in 3.0.7 and have no obvious equivalents.

I can't find any readme or other text describing these changes and/or what properties I might use instead of the missing ones if I were to upgrade to the new version. If there is some I'd appreciate a pointer, thanks.

doghappy commented 1 year ago

Sorry for the breakchanges and no any docs updates (busy).

namespace is a internal property and it should not be public, either in socket.io client js lib, why would you like to access it, do you have any mechanism base it?

silentdiverchris commented 1 year ago

Hi, thanks for responding, no worries, sometimes things need to break to evolve :)

Re: why I need to get at the namespace property, now I check what I'm using it for, I don't strictly speaking need it, but have been using it.

I have an application that uses a connection with several namespaces and it stores references to them keyed on the namespace it used to create the connection, and retrieves them that way.

Here and there I use the socket.Namespace property in log messages where I could just use the key they were retrieved with, but with me just passing around a reference to the socket, I dig it out of the properties rather than pass the socket plus the key/namespace as well.

Log messages like... InitialiseSocketClientEventHandlers initialising handlers for socket namespace '{socket.Namespace}' and SocketIO reports socket '{socket.Namespace.ValueOrNoValue("[default]")}' connected

I'd have thought it would be handy to keep it exposed, as it is informative/useful - as a read only property of course as in vsn 3.0.6 - but it's not essential, I could get round that no problem.

doghappy commented 1 year ago

I have exposed Namespace as a readonly property.

temp solution

solution 1

var uri = new Uri("http://localhost:11002/namespace");
using var io = new SocketIO(uri);
var ns = uri.AbsolutePath; // namespace
var dic = new Dictionary<string, SocketIOClient>();
dic.Add(ns, io);

solution 2

https://stackoverflow.com/questions/95910/find-a-private-field-with-reflection

silentdiverchris commented 1 year ago

Thanks, no need for solutions, I can make the namespace available in any case, and using reflection just for a log message is probably a big strike against my future application to enter developer heaven :)