Я создал пользовательский IHttpControllerSelector, чтобы обойти некоторые проблемы с дублирующимися именами контроллеров.
В моем Global.asax.cs я звоню на FilterConfiguration.Configure и в ответном вызове добавляю строку (с конфигурацией, являющейся параметром HttpConfiguration обратного вызова):
config.Services.Replace(typeof(IHttpControllerSelector), new NamespacedHttpControllerSelector(config));
Это прекрасно работает, когда я запускаю локально, но когда я публикую в Azure, я получаю ошибки от DefaultHttpControllerSelector,я думал, что уже заменил.
Я смог определить, что код обратного вызова достигнут, поэтому мои две теории на данный момент таковы:
- Что-то в моей конфигурации Azure блокирует выполнение функции
Replace. - Через некоторое время после того, как я заменил
DefaultHttpControllerSelector на свой, что-то еще меняет его на значение по умолчанию.
Поскольку большая часть этого кода выполняется в начале жизненного цикла приложения (до того, как я могу подключить отладчик), у меня возникают проблемы с поиском эффективных способов его устранения.
Обходной путь, который я имеюсейчас пришло время «не дублировать имена контроллеров», но в интересах понимания моих инструментов было бы неплохо выяснить основную причину моей проблемы.
Что может быть причиной этой разницыповедение между локальным и размещенным на Azure кодом?Как я могу убедиться, что Azure использует мой пользовательский IHttpControllerSelector, а не возвращается к стандартному?