Неверный ответ Nancy Self Host с представлением Razor

Решено в Нэнси 0,6

Я пытаюсь получить самообслуживаемую Нэнси, чтобы вернуть вид бритвы, и я не могу заставить ее работать. Образец в исходном коде Nancy использует веб-проект, но на котором они есть, не говорит, что это необходимо. Я попытался указать разделы конфигурации, но снова они говорят: "Этот шаг полностью необязателен" (курсив мой). Прослеживание через источник не похоже, что бритва является допустимым механизмом просмотра, но я не вижу, где я могу добавить его либо в конфиг, либо в свой собственный NancyModule... Любая помощь будет оценена.

View Engines

Когда я, наконец, выяснил, что они ищут в папке представлений, кажется, что cshtml является поддерживаемым расширением, но DefaultViewFactory не имеет связанного с ним механизма представления, поэтому я получаю null:

enter image description here

Мой код:

public Module1()
{
    Get["/me"] = parms =>
    {
        return View["Static.html"]; // WORKS!
    };
    Get["/you"] = parms =>
    {
        dynamic model = new ExpandoObject();
        //return View["~/Static.cshtml", model];
        //return View["/Static.cshtml", model];
        return View["Static.cshtml", model]; // blank page, no error or anything
    };
}

Static.cshtml - это просто html-страница, в которой говорится: "Привет, мир!"

Ответы

Ответ 1

Консоль, форма и проекты wpf определяют файлы просмотра в том же месте, что и исполняемый файл. это означает, что вы должны скопировать файлы view.cshtml в папку bin\debug проектов, чтобы работать в режиме отладки.
Итак: пометьте ваши .cshtml файлы как копии для вывода

Ответ 2

Я выяснил одну часть моей проблемы: сборка бритвы не была загружена в мой AppDomain, когда я создал свой NancyHost. NancyHost имеет TinyIoc-сканирование и создает список всех классов во всех загруженных сборках, когда он запускается, и этот список никогда не обманывается. Я исправил его, создав RazorViewEngine, чтобы заставить сборку загружаться. Использование вызова Register() также работает, но я думаю, что только потому, что он заставляет сборку загружаться, я думаю, что у Nancy есть свой собственный контейнер. Все эти местоположения работают, но это все еще не работает, если я поместил его в свой NancyModule:

//TinyIoC.TinyIoCContainer.Current.Register<RazorViewEngine>(); // WORKS
//RazorViewEngine rve = new RazorViewEngine(); // WORKS
m_Host = new NancyHost(m_Uri);
//TinyIoC.TinyIoCContainer.Current.Register<RazorViewEngine>(); // WORKS
m_Host.Start();
TinyIoC.TinyIoCContainer.Current.Register<RazorViewEngine>(); // WORKS

Если кто-то захочет перезаписать этот ответ и выяснить более чистый способ или лучшее решение, я приму ответ.

Ответ 3

У меня была похожая проблема с nancy 0.8.0 и Razor. У меня были Nancy, Host.Self и ViewEngine.Razor загружены и установлены, и ссылки.

Однако при компиляции компилятор не смог найти пространство имен Razor в Nancy.ViewEngines.Razor(событие, хотя браузер объектов и рефлектор показал, что пространство имен и типы отлично подходят), я выполнил все нормальные ссылки на пространство имен vodo; чистить, удалять, добавлять, pm неустанавливать, устанавливать время, вручную перемещать dlls в корзину, надеть мою счастливую скомпилированную шляпу, плюнуть три раза на левое плечо и так далее, но все же получило тот же результат. Никакая Razor не загружена в AppDomain...

Я вернул ручную загрузку сборки в appdomain и использовал активатор для создания экземпляра типа RazorViewEngine для контейнера Tiny.IoC factory.

Фактическая проблема заключалась в том, что проект запуска моего решения был нацелен на профиль клиента .NET Framework 4. По-видимому, клиентский пакет .Net не может потреблять и просматривать некоторые части для dll, скомпилированных для полной версии 4.

В любом случае. Изменено мое построение на "нормальный".NET 4, и все возвращается к норме. Компилятор находит типы в пространстве имен, а Tiny.IoC способен подключить все.