Здравствуйте, fddima, Вы писали:

F>Здравствуйте, fddima, Вы писали:

F>Собственно на основе этого можно poor-man's lock logger прикрутить (естественно для текущей сборки).
F>Хотя я как бы и знал о возможности делать подобные извраты — никогда не делал.

F>1. Прийдется добавить в файл проекта ручками — студия зачем-то заботливо нас от этого огораживает:
F>

F>    <Reference Include="mscorlib">
F>      <Aliases>global,mscorlib</Aliases>
F>    </Reference>
F>

F>2.
F>[c#]
F>extern alias mscorlib;
F>using System;

F>namespace System.Threading
F>{
F> static class Monitor
F> {
F> public static void Enter(object obj, ref bool locked)
F> {
F> Console.WriteLine("Enter");
F> mscorlib::System.Threading.Monitor.Enter(obj, ref locked);
F> }
F> public static void Exit(object obj)
F> {
F> mscorlib::System.Threading.Monitor.Exit(obj);
F> Console.WriteLine("Exit");
F> }
F> }
F>}
Да, именно так и предполагалось использовать, только не для логов, а для рантайм проверки возможности дедлоков. (и даже больше, доказывания отсутствия возможности таковых при очередном захвате).
Из-за нестабильности эффекта вместо lock-а пришлось перейти на using, и все было ничего, пока компилятор не разрешил внутрь using-а вставлять await-ы. Теперь пришлось доказывать еще что из using-а выходит именно тот поток, что входил.

F>PS: VS2015U3
Аналогично

F>UPD: Ну вариант с "happy debug" предложенный практически изначально — я промолчу.
В заглавном сообщении меня интересовал именно факт вызова моих методов из под штатного lock-а. Понятно что без mscorlib или своего аналога это злая засада.