Microsoft docs claim this .NET class is public... Labview disagrees

[Nickster]

I want to use (or at least try using) the ClientWebsocket .NET class (System.Net.Websockets.Client). The documentation says the class is public, but Labview seems to claim otherwise. What gives?

P.S. - I'm aware of the websocket package available via VIPM. I've found it, er... wanting. If someone knows another (free) solution, I'd be interested to hear about it.

Thanks,

Nick

[Darin.K · Accepted solution]

Look under the System namespace instead.

[Nickster]

Ha! Thanks! I had tried all the way up to System.Net without any luck.

Am I wrong in thinking that it shouldn't behave this way?

[Kyle97330]

If you look at the MS web page for any .NET code, the choice you need to make in LabVIEW will always be one of the listed items in the "Assemblies" list, minus the ".dll" at the end:

However, I've never been able to determine why they order them as they do, so it's always a bit of a crapshoot.  If you're lucky, there will be only one.

[rolfk]

The names LabVIEW shows are simply the component names under which .Net classes are registered in the system. This registration typically happens during installation (or sometimes through self registration when a .Net assembly is first loaded).

LabVIEW simply uses .Net to enumerate all registered classes and then uses the registry name to show them. Why Microsoft tends to make such a mess especially in the System namespace when registering .Net classes and changes the registered name of components to something else than the actual assembly namespace I do not know. LabVIEW could probably retrieve the assembly namespace too and display that instead but it might be that that was not an option in the beginning when the .Net functionality was implemented in LabVIEW. Maybe a CAR might be in order.

[tyk007]

I think the .NET Framework shows the symptoms common to large, older legacy frameworks. The initial core concepts were 'pure' and focused and conventions were followed. But then changes happen along the way to fit in with customer requirements and the classic "time-to-market vs ideal engineering solution" compromise comes into play. Decisions are made in the name of effectiveness (time and cost) rather than purity but also with a mind to maintaining backward compatibility (where at all possible) which is very difficult balance. 

Out of interest: this book (https://www.amazon.com/Framework-Design-Guidelines-Conventions-Development-ebook/dp/B0017SWPNO) is an interesting read as it contains hundreds of comments from the framework designers about why they made the decisions they did at the time and, in hindsight, what they would do differently. It also contains good guidance around developing frameworks, including places where the designers themselves didn't heed their own advice due to reasons of time, cost or other factors. I think it echoes the thoughts of most developers who have had to maintain an ever-changing framework across the two decades.

[tyk007]

---

@Kyle97330 wrote:

If you look at the MS web page for any .NET code, the choice you need to make in LabVIEW will always be one of the listed items in the "Assemblies" list, minus the ".dll" at the end:

However, I've never been able to determine why they order them as they do, so it's always a bit of a crapshoot.  If you're lucky, there will be only one.

---

I can't speak to the order shown on the list but I can explain why only choosing the "System" option in LabVIEW works. The "...WebSockets.Client" assembly doesn't contain any type implementations, only declarations of the two public classes which are type-forwarded to the System assembly.  The Fusion loader understands type forwarding but LabVIEW doesn't, which is why it can't find any types.

My thoughts on type forwarding is that its primary purpose these days is as a tool to aid in backwards compatibility as framework structure is "shuffled" eg. where the "physical" or file location of types changes with respect to the logical location. The .NET Standard uses type forwarding heavily so that platform-agnostic .NET code can reference the same physical name of "netstandard.dll". Then each platform-specific implementation of .NET (with it's own copy of "netstandard.dll") will re-direct at runtime to the appropriate OS-specific platform libraries that contain the implementation of those types. This is how .NET Framework (along with other pre-existing frameworks) can still work in the .NET Standard era even though they were designed before it.

As to why Microsoft chose to use type-forwarding in this case, I'm not sure.

[Sam_Sharp]

As the author of the WebSockets library available on the tools network, how is it 'wanting'? What issues were you having with it?

FYI - a new version with a major rewrite has been published in the last few weeks.

[Nickster]

Oof - I was not too tactful in my initial post! Sorry for that, as I'm actually quite grateful for the package!

As it's off-topic from the thread, I just DM'd you. Glad to hear of the new release, and I look forward to trying it out.