Uso de namespaces en la generación de una DLL
Para resolver el problema de los namespaces, se hizo una modificación en Proxy Manager 5900.
En principio, el problema se produce solamente si se necesita usar un namespace cuando se genera una nueva clase proxy, informándolo en el campo “Espacio de nombres”:
Los namespaces se requieren cuando hay más de un EndPoint cliente en el archivo de configuración de EIS utilizando el mismo contract. Por ejemplo, lo siguiende genera un conflicto:
<system.serviceModel>
<client>
<endpoint address=”http://localhost/WSExamples20/WSExampleComplex1.asmx” binding=”customBinding”
bindingConfiguration=”WSExampleComplexSoap12″ contract=”WSExampleComplexSoap” name=”WSExampleComplex1″ />
<endpoint address=”http://localhost/WSExamples20/WSExampleComplex2.asmx” binding=”customBinding”
bindingConfiguration=”WSExampleComplexSoap12″ contract=”WSExampleComplexSoap” name=”WSExampleComplex2″ />
</client>
</system.serviceModel>
Pero al utilizar namespaces al generar la clase proxy, el contract ya tiene distinto nombre, por ejemplo:
<system.serviceModel>
<client>
<endpoint address=”http://localhost/WSExamples20/WSExampleComplex1.asmx” binding=”customBinding”
bindingConfiguration=”WSExampleComplexSoap12″ contract=”NS1.WSExampleComplexSoap” name=”WSExampleComplex1″ />
<endpoint address=”http://localhost/WSExamples20/WSExampleComplex2.asmx” binding=”customBinding”
bindingConfiguration=”WSExampleComplexSoap12″ contract=”NS2.WSExampleComplexSoap” name=”WSExampleComplex2″ />
</client>
</system.serviceModel>
Agregar un namespace es inocuo en la mayoría de los casos de generación de clases proxy, pero según cómo estén definidas las estructuras de datos en el WSDL (lo cual no implica una inconsistencia del WSDL), se pueden producir errores en el código de la clase proxy.
El valor ingresado en el campo “Espacio de nombres” de Proxy Manager, va a parar diréctamente al parámetro “namespace” de SvcUtil, de la siguiente manera “/namespace: *,<namespace>”. Esto se puede ver en el archivo “./AssembliesGeneration/ClientGeneration/GenerateComplexClient.bat”, que se utilizaba antes de que Proxy Manager tuviera la capacidad de generar clases proxy:
“..\VsSdkTools\svcutil.exe” /namespace:*,WSE20 /config:..\..\%DLLNAME%.config /l:VB /tcv:Version35 /o:.\%DLLNAME%.vb %WSDLPATH%
Pero ese formato hace que todos los namespaces del WSDL se mapeen al mismo namespace en el código fuente de la clase proxy. Con lo cual, si se quiere mapear específicamente un namespace del WSDL a un namespace del código fuente, se debe informar de la siguiente manera:
/namespace: <wsdl_namespace>,<code_namespace>
Y en caso de haber múltiples mapeos, entonces se pueden combinar los parámetros:
/namespace: <wsdl_namespace1>,<code_namespace1> /namespace: <wsdl_namespace2>,<code_namespace2> /namespace: <wsdl_namespaceN>,<code_namespaceN> /namespace: *,<namespace>
Donde el último parámetro englobará bajo el mismo namespace del código fuente a todos los namespaces del WSDL que no se hayan discriminado.
Hasta Proxy Manager 5800 inclusive, sólo se podía informar un solo namespace, pero a partir de Proxy Manager 5900 se puede usar la siguiente sintaxis en el campo “Espacio de nombres”:
<wsdl_namespace1>,<code_namespace1>;<wsdl_namespace2>,<code_namespace2>;<wsdl_namespaceN>,<code_namespaceN>;<namespace>
Lo cual se traduciría a lo siguiente:
/namespace: <wsdl_namespace1>,<code_namespace1> /namespace: <wsdl_namespace2>,<code_namespace2> /namespace: <wsdl_namespaceN>,<code_namespaceN> /namespace: *,<namespace>
Nótese que cuando no se informa un par de namespaces wsdl/code, se asume “*” como hasta ahora.
No es sencillo determinar cuando se necesita un mapeo específico de namespaces, pero es válido hacer prueba y error la primera vez. Y sólo si hay un error de compilación que implique una estructura de datos repetida, se hará necesario un análisis de los namespaces del WSDL (para lo cual hay que tener cierto conocimiento de XSD).