PowerShell and Common Language Specification (CLS) compliant types

[ChrisLynchHPE]

I have yet to find any PowerShell library that supports SSL Certificate authentication. All implement username/password, which will not work for some RabbitMQ implementations. So, in trying to develop my own that implements SSL Certificate authentication, it appears that the Rabbit.Net Client library still has this nagging issue with PowerShell:

[System.Reflection.Assembly]::LoadFile('C:\Dir\RabbitMQ.Client\3.6.5\RabbitMQ.Client.dll')
$Factory = New-Object RabbitMQ.Client.ConnectionFactory
$Factory
format-default : The field or property: "uri" for type: "RabbitMQ.Client.ConnectionFactory" differs only in letter
casing from the field or property: "Uri". The type must be Common Language Specification (CLS) compliant.
    + CategoryInfo          : NotSpecified: (:) [format-default], ExtendedTypeSystemException
    + FullyQualifiedErrorId : NotACLSComplaintProperty,Microsoft.PowerShell.Commands.FormatDefaultCommand

Here are just a few users noting this issue, dating as far back as November 2011:
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-November/016313.html
https://groups.google.com/forum/#!topic/rabbitmq-users/L-5WmEUGyaY
https://groups.google.com/forum/#!topic/microsoft.public.windows.powershell/YA95OVrnhWQ

So, when trying to set any SslOption in the ConnectionFactory, I always get the error about the uri property.

I see within ConnectionFactory.cs that Uri is being defined as a System.String, while uri as type System.Uri. Is there a reason for these two public properties? They both wind up calling a private method, SetUri which only accepts a Uri object type.

[kjnilsson]

No the Uri/uri setters aren't really both needed. I'd prefer to remove them completely and make SetUri public but this is a breaking change in one of the most frequently used classes and thus is something we'd have to be really careful with. CLS compliance probably wasn't something that was considered. Could you try wrapping the .NET client in a CLS compliant API instead? Would that allow you get it to work? I seem to recall seeing someone else doing that.

[kjnilsson]

Ok I've created a PR to deprecate these setters in favour of SetUri. It won't solve the CLS compliancy problem immediately but it begins the process of doing so.