WCF - как хостить на IIS?
WCF - как хостить на IIS?
Есть сервисе и есть клиент. Все отлажено и в отладочном режиме работает.
Отладка, однако, делалась на базе WcfTestClient.exe и IIS Express (того, который автоматически прописывается для сервиса)
Вопросик - Как перекинуть сервисе на обычный IIS.
Веб-сайт создается без проблем.
Сервисе, как приложение, включается в веб-сайт тоже без особых проблем.
Дальше - начинаются непонятности - сервисе остается невидимым.
Т.е. код в папке виден, БИН-фолдер там тоже есть, папки ДЕБУГ & РЕЛЕАСЕ - пустые - дллка и конфиг лежат прямо в БИН.
Копировал построенные дллку и конфиг в корневой БИН сайта - без результата.
Перепроверил и скорректировал все ссылки на функциональность сервиса - они - корректные, актуальные.
Под отладкой - все работает как должно. Под IIS- не видит сервиса.
Ах, да... если добавить обычный веб-сервисе (асмх) - он видим - т.е. все пути правильные
и все должно работать.
Когда-то давно что-то подобное побеждал, но не помню как делал.
По идее - должно быть что-то в конфиге корневой папки или в глобал.асах...
Ткните, плс, носом где прочитат' куда чего дописать...
Пока остановился на следующем.
1. создается обычный сайт на ИИС. Можно - просто приложение в студии.
2. отдельно создается проект для сервиса. Физическая папка мапится к сайту как виртуальная директория.
3. в сервисе надо сделать несколько вещей:
3.1 прописать .СВЦ для каждого доступного сервиса
3.2. в имплементации сервиса прописать атрибут:
[System.ServiceModel.Activation.AspNetCompatibilityRequirements(RequirementsMode = System.ServiceModel.Activation.AspNetCompatibilityRequirementsMode.Allowed)]
3.3. в веб.конфиге прописать
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" ... />
обычные описания доступных сервисов должны быть на месте.
После этого сервисы будут видимы и можно будет отлаживаться в обычном порядке.
Еще небольший моментик к сервисам...
Есть у билли в документации упоминание об способе адресации к корневому каталогу сайта.
Т.е. говорится, что если где-то используется :
string RootDir = "~";
string fullpath = System.Web.Hosting.HostingEnvironment.MapPath(RootDir);
то fullpath будет содержать полный путь к корню сайта на физическом диске.
Так вот - не верьте билли.
Для кода исполняемого в "виртуальном приложении" путь будет не к корневой директории сайта, а к корневой директории "виртуального приложения".
Как сослаться на корень сайта из кода "виртуального приложения" Я пока не смотрел - просто подмапил нужную мне папочку в приложение.
Но приложений у меня несколько, а работать они должны с одной и той же папкой.
Так что вместо мапа в корневой каталог, придется мапить в каждое приложение. 
Еще одна нособойка.
Имеем ВЦФ-сервис работающий под ИИС.
Сервису надо возвращать некоторый комплексный тип.
Для примера возьму с мелкомягкого сайта:
[DataContract] public class CompanyLogo { [DataMember] private string ShapeOfLogo; [DataMember] private int ColorOfLogo; }
пока этот тип лежит в дллке сервиса - все работает.
Мне, однако, хочется его поиметь в отдельной библиотеке.
И вот как только - так сразу вываливается несовпадение кодировок техт/хмл => техт/соап+хмл...
Ну и как тут быть? Мне класс шарить хочется... не с сервисом и без клиента...
Ну расскажи мне как пользоваться гооглем.
Только вот интересует меня не что надо поправить чтобы можно было работать - новый биндинг прописать не проблема, а причина, по которой появляется необходимость это дело менять - местоположение кода роли играть не должно, но ... играет.
Еще одна мелкая непонятность в WCF,
Имеем простой класс в качестве передаваемого объекта из веб-сервиса на клиента. (упрощено)
[DataContract]public class TPartialReport{
[DataMember]public List<TFile> Files2 { get; set; }[DataMember]public TFileList Files4 { get; set; }
}
В полиси прописано, что в бизнес-логике должны использоваться только пользовательские типы.
Первый ДатаМембер этому требованию не соответствует. Собственно по-этому и вводится второй.
TFileList определен как [DataContract] public class TFileList : List<TFile> {}.
Вопросик - Так какого рожна после замены меняется требование к типу контента - хмл =>соап+хмл?
Ну и вопросик второй - Как оформить Список/Массив для ДатаКонтракта? Чтобы не появлялся соап...
тогда и спрашивай там, где его писали
------
Ответь проще - "И я не знаю".... Я такое вполне пойму.
А вообще - интересно - существует ли механизм перекачки данных об наследовании?
Функциональность в рамках WCF не перекачивают - это понятно.
А вот простое наследование от хорошо известных базовых типов?
Как обойти - Я придумал, но многовато писанины и сложное соглашение об наймспейсах...