Как отладить вызовы дистанционной работы.NET?
Вы можете использовать:
[ApiExplorerSettings(GroupName = "Group")]
public class SomethingController : Controller
{
И в декларации
services.AddSwaggerGen(options =>
{
options.SwaggerDoc(version,
new Info
{
Title = name,
Version = version
}
);
options.DocInclusionPredicate((_, api) => !string.IsNullOrWhiteSpace(api.GroupName));
options.TagActionsBy(api => api.GroupName);
});
4 ответа
Оказывается, инфраструктура удаленного взаимодействия .NET использует .NET ThreadPool (или совместно использует базовый ресурс), поэтому вызовы удаленного взаимодействия могут зависать, если все потоки ThreadPool используются вашим приложением.
Я не уверен, поможет ли это (я не могу сказать, является ли это Вашей проблемой или не), но если Вы хотите отладить свой сервис как его выполнение, можно хлопнуть это по коду:
#if DEBUG
if (!System.Diagnostics.Debugger.IsAttached)
Debugger.Launch();
#endif
и Вы получите диалоговое окно, прося, чтобы Вы выбрали отладчик. Простой способ присоединить к рабочему экземпляру сервиса. Если ничто иное, это позволит Вам ворваться в свой сервис, когда UI зависнет (путем нажатия кнопки паузы на панели инструментов отладки), и проверьте потоки и стек вызовов.
Это не может быть исключительно полезно, но я брошу его туда так или иначе.
При отладке сервисов и клиентов, которые говорят через дистанционную работу, я буду обычно всегда выполнять два экземпляра отладчика: один для клиента и один для сервиса. Только, чтобы быть ясным, я выполняю две копии Visual Studio. Для сервиса можно использовать команду присоединения, или можно изменить основное, и вызов запускаются непосредственно (обходящий весь служебный код).
Вот то, как я обычно позволяю отладить путем изменения основного, Вы будете иметь к, и DebugService призывают к сервису, это действительно - просто точка входа, которую запускают вызовы. После того как у меня есть это, я просто включаю сервисную отладку definine SERVICE_DEBUG или изменение #if путем добавления'!'. Теперь Вы в основном преобразовали свой сервис в консольное приложение.
#if SERVICE_DEBUG
ServiceHost s = new ServiceHost();
s.DebugService();
Thread.Sleep( 300000000 );
#else
ServiceBase.Run( ServicesToRun );
#endif
После того как у Вас есть и установка и выполнение Вас, может ступить через клиент, когда вызовы дистанционной работы поражают сервис, можно ступить через служебный код, позволив Вам отладить обоих одновременно.
Из любопытства Вы называющий удаленный объект непосредственно от потока GUI? Если так, поток GUI заблокируется, пока вызов дистанционной работы не завершается. Это запрет целый GUI и сделает его безразличным. Это не решение проблемы, но если это будет иметь место, и Ваш сервисный поток не возвращается, то это заставит GUI зависать также.
Несколько лет назад я разработал и реализовал критическую бизнес-систему, которая использовала Дистанционную работу.NET. Нам реализовали клиент как GUI Windows Forms, сервер, реализованный как служба Windows и база данных SQL Server.
Я разработал для поиска и устранения неисправностей/отладки/разработки, таким образом, один из моих первых критериев расчета был то, что я мог тривиально удалить всю реализацию Дистанционной работы.NET и выполнить целую систему на моем рабочем столе. Так, я мог деактивировать дистанционную работу путем изменения единственного булева параметра конфигурации на "ложь" = прочь. Я мог затем диагностировать, отладить, разработать полностью без издержек или интерференции Дистанционной работы.NET.
Кажется, что это было бы ценно для Вашей ситуации также. На самом деле, я не могу вообразить ситуацию, в которой это не желательная функция, тем более, что легко реализовать.
Так, для реализации его параметр конфигурации использовался каждым клиентом и серверным кодом для решения который класс реализации инстанцировать для связи с другой стороной. Вся коммуникация произошла через пользовательский интерфейс C#, который имел два класса конкретной реализации на каждой стороне: один класс реализовал коммуникацию с помощью Дистанционной работы.NET, другой класс реализовал коммуникацию как прямую незавершенную передачу (прямые вызовы).
Только одна пара классов (один на каждой стороне) знала что-либо о Дистанционной работе.NET, таким образом, изоляция была общей. Большую часть времени все разработчики работали с выключенной дистанционной работой, который был быстрее и более простым. Когда они должны были в редком случае, они включили его (главным образом просто меня, или когда кто-то подключенный к тесту/производству для поиска и устранения неисправностей).
Между прочим, я сделал интерфейс дистанционной работы очень простым: общедоступный Ответ выполняется (Запрос)
Кроме того, я также использовал подсказку по запуску отладчика, упомянутую выше, и я соглашаюсь, что необходимо помнить влияние на поточную обработку GUI.