Добавление ссылки на службу создает дублированные определения для перечислений и методов

Я добавляю Navision Web Services в простое приложение Windows Forms с использованием Add Service Reference функций внутри Visual Studio 2010, ссылка генерируется, но внутри кода дублируются определения, которые не позволяют компилировать код, например:

Ошибка

Пространство имен 'WindowsFormsApplication1.ServiceReference1' уже содержит определение 'Status' C:\Trash\WindowsFormsApplication1\WindowsFormsApplication1\Service Ссылки \ServiceReference1\Reference.cs

и внутри Reference.cs У меня

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "4.0.30319.1015")]
[System.SerializableAttribute()]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="urn:microsoft-dynamics-schemas/page/salesheaderpage")]
public enum Status {

    /// <remarks/>
    Open,

    /// <remarks/>
    Released,

    /// <remarks/>
    Pending_Approval,

    /// <remarks/>
    Pending_Prepayment,
}

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="Status", Namespace="urn:microsoft-dynamics-schemas/page/salesheaderpage")]
public enum Status : int {

    [System.Runtime.Serialization.EnumMemberAttribute()]
    Open = 0,

    [System.Runtime.Serialization.EnumMemberAttribute()]
    Released = 1,

    [System.Runtime.Serialization.EnumMemberAttribute()]
    Pending_Approval = 2,

    [System.Runtime.Serialization.EnumMemberAttribute()]
    Pending_Prepayment = 3,
}

Я уже попытался снять флажок Reuse types in referenced assemblies, но дублированные определения все еще генерируются в обоих случаях.

любые идеи?

EDIT: Страница является настраиваемой страницей, подключенной к стандартной таблице 36 (Заголовок продаж)

Ответ 1

Проблема заключается в том, что сериализация происходит дважды:

//Xml Serializer
[System.Xml.Serialization.XmlTypeAttribute(...

//DataContract Serializer
[System.Runtime.Serialization.DataContractAttribute(...

Предполагая, что на сервере не возникает проблем:

Первое, что нужно проверить, это то, что у вас нет перечислений локально с тем же именем, поскольку он часто нарушает повторное использование типов.
Кроме того, использование Add Web Reference должно обеспечивать рабочий код.
Если другие вопросы не устранили проблему (или они вам не полезны, даже если они производят рабочий код), я бы попытался с помощью svcutil вручную создать прокси-класс через специфический сериализатор. Поскольку службы Dynamics должны быть XML-тегами, я бы пошел с /serializer:XmlSerializer (EDIT: я ошибся параметр командной строки!)

Команда может выглядеть так:

svcutil <ServiceURL> /Language:CS /target:Code 
/out:MyServiceProxy.cs /config:MyServiceProxy.config /serializer:XmlSerializer

Расположение по умолчанию инструмента должно быть %ProgramFiles%\Microsoft SDKs\Windows\v6.0\Bin в соответствии с Ссылка MSDN для инструмента (Framework ver 4.0)

Ответ 2

Вот что исправлено для меня:

Добавьте ссылку на службу, как обычно,
В "Solution explorer" выберите переключатель "Показать все файлы"
Откройте ссылку Reference.svcmap только что добавленной ссылки на службу.
Измените строку <Serializer>Auto</Serializer>
К <Serializer>XmlSerializer</Serializer>
Обновить служебную ссылку

Похоже, что в некоторых версиях Visual Studio функция "Добавить ссылку на службу" не может автоматически определить, следует ли использовать XmlSerializer og DataContractSerializer. Таким образом, это заставляет его использовать XmlSerializer.

Ответ 3

Я знаю, что было какое-то время для этого вопроса, но на всякий случай кто-то сталкивается с подобной проблемой:

При добавлении ServiceReference к проекту VS важно использовать точный URL-адрес, связанный с веб-службой, которую вы выставили, то есть:

Не открывайте все объекты веб-сервиса, введя:

http://navserver.domain.com:7047/DynamicsNAV/WS/services

а затем выберите объект веб-службы из списка.

Вместо этого ссылайтесь на объект веб-службы, в частности, как на:

http://navserver.domain.com:7047/DynamicsNAV/WS/%PercentEncodedCompanyNameHere%/page/salesheaderpage

Это избавит вас от необходимости удалять лишние ссылки.

Это не проблема при добавлении веб-ссылки к вашему проекту, она уникальна для ServiceReferences

Ответ 4

Я видел эту проблему раньше, и это случилось, когда у меня было приложение WPF и служба WCF, совместно использующая общую сборку в качестве средства сериализации/десериализации данных между ними.

Проблема, по-видимому, возникла из-за того, что общая сборка имела название другого имени.

Это было некоторое время назад, поэтому моя память несколько туманна, но я считаю, что я переименовал сборку в соответствие с именем проекта, а затем она отлично работала.

По-видимому, об этом сообщают другие пользователи здесь.

Соответствует ли это вашей ситуации?

Ответ 5

Это может быть полезно кому-то. Я добавлял службу postcodeanywhere в приложение и сохранял такую же ошибку. Я изменил пул приложений IIS, чтобы разрешить 32 бит, и он сразу же начал работать. Я понятия не имею, почему это должно быть так, но это сработало для меня.

Ответ 6

Я рекомендую всегда хранить ссылку на службу в собственной DLL, чтобы было легче отменять изменения. "Svcutil" теперь "старый" и иногда путается.

Вот моя история...

Я использую эту служебную ссылку для YEARS и обновляю ее в основном без ussue. Мне понадобился тип Binary от System.Data.Linq, поэтому я проверил эту сборку.

Как-то он полностью запутался и создал дополнительный Reference1.cs, который дублировал ВСЕ в Reference.cs (вы можете видеть, что это новый файл из-за +).

Даже когда я сделал Undo pending changes, чтобы попытаться вернуть его, дополнительный файл остался без символа +, но у меня все еще есть дубликаты.

Мне пришлось полностью удалить ссылку и воссоздать ее.

Как я уже сказал, гораздо безопаснее создать отдельный проект /DLL для вашей справки по сервисам, поэтому, когда что-то происходит (редко, но это происходит), вы можете легко его исправить.