А почему вы не воспользовались стандартным механизмом логгирования для MS Dynamics?
Насколько мне известно, в стандартный MS Dynamics SDK входит интерфейс ITracingService, конечно он не такой разнообразный и мощный как логгеры в NLog, но я рекомендую пользоватся им вместо NLog(это поможет избежать проблем с развертыванием на боевую систему в будущем).
Получить экземпляр интерфейса ITracingService можно вот так:
var tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
A: Неперменно. Все онлайн и оффлайн участники получат на указанный при регистрации емэйл-адрес ссылку на видеозаписи докладов.То есть, если вы участник, и на конференции успели посетить только 6-7 докладов или, например, заболели и вообще не смогли приехать — не волнуйтесь! Всё посмотрите на видео!
Для тех же, кто решил не участвовать в конфе, лучшие видео будут опубликованы через несколько месяцев после конференции.
Похоже, что это сделано в целях оптимизации. Если посмотреть в спецификацию MSIL, а именно, на пункты «II.24.2.3 #Strings heap» и «II.24.2.4 #US and #Blob heaps», то становится ясно, что сборка хранит служебную информацию в UTF-8 формате(кстати, это отностися не только к пользовательским атрибутам, но и к версии самой сборки) в специальном блоке #Strings, а пользовательские строки в формате UTF-16 в другом специальном блоке #US(похоже это акроним от user strings).
Я не очень понимаю, как из того, что данные атрибутов хранятся в метаданных сборки следует то, что строковые метаданные должны хранится в формате UTF-8 вместо UTF-16.
И как же это всё относится к C#? Ну, константы же надо как-то представлять на уровне IL. Оказывается, способов представления тут два – в большинстве случаев используется UTF-16, но для аргументов конструктора атрибута – UTF-8.
Кто-нибудь знает, почему для аргументов конструктора атрибута используется UTF-8 вместо UTF-16?
Я не очень понял аргумент насчет легаси, возможно же создание нового JIT не вместо, а как альтернатива уже имеющемуся. Т.е. по-умолчанию пусть работает как есть, а для продвинутых можно использовать другю опцию.
23derevo вы случайно не знаете, есть ли какая-нибудь статистика по тому, какой прирост производительности даёт подобная фича в Java(имеется ввиду отложенная компиляция)?
Я просто не могу понять почему MS её не реализовало? Это дорого? Это того не стоит? Лень поддерживать две версии JIT?
А можете пояснить, это какая-то особенность .NET, или возможна какая-то другая релизация JIT, которая будет использовать отложенную компиляцию кода, например как в Java?
То, что WinForms гвоздями прибит к WinApi это ясно, но я не очень понимаю, почему нельзя портировать Wpf? Wpf вроде не сильно завязан на WinApi. Кто-нибудь может прояснить ситуацию чайнику?
Ну так в этом вся соль, пока не ясно чем эти спутники будут укомплектованы, но разница масс Иридиумов(700кг) и этих спутников(100кг) довольно велика, это обстоятельство у меня(я не специалист) вызвает подозрения, что спутник не будет иметь сколь-либо значимого запаса топлива для коррекции орбиты.
Насколько мне известно, в стандартный MS Dynamics SDK входит интерфейс ITracingService, конечно он не такой разнообразный и мощный как логгеры в NLog, но я рекомендую пользоватся им вместо NLog(это поможет избежать проблем с развертыванием на боевую систему в будущем).
Получить экземпляр интерфейса ITracingService можно вот так:
Выглядит, как конфликт спецификаций C# и MSIL.
Деревья выражений дают возможность анализировать, что же находится внутри Linq запроса, а ваше дело потом решить, что с этой информацей делать.
Я просто не могу понять почему MS её не реализовало? Это дорого? Это того не стоит? Лень поддерживать две версии JIT?
Кто-то когда-то шутил о том, что RMS покусал ребят из Microsoft, похоже что это была не шутка.