Как предотвратить свойства 'Specified', сгенерированные в клиентах WCF?
У меня есть две.NET 3.5 сервисных сборки WCF с VS2008.
У меня есть два клиента WCF в Silverlight для потребления этих сервисов. Клиенты сгенерированы с, 'Добавьте Сервисная Ссылка'. Я использую Silverlight 4.
ОДИН из прокси сгенерирован с Specified свойства для каждого свойства. Это - 'сообщение - в' классе для моего сервисного метода:
// properties are generated for each of these fields
private long customerProfileIdField;
private bool customerProfileIdFieldSpecified;
private bool testEnvField;
private bool testEnvFieldSpecified;
Теперь мой другой сервис (все еще с клиентом Silverlight) НЕ генерирует Specified свойства.
Теперь я не забочусь о 'принципах хорошего SOA'. Я просто хочу избавиться от этих проклятых свойств, потому что в контексте того, что я делаю, я абсолютно ненавижу их.
Должно быть некоторое различие между этими двумя сервисами - но я не хочу должным быть полностью разрывать их для обнаружения различия.
Подобный вопрос прежде имел ответ, 'Вы наклоняетесь, делают это' - который определенно не верен, потому что у меня есть он - я просто не знаю то, что я сделал по-другому.
Править: Я нахожусь теперь в ситуации, где я повторно создаю свой прокси Silverlight 4 к моим 3.5 сервисам WCF (все на той же localhost машине), что иногда я получаю свойства 'Specified', и иногда я не делаю. Я больше не думаю (как я подозревал первоначально), что это должно только к некоторой конфигурации конечной точки или уровню обслуживания [атрибут]. Существуют определенные триггеры в самом сообщении что причина, Указанная, чтобы быть сгенерированными (или не). Может быть много включенных факторов, или это может быть что-то очень простое.
3 ответа
Попробуйте это в вашей службе WCF, где объявлено имущество
[DataMember(IsRequired=true)]
public bool testEnvField { get; set; }
isrequired = true , не отрицает необходимость в теметелевомфидлдеспределенном собственности
Для получения информации о параметрах подписи метода Main см. this .
Единственные действительные подписи для метода Main :
static void Main()
и
static void Main(string[])
static void Main (последовательность) не является действительной подписью для метода Main .
ОК Я пока нашел одну вещь, которая вызовет Указанные свойства:
- Наличие
XTypedElementв сообщении.
Они используются Linq2XSD. Я возвращал элемент из Linq2XSD модели.
Это вызвало Указанные свойства для создания ВСЕГО во всех моих классах:
public XTypedElement Foo { get; set; }
Это, однако, не:
public XElement Foo { get; set; }
Все еще любопытно, почему это так, и если есть какие-либо другие вещи, которые вызывают это.
Эти дополнительные указанные свойства генерируются для типов значений, которые указываются как необязательно в договоре, либо на разметке атрибута.
В качестве типов значений имеют значение по умолчанию, для этих свойств добавляют дополнительные флаги , чтобы позволить клиенту (и серверу) различать нечто явное не указанное или явно указанное - что может Ну, будьте установлены на значение по умолчанию. Без этого целые числа больше не будут в конечном итоге 0 (и быть сериализом), даже если вы не установите их (из-за отображения int) в вашем клиентском коде. Поэтому, когда вы делаете, вам также необходимо убедиться, что вы установили указанный флаг , в противном случае эти свойства не получат сериал.
Итак, чтобы предотвратить создание этих флагов для типов значений, вам придется изменить контракт, чтобы сделать эти свойства типа значения, а не необязательно.
Надеюсь, что имеет смысл.