2010-01-12 16 views
10

Tengo dos servicios .NET 3.5 WCF compilados con VS2008.¿Cómo evitar que se generen propiedades 'especificadas' en clientes WCF?

Tengo dos clientes de WCF en Silverlight para consumir estos servicios. Los clientes se generan con la 'Agregar referencia de servicio'. Estoy usando Silverlight 4.

Uno de los proxies se genera con Specified propiedades para cada propiedad. Esta es una clase 'mensaje-in' para mi método de servicio:

// properties are generated for each of these fields 
    private long customerProfileIdField;   
    private bool customerProfileIdFieldSpecified;   
    private bool testEnvField;   
    private bool testEnvFieldSpecified; 

Ahora mi otro servicio (aún con un cliente Silverlight) no genera Specified propiedades.

Ahora no me importan los 'principios de buena SOA'. Solo quiero deshacerme de estas malditas propiedades porque en el contexto de lo que estoy haciendo, las odio.

Tiene que haber alguna diferencia entre los dos servicios, pero no quiero tener que separarlos por completo para descubrir la diferencia.

A similar question antes tenía la respuesta 'you cant do it' - que definitivamente no es verdad porque la tengo - simplemente no sé lo que hice diferente.

Editar: Ahora estoy en una situación donde regenero mi proxy Silverlight 4 a mi servicio WCF 3.5 (todos en la misma máquina localhost) que a veces obtengo propiedades 'especificadas' y otras veces no. Ya no creo (como sospeché originalmente) que esto se deba únicamente a alguna configuración de punto final o nivel de servicio [atributo]. Hay ciertos desencadenantes en el mensaje en sí que provocan que se genere Especificado (o no). Puede haber muchos factores involucrados o puede ser algo muy simple.

+0

realidad tengo 3 servicios que no están creando propiedades especificadas. ¡Solo el cuarto lo hace! –

+0

Agregue '[XMLSerializerFormat]' a los atributos en su servicio: verifique esto [respuesta] (http://stackoverflow.com/questions/13396190/wcf-service-method-arguments-bool-specified) –

Respuesta

11

probar esto en su servicio WCF donde la propiedad se declara

[DataMember(IsRequired=true)] 
public bool testEnvField { get; set; } 

IsRequired=true va a negar la necesidad de la propiedad testEnvFieldSpecified

+0

¿qué tal hacer esto globalmente? ? ahora mi servicio que creaba propiedades especificadas simplemente ha dejado de crearlas mágicamente. Acabo de agregar un segundo OperationContract con un mensaje muy similar, así que todavía estoy atascado sabiendo qué está desencadenando este comportamiento global –

+0

La única razón por la que pude ver por qué 2 proxies se generarían con SpecifiedField y no, es desde aplicaciones cliente .3.5 no necesitan la propiedad "IsRequired", suponen que es verdadera de manera predeterminada, donde como las aplicaciones .net2.0 necesitan el atributo, leen el wsdl de manera diferente. ¿Son ambas aplicaciones SL4? – Neil

+0

@neil es la misma aplicación única! Ahora llegué a un punto en el que, después de recompilar mi aplicación 3.5 y regenerar un proxy para mi cliente SL4, algunas veces me 'especifican' y otras no. ¡Es realmente frustrante! algo en el modelo de datos está causando este comportamiento –

0

Aceptar He encontrado una cosa tan lejos que hará que Specified propiedades a se generará:

  • La presencia de un XTypedElement en el mensaje.

Estos son utilizados por Linq2XSD. Estaba devolviendo un elemento de un modelo Linq2XSD.

Esto provocó Specified propiedades que se generen TODO en todas mis clases:

public XTypedElement Foo { get; set; } 

Sin embargo, esto no fue así:

public XElement Foo { get; set; } 

Aún curiosidad de por qué esto es, y si hay alguna otras cosas que desencadenan esto.

+0

Estoy de repente obtener un problema similar en un servicio web que solía funcionar como está escrito, aunque no estoy usando XTypedElement o Linq2XSD, y estoy usando .NET 4.0 – speckledcarp

2

Estas propiedades adicionales especificadas se generan para los tipos de valores que se especifican como opcionales en el contrato o en el marcado de atributo.

Como los tipos de valor tienen un valor predeterminado, se agregan los indicadores adicionales Specified para estas propiedades, para permitir que el cliente (y el servidor) distingan entre algo explícitamente no especificado o explícitamente especificado, que bien puede configurarse en valor por defecto. Sin ella, los enteros siempre terminarían siendo 0 (y se serializarán) incluso si no los configura (debido a la asignación a int) en su código de cliente. Entonces, cuando lo haga, también debe asegurarse de establecer el indicador Specified en verdadero, de lo contrario, estas propiedades no se serializarán.

Para evitar que estos indicadores se generen para los tipos de valor, tendría que cambiar el contrato para que estas propiedades de tipo de valor sean obligatorias, en lugar de opcionales.

Espero que tenga sentido.

+1

Derecha que hace p Sentido de error EXCEPTO No siempre los obtengo, incluso para los tipos de valores. En la actualidad, todos mis booleanos (incluso no anulables) y 'ints' NO están generando estas propiedades, pero ocasionalmente cambio algo involuntariamente en el contrato que hace que se generen (y definitivamente no agrego accidentalmente [DataMember (IsRequired = true) ]). Realmente me gustaría saber cómo desactivarlos permanentemente para que se comporten como objetos 'normales'. –

+0

Los que no aceptan nulos deben estar bien, solo los tipos de valores * opcionales *, que tendrán esto. –

+0

es al revés.son los campos no anulables que necesitan las propiedades especificadas porque, de lo contrario, no sabrías si el valor predeterminado (falso o 0) es lo que el usuario realmente quería. los opcionales simplemente no existirán, pero el hecho de que sean opcionales dice que eso está bien. en cualquier caso, TODAS mis propiedades terminan obteniendo propiedades especificadas que básicamente atornillan completamente mi código. tiene que haber un conjunto de reglas que determinen cuándo se generan y cuándo no. no es tan simple como la nulabilidad desafortunadamente (o afortunadamente dependiendo de cómo se mire) –

0

NOTA: Me doy cuenta de que esta es una vieja pregunta. Estoy agregando esto aquí porque esta pregunta surge como un resultado superior en Google, y es información útil para quien viene.

Trate de añadir esta línea en su declaración de contrato de operación:
[XmlSerializerFormat]

Debe ser algo como esto:

namespace WebServiceContract 
{ 
    [ServiceContract(Namespace = "http://namespace")] 
    [XmlSerializerFormat] //This line here will cause it to serialize the "optional" parameters correctly, and not generate the extra 
    interface InterfaceName 
    { 
     /*...Your web service stuff here...*/ 
    } 
} 
+1

Tenga en cuenta que esto cambia completamente el motor de serialización XML utilizado para el servicio web. (Cambiando de DataContractSerializer a XmlSerializer). El motor diferente usa un conjunto diferente de atributos para controlar la salida del serializador, tiene diferentes límites de compatibilidad y diferentes características de rendimiento. No es un cambio menor – Hydrargyrum

Cuestiones relacionadas