Хочу, чтобы файл был доступен по адресу, например, "aaaa.com/robots.txt". Делал по этой статье , а получил 404. В комментариях к этой статье сказано, что надо сделать runAllManagedModulesForAllRequests="true" в вебконфиге - ну так оно у меня и так стояло.

Конкретно, мой код:

контролллер:




представление:




маршрут (в Global.asax):




В маршруте надо обратить внимание на URL "robots.txt". Это такое требование, что роботы поисковых машин хотят обнаружить этот файл в корне сайта, поэтому путь к этому файлу должен быть именно таким. Подскажите, пожалуйста, как в контексте контроллеров и действий в ASP.NET MVC сделать доступ к этому файлу "как бы из корня сайта".

авторХочу, чтобы файл был доступен по адресу, например, "aaaa.com/robots.txt"
Добавлю, что по адресу "aaaa.com/Home/Robots" файл доступен.

handmadeFromRuМСУ, зачем гадать если бы да как бы? если в бд да экшен 100%, если в файловой то смысла нет огород имхо.
robots.txt у меня не хранится в файловой системе (хотя раньше хранился там). Я отдаю его представлением, а в контроллере пишу Response.ContentType = "text/plain"; - как в первом посте описал. Это что-то меняет?

hVostt


должно идти до основного роутинга ("Default")
Спасибо, это сработало.

МСУuser7320robots.txt у меня не хранится в файловой системе ...

handmadeFromRu
Ну что, продолжим разговор по поводу "включения задней"?
Не надо ссориться, вам же ещё вместе пиво пить и в с..не ш... е..ть. ))

Лучше давайте переключимся на

hVosttuser7320,

плохая идея runAllManagedModulesForAllRequests="true"

Я вот тут почитал, что перформанс импакт будет не такой уж большой. Ну, в смысле, что манагед модулес загружаются и так на всякий запрос к контроллеру, а будут ещё и на запросы к файлам стилей, скриптов, картинок из файловой системы и т. п. Ну и плохо это или нет? Я так понимаю, будучи раз загруженными, они уже висят в ОЗУ в виде кеша и навряд ли их оттуда что-то уберёт, если они требуются постоянно (сервер же непрерывно работает и отвечает на запросы ко всяким контроллерам). Ну, будет импакт при первом запуске, но ведь это же Дотнет - он, как и Джава, сначала должен "разогреться", а потом летать.

Ну и наконец, у меня сборок-то пока не так уж много:

<add assembly="System.Web.Abstractions
<add assembly="System.Web.Helpers
<add assembly="System.Web.Routing
<add assembly="System.Web.Mvc
<add assembly="System.Web.WebPages
<add assembly="System.Data.Entity
<add assembly="WebMatrix.Data
<add assembly="WebMatrix.WebData

Неужто будет импакт?

Кстати, не знаю, важно это или нет, но из всего совета я сделал только то, что маршрут зарегистрировал до дефолтного, и этого оказалось достаточно. Я так понимаю, что если файл не в файловой системе, до хендлер не поможет? Дело в том, что если я его помещу в файловую систему, то и без этого хендлера и маршрутов с контроллерами всё работает. Только не спрашивайте, почему я не помещаю его (и ещё два подобных файлика - от Гугла и Яндекса) в файловую систему - это сложилось исторически и мы свято чтим традиции предков.

МСУuser7320Я вот тут почитал, что перформанс импакт будет не такой уж большой.
И тем не менее, зачем нужны ненужные работающие модули на сайте?
Я, наверное, не понимаю. Объясните, пожалуйста, что означает "ненужные модули"? Это же будут модули из списка assemblies в вебконфиге? А они все же нужны. Я правильно понимаю , как работает asp.net mvc на сервере? Т. е. модули при первом запросе к ним кешируются в ОЗУ, подобно PresentationFontCache в WPF? Разве так уж много займут в памяти несколько модулей, которые могут понадобиться только раз 10 в сутки? Или ничего не кешируется и всё как в PHP - на каждый запрос грузим все модули, а потом их убиваем (сборщиком мусора, например)?

МСУuser7320, Don't use runAllManagedModulesForAllRequests="true"
А зачем автор там советует добавить именно модуль "UrlRoutingModule-4.0"? Я сделал по его совету и у меня заработало, но почему именно этот модуль?

МСУuser7320, чисто совпадение.
Не, я, конечно, прочитал эту штуку , но в том-то и непонимание: почему, чтобы исправить ситуацию, надо всего лишь добавить один модуль, который и обрабатывает маршруты? Почему этого не сделали раньше и автоматически? И как раньше работал сайт, без этого модуля (и без runAllManagedModulesForAllRequests="true")?

МСУuser7320, Don't use runAllManagedModulesForAllRequests="true"
А кто-нибудь пробовал то обновление , что в комментах по ссылке МСУ нахваливают? И почему оно "even better solution"?


И ещё вопрос. Вот там автор поста пишет:

авторIt is true that some modules will not be fired on MVC pages without the runAllManagedModulesForAllRequests="true" but this is why those modules should be added into added into the modules section (with preCondition="").
А как я узнаю, что не запущен такой-то модуль? Какое-то исключение вадастся или ещё чего? Т. е. как я могу узнать, что нужен такой-то модуль, а он не запустился?

hVosttuser7320,

потому что через ExtensionLess можно определить конкретные пути, которые надо обрабатывать с помощью модуля. а runAllManagedModulesForAllRequests -- из пушки по воробьям.
А как вы определите, что такие-то пути должны обрабатываться с помощью такого-то модуля ? Если совсем в лоб: где найти таблицу соответствия "вид пути - модуль". Это чтобы совсем конкретный разговор вести, а не вилами по воде рассусоливать. Я вот в первом сообщении в этой теме привёл пример, что у меня 404 и всё. Я там не вижу, что "чтобы по такому-то пути пройти, надо такой-то модуль включить в обработку путей". Выдал бы этот ASP.NET исключение какое, чтоли, где бы всё подробно и было расписано.

А вот такие сообщения меня вообще в смех вгоняют. Такое ощущение, что там не специалисты, а такие же, как я, сайты ваяют: "мы установили какой-то неведомый фикс и всё как-то само собой заработало; до этого хрен знает что не работало и почему, поэтому мы всегда шли путём грубой силы - ран олл бла-бла модулес тру".