Здравствуйте, HotDog, Вы писали:
HD>Аргументирует это тем, что все работает так как оно сейчас есть.
HD>И переделывать клиентский софт, чтобы решить какие то внутренние, серверные проблемы — плохое решение
Скажи клиенту, что нужно оптимизировать общую сложность решения задачи.
Ибо простые изменения на клиенте и сервере это лучше чем нетронутый клиент и тонна геморроя и костылей на сервере.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Здравствуйте, para, Вы писали:
P>заодно и в билд-процесс встроили
Проверил этот метод. Если в двух словах — не работает. Вернее работает не всегда.
Компилятор в процессе оптимизации (состояние чекбокса "Optimize code" в настройках проекта роли не играет) создает статический класс вида
[CompilerGenerated]
internal class <PrivateImplementationDetails>{12212EB7-C14C-4369-8C9C-659AE2FA2A49}
{
.....
}
в который выносит к примеру статичные массивы. Т.е. если у меня в коде есть следующая строка
bl.Factors = new float[] { 0f, 0.4f, 0.56f, 0.68f, 0.77f, 0.82f, 0.89f, 0.92f, 0.95f, 0.98f, 1.0f };
то этот bl.Factors будет инициализирован статической переменной из [CompilerGenerated] кода.
Название этого класса меняется при компайле (GUID меняется), естественно и IL code тоже меняется раз от раза.
Можно было бы конечно и вручную произвести подобную оптимизацию, вынести подобные вещи заранее в нами созданный класс,
но кто знает что будет прооптимизированно после установки сервис пака (апдейт компайлера)
или при использовании каких либо иных конструкций языка.
Т.е. никаких гарантий, что мы не "зевнем" какие то важные изменения.