Я использую netTcpBinding WCF, который подключается напрямую к конечной точке и, похоже, ничего не знает о прокси-серверах socks.
Мне нужно использовать прокси-сервер, потому что большинство моих клиентов не разрешают прямые исходящие соединения и постоянно используют прокси-серверы socks.
Моей первой идеей было настроить .net framework для этого, поэтому я отредактировал файл machine.config следующим образом, но, похоже, он работает только с http-прокси (не с socks)
<system.net>
<defaultProxy enabled="true">
<proxy usesystemdefault="False" proxyaddress="foo:1080" bypassonlocal="True"/>
<module />
</defaultProxy>
</system.net>
Второй вариант заключался в том, чтобы реализовать пользовательскую привязку, наследующую от netTcpBinding, и переопределить логику подключения только для добавления прокси-кода.
Я демонтировал сборку System.ServiceModel, и, к сожалению, многие классы помечены как внутренние (в том числе SocketConnectionInitiator, ConnectionPoolHelper, ClientFramingDuplexSessionChannel и FramingDuplexSessionChannel и, возможно, другие также)
Это делает создание пользовательского netTcpBinding огромной работой, и, кроме того, может вызвать некоторые проблемы при поставке новых версий .net Framework.
Другая идея состоит в том, чтобы внедрить некоторый код непосредственно в метод Socket.Connect (). Этого довольно легко достичь, но я не очень уверен в изменении внутреннего кода .net framework. Кроме того, хотя класс сокета не помечен как закрытый, я боюсь что-то сломать, особенно в последующих версиях фреймворка.
Последняя идея, которая у меня есть на данный момент: я мог бы создать небольшой прокси-инструмент, работающий на том же компьютере, что и мое программное обеспечение, который будет автоматически подключаться к корпоративному socks-прокси и выдавать хороший «сервер подключения» Команда для реального прокси носки.
Последний вариант, на мой взгляд, лучше, но мне любопытно услышать мнение других людей.
Что вы думаете?