¿Puede un WebServiceHost ser cambiado para evitar el uso de HttpListener?

Question

Estoy buscando una manera de utilizar un WCF WebServiceHost sin tener que depender de la clase HttpListener y que está asociado problemas de permisos (véase esta pregunta para más detalles).

Estoy trabajando en una aplicación que se comunica localmente con otra aplicación (de terceros) a través de su API REST.

En este momento estamos utilizando WCF como un servidor HTTP. Creamos un WebServiceHost de la siguiente manera:

String hostPath = "http://localhost:" + portNo;
WebServiceHost host = new WebServiceHost(typeof(IntegrationService), new Uri(hostPath));

// create a webhttpbinding for rest/pox and enable cookie support for session management
WebHttpBinding webHttpBinding = new WebHttpBinding();
webHttpBinding.AllowCookies = true;

ServiceEndpoint ep = host.AddServiceEndpoint(typeof(IIntegrationService), webHttpBinding, "");

host.Open()

ChannelFactory<IIntegrationService> cf = new ChannelFactory<IIntegrationService>(webHttpBinding, hostPath);
IIntegrationService channel = cf.CreateChannel();

Todo funciona muy bien, siempre y cuando nuestra aplicación se ejecuta como administrador. Si ejecutamos nuestra aplicación en una máquina sin privilegios administrativos la host.Open () lanzará una HttpListenerException con ErrorCode == 5 (ERROR_ACCESS_DENIED).

Podemos evitar el problema mediante la ejecución de httpcfg.exe desde la línea de comandos, pero esto es una aplicación de escritorio con un solo clic y que en realidad no es una solución a largo plazo como para nosotros.

Podríamos zanja WCF y escribir nuestro propio servidor HTTP pero me gustaría evitar que si es posible.

¿Cuál es la forma más fácil de reemplazar HttpListener con un socket TCP estándar sin dejar de utilizar todos los andamios HTTP restante que WCF proporciona?

Answer 1

Puede componer fácilmente su propia pila a través de customBinding, utilizando el protocolo de nivel superior cosas "tal cual", y rodar su propia versión de HttpTransport que no está respaldada por HttpListener o IIS. Factible, seguro, pero es mucho trabajo. Tome los bits existentes HttpTransport de separación, con reflectoras hay un montón de piezas móviles en ese país. Probablemente se podría piratear un PoC simple a través de socket en un día o dos, si no es necesario ningún procedimiento especial como HTTPS o CHUNKING, pero lo que es robusta va a ser complicado. Aquí una buena WrapUp de un montón de recursos (puede ser un poco anticuado ahora).

Answer 2

Su problema no está relacionado con HttpListener.

Su problema es: * Tiene una aplicación de OneClick con permisos limitados que * Trata de abrir un puerto del servidor.

Esto es una contradicción. Una aplicación permiso limitado no es de confianza no debe abrir un puerto del servidor. Esta es la razón por esto no está permitido por la definición.

¿Ha intentado abrir un puerto de socket normal? Para que no funcione bien.

En general, las aplicaciones de usuario final confianza limitados no deben albergar un servicio web;)

Dicho esto, me tienen estado en una situación similar tratando de usar WCF en un escenario de comunicación conductor -. Gracias a Dios mi aplicación se ejecuta con el permiso completo

Answer 3

También podría mirar a desgarrar suficiente Cassini para que sea hospedable en su aplicación, y la carga de la tubería WCF allí (a través de archivos .SVC y el manejador de la activación del servicio) - que sería requiere muy poco escribiendo nuevo código de esa manera, pero todavía le dan un servidor web bastante robusto y probado.