You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
$Factoryformat-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
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:
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
thatUri
is being defined as aSystem.String
, whileuri
as typeSystem.Uri
. Is there a reason for these two public properties? They both wind up calling a private method,SetUri
which only accepts aUri
object type.The text was updated successfully, but these errors were encountered: