Azure в Role Cache и Windows Server AppFabric Cache в одном решении
Мы переносим приложение Azure в локальные дата-центры. При развертывании пакета Azure в облачных службах нам необходимо использовать Azure в Role Cache. При локальном развертывании на Windows Server нам нужно использовать Windows Server AppFabric Cache. Как заставить его работать в одном решении?
Детальное объяснение
Мы подключаемся к Azure в Role Cache с клиентскими сборками Azure SDK v 2.2.
Microsoft.ApplicationServer.Caching.Client.dll, assembly version 1.0.0.0, file version 1.0.5137.0
Microsoft.ApplicationServer.Caching.Core, assembly version 1.0.0.0, file version 1.0.5137.0
Мы подключаемся к Windows Server AppFabric Cache v 1.1, используя клиентские сборки, поставляемые с установкой.
Microsoft.ApplicationServer.Caching.Client.dll, assembly version 1.0.0.0, file version 1.0.4632.0
Microsoft.ApplicationServer.Caching.Core, assembly version 1.0.0.0, file version 1.0.4632.0
Проблемы с видением сборок решаются в Windows Server AppFabricCache, Исключение, Проверка потока версии клиента.
Проблема в том, что наш основной веб- проект заканчивается ссылками на все упомянутые сборки, которые имеют повторяющиеся имена и версии. Мы не хотели бы взламывать наш путь через это. Варианты от худшего до не очень плохого - создать пользовательскую загрузку сборки или изменить процесс сборки. Какой предпочтительный способ? Разве мы сбились с пути?
2 ответа
Вы не можете использовать библиотеки Azure SDK и локальные библиотеки в одном проекте для кэширования. Для локального использования вам необходимо использовать клиентские библиотеки, находящиеся в папке установки, а для in-role - библиотеки Azure SDK.
Если причина вашего переезда заключается в том, что сервер и клиент привязаны к одному и тому же проекту, я бы предложил использовать управляемый кеш - новое решение GA, в котором вы можете использовать тот же клиент, который вы используете для роли, с минимальными изменениями уровня конфигурации, чтобы он работал, Здесь SLA времени работы сервера и т.д. управляется самой сервисной командой, так что вам не нужно об этом беспокоиться.
Если вы хотите полностью перейти на локальный сервер, то да, тогда Appfabric for windows server является лучшим решением. Но в целом я видел сайты, на которых есть трафик со всего мира, пользующихся их лазурным решением для кеша. Но вы бы лучше знали ваши сценарии:)
Вы можете использовать как библиотеки Azure SDK, так и локальные библиотеки в одном проекте для кеширования, но это подделка. Это значит, не очень хорошая идея. Попробуйте вместо этого использовать Redis.
Я продолжу с плохим советом.
Должны существовать две конфигурации сборки. Один для лазури, а другой для премьера. Процесс предварительной сборки должен быть закален. Например добавьте msbuild xml или запустите сценарий после сборки, который заменит DLL-библиотеки Azure, развернутые по умолчанию, на предварительные библиотеки. Публикация для on-prem тоже должна быть изменена. Проверьте этот указатель: цель AfterPublish не работает.