Changing WcfProxy.DefaultBinding or its properties has no effect

[klk103]

I'm working on a PowerShell script that uses some of our existing business objects, and connects to a dataportal on our application server the same way that our other applications do, instead of using a local in-process portal.

I can't use the standard app.config approach (because PowerShell), so I thought that configuring the dataportal in the script would look like this (we use transport security instead of message):

[Csla.ApplicationContext]::DataPortalProxy = [Csla.DataPortalClient.WcfProxy].AssemblyQualifiedName
[Csla.ApplicationContext]::DataPortalUrlString = "https://portal.internal/Production.svc"
[Csla.DataPortalClient.WcfProxy]::DefaultBinding.Security.Mode = [System.ServiceModel.SecurityMode]::Transport

But apparently the Binding property that's loaded from DefaultBinding isn't actually used when creating a channel, so the security mode isn't applied to the binding that's ultimately used.

[rockfordlhotka]

@klk103, I like the changes - the code is cleaner the way you have it now.

I do wonder if this is a potential breaking change for existing code? Or was this broken in a way that your updates won't break anyone?

[klk103]

I believe it's the latter. The Core/Xamarin code actually uses the Binding property correctly, which was a BasicHttpBinding before and still is for those builds, and the rest of the builds incorrectly used WsHttpBinding every time, which is now their default.

The only scenario I can see this causing issues for is if anyone with a .Net 4.x project was modifying DefaultBinding, or they subclassed WcfProxy and made changes to Binding. That code would currently have no effect, but it would become "active" if this change was made.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.