Эмпирическое правило - то, что необходимо использовать утверждения, когда Вы пытаетесь зафиксировать свои собственные ошибки и исключения при попытке зафиксировать ошибки других людей. Другими словами, необходимо использовать исключения для проверки предварительных условий на общедоступные API-функции, и каждый раз, когда Вы получаете любые данные, которые являются внешними к Вашей системе. Необходимо использовать, утверждает для функций или данных, которые являются внутренними к системе.
Возможно, что один из потоков, порождаемых методом DoWork, бросает исключение. По умолчанию в этом случае процесс завершается. Вы можете предотвратить это, используя событие AppDomain.UnhandledException , чтобы переопределить поведение по умолчанию.
не сервис контракт , который должен быть интерфейсом (что-то вроде IMyService
). Почему у вас нет явного контракта на обслуживание?
В любом случае, если ваша реализация службы также является контрактом в одно и то же время (не лучшая практика! Но возможно), тогда у вас есть две конечные точки вроде этого:
<endpoint address=""
binding="webHttpBinding"
contract="MyService" />
<endpoint address="http://azureURL"
binding="webHttpRelayBinding"
contract="MyService" />
<endpoint address="http://someURL"
binding="myBinding"
contract="MyService" />
Затем вам нужно добавить немного туда и сюда (определить «базовый адрес» службы, дать службе имя и т. Д.), И в итоге должно получиться что-то вроде:
<system.serviceModel>
<bindings>
<customBinding>
<binding name="MyBinding">
.. define the parameters of your binding here
</binding>
</customBinding>
</bindings>
<services>
<service name="YourNameSpace.MyService">
<host>
<baseAddresses>
<add baseAddress="http://localhost:80/" />
</baseAddresses>
</host>
<endpoint address=""
binding="webHttpBinding"
contract="MyService" />
<endpoint address="http://azureURL"
binding="webHttpRelayBinding"
contract="MyService" />
<endpoint address="http://someURL"
binding="myBinding"
contract="MyService" />
</service>
</services>
</system.serviceModel>
Теперь все, что вам не хватает определено ли поведение - я оставлю это в качестве упражнения для плаката: -)
Это хоть как-то помогает?
Что касается ссылок - хммм ..... трудно сказать .... Я думаю, обычные книги ("Изучение WCF" от MLBustamante для начинающих / среднего уровня, "Программирование WCF" от Juval Lowy для среднего / продвинутого) - мой лучший выбор, да и вообще большой опыт. Я не знаю ни одного источника, который явно показывает и учит, как преобразовывать настройки в коде и конфигурации - две упомянутые книги обычно показывают оба пути, и из этого вы можете понять это самостоятельно.
Marc
Проблема с некорректным распознаванием файла конфигурации может быть решена.
Просто нужно было добавить
ServiceHost h = new ServiceHost(typeof(MyService));
h.Open();
в мой код, я подумал, что ServiceModel запустит службу автоматически, поскольку она знает всю информацию. Как-то странно, что вы добавляете информацию о «MyService» в файл конфигурации, а затем также должны указывать ее в коде.
Однако реальный ответ на мою проблему дал marc_s, который описал весь процесс преобразования из программный подход к файлу конфигурации очень хорошо.