Обмен пользовательскими объектами м/у несколькими сборками

[*null]

Есть несколько Web-сервисов и Windows-Application. Между ними требуется передавать экземпляр структуры. Т.е. описываем (например, в WebService1) некоторую структуру вроде:
public struct SomeStruct

{
public Int32 SomeMember1;
public string SomeMember2;
. . .
}

Некоторые методы WebService1 возвращают экземпляр этой структуры. WindowsApplication вызывает эти методы, получают структуру, как то с ней работают и передают этот объект WebService2 (как аргумент методов сервиса).

Проблема в том, что при компиляции Windows-Application получаю ошибки вроде:

Cannot convert type WebService1.SomeStruct to WindowsApplication.SomeStruct /
Cannot convert from WindowsApplication1.SomeStruct to WebService2.SomeStruct

Как разрешить такую проблему, сделать данную структуру общей для всех сборок?

Пробовал вынести ее в отдельную библиотеку, а в сервисах и приложении создать на нее ссылки. Результат примерно тот же: компилятор ругается если экземпляр структуры создавался в разных нейм-спейсах.

Подскажите решение, плиз

 

[NikSoft]

Для: *null
А зачем преобразовывать типы?
Разве нельзя скопировать содержимое WebService1.SomeStruct в WindowsApplication.SomeStruct
по полям?

 

[*null]

Можно конечно, но не слишком "красивое" решение, imho.
Неужели как то иначе нельзя? Хотелось бы сделать тип общим для всех сборок.

 

[Pasha]

Для: *null
Копировать по полям, с использованием Reflection. Вполне "красиво" будет.

 

[NikSoft]

Для: *null
Можно создать сборку состояшей из одного типа(скажем типа Т) с полями из структуры.
А затем передавать тип Т из WebService в WindowsApplication и наоборот в качестве параметра

 

[mr_ST]

В таком случае создается отельная сборка типа MyApp.Contract а которую помещаются классы/структуры/интерфейсы общие для сервера и клиента.

 

[Pasha]

Контракты и общие сборки это, конечно, хорошо. Вот только клиентское приложение использует WebService через Web Service Reference. И структуры передаются/возвращаются не в виде MyApp.Contract.MyStruct, а в виде их прокси MyClentApp.MyWebReference.MyStruct.
<!--QuoteBegin-*null+25:06:2007, 09:29 -->
<span class="vbquote">(*null @ 25:06:2007, 09:29 )</span><!--QuoteEBegin-->Пробовал вынести ее в отдельную библиотеку, а в сервисах и приложении создать на нее ссылки. Результат примерно тот же: компилятор ругается если экземпляр структуры создавался в разных нейм-спейсах.

[snapback]70456" rel="nofollow" target="_blank[/snapback]​

[/quote]И собственно вопрос: можно ли стандартными средствами создать Web Service Reference, передающий сами структуры, а не их жалкое проксевое подобие.

 

[*null]

Всем спасибо за ответы!

NikSoft, mr_ST - именно так я и пытался сделать: вытащил в отдельную библиотеку.
Явно прописывал namespace'ы и в клиентах и в web-сервисах. Допустим если метод сервиса возвращает
MyLib.SomeStruct, на клиенте я создаю такой объект и пытаюсь его проинициализировать методом веб-сервиса. В результате получал ошибки из первого поста: компилятор считает что
WebService1.SomeStruct != WindowsApplication1.SomeStruct
хотя они и там и там объявлены как MyLib.SomeStruct.

NikSoft, Pasha - пока обошелся копированием (без reflection), но хотелось использовать первый вариант - с общей библиотекой типов.

 

[Pasha]

Для: *null
Нашел мегассылку:

Ссылка скрыта от гостей

 

[mr_ST]

В результате получал ошибки из первого поста: компилятор считает что
WebService1.SomeStruct != WindowsApplication1.SomeStruct
хотя они и там и там объявлены как MyLib.SomeStruct.

Ну да, это совершенно разнве типы несмторя на то что они имеют одинаковые имена.

 

[karlito]

И собственно вопрос: можно ли стандартными средствами создать Web Service Reference, передающий сами структуры, а не их жалкое проксевое подобие.

Либо полноценная схема, но канал придётся самому строить. Либо скорость разработки с Web Service Reference, но с убогой схемой. Стандартными средствами этого не изменить, но, как грится, было бы желание, время и конечная ценность решения. Всё зависит от самого приложения. Но если можно сделать проще, то лучше так и сделать.

 

[Pasha]

Для: karlito
Сходи по мегассылке из моего предыдущего поста. Там сказано как изменить это, причем стандартыми средствами.

Current solutions to this proxy customization problem include manually editing the generated code, but this has the obvious drawback that all your changes are lost if you re-generate the proxy. Another option is not to generate a proxy at all, and manually coding up the typed proxy....
In the .NET Framework 2.0 and Visual Studio 2005, the new concept of Schema Importer Extensions makes it possible to resolve these shared types. Schema Importer Extensions allow you to customize the code generated from a WSDL document when using automated query tools, such as WSDL.exe or the Add Web Reference dialog box in Visual Studio. It works by inheriting from the System.Xml.Serialization.Advanced.SchemaImporterExtension class, overriding one or more methods, deploying the assembly containing that class to a discoverable location, and finally registering the Schema Importer Extension on your machine.

 

[karlito]

Для: Pasha
Менять генерённые файлы не есть хорошо и не есть стандартное средство. А за Schema Importer Extensions спасибо.