Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Razor Pages Module Pipeline #2599

Open
ahoefling opened this issue Feb 28, 2019 · 22 comments

Comments

@ahoefling
Copy link
Contributor

commented Feb 28, 2019

Living Document

This document is a living document and will be edited as we get feedback from community members to refine the Spec

Description of problem

There is no easy way to migrate DNN to .NET Core as Web.Forms does not exist in .NET Core. Adding support for a Razor Pages Module will support this soft migration path.

Description of solution

Add a new Module Pipeline that will be a carbon copy of .NET Core Razor Pages into the DNN Platform. The goal of this new module pipeline will to be use the EXACT same .zip installer and module code for both DNN on .NET Framework and DNN on .NET Core which will allow module developers to migrate their modules once to Razor Pages and they should work on their .NET version of DNN.

Please read the spec below for implementation details and the plan of action (which we can discuss in the comments)

The Spec

DNN Razor Pages will follow as close as we possibly can to feature parity with .NET Core Razor Pages. If you are unfamiliar with how it works please take a look at the docs from Microsoft. Every item in the Spec is a design element that is pulled from the Razor Pages implementation in .NET Core and our Proof of Concept of DNN running in .NET Core

DNN Manifest File

A minor update to the Module Loading pipeline will be needed in the ModuleControlFactory to allow a new type of file .razorpages.

Snippet Example Manifest:

<moduleControl>
	<controlKey />
	<controlSrc>DNNTAG.RazorPagesModule/Index.cshtml</controlSrc>
	<supportsPartialRendering>False</supportsPartialRendering>
	<controlTitle>RazorPagesModule</controlTitle>
	<controlType>View</controlType>
	<iconFile />
	<helpUrl />
	<viewOrder>0</viewOrder>
</moduleControl>

Module Control Properties

Property Description
controlKey
controlSrc The path to the root index.cshtml starting from the DesktopModules Folder
supportsPartialRendering
controlTitle
controlType
iconFile
helpUrl
viewOrder

note: This isn't the final spec as this is the module manifest from the existing mvc/razor pages implementation which is subject to change.

The View aka Razor Page

The view is a .cshtml Razor Page. The exact same razor syntax that you see in Razor Modules or MVC Modules. Razor Syntax (the code of a .cshtml page) is a combination of C# and HTML.

Simple View

@page
@model HelloWorld

<h1>@Model.Title</h1>
<div>@Model.Content</div>

Directives
The top of the Razor Page has several directives that are required for the page to work correctly in DNN Razor Pages

Directive Description MVP Plan
@page Required at the top of every Razor Page to tell the runtime that the page is using Razor Pages instead of MVC or other framework Must Have
@using Includes a .NET namespace to be using in the C# code included in the Razor Page Must Have
@model Binds the specific Model to the view which allows the use of @Model syntax to retrieve values of the model's properties Must Have
@inject Injects different services or objects that are registered with the Razor Pages Dependency Injection Provider Nice to Have

View Context Utilities
The DNN Platform has special utility libraries that are used throughout the different module platforms to make DNN specific API calls easier for the module developer.

API Utility Description
DnnUrlHelper Manages DNN specific URLs and routing
TBD We need feedback on required view context APIs

The Page Model

The Page Model is NOT a code behind

Every *.cshtml file in Razor Pages modules will have a corresponding *.cshtml.cs file which will inherit a DnnPageModel the base class will provide access to critical DNN, .NET Framework and .NET Core APIs depending on the runtime environment.

The Page Model simplifies binding a model to a view similar to how you would do it in MVC but with less convention based programming. The Page Model can have any number of properties on it that can be bound in the View using Razor Syntax. The properties can be assigned at Page Model Construction time or using different HTTP Handlers that are implemented in the Razor Pages spec.

Handlers
Razor Pages requires several different HTTP Handles that execute depending on the type of HTTP Method that is invoked by the client. This allows the Page Model to execute different code depending on the type of action the user is trying to accomplish. For example if the user is just trying to retrieve data the module may have a HTTP GET Method implemented on their Page Model

Handler Route Example Description MVP Plan
GET https://localhot.dnndev.me/MyModulePage/ModuleId/1234/index The basic GET HTTP Request Handler to populate the model at request time Must Have
PUT https://localhot.dnndev.me/MyModulePage/ModuleId/1234/index TBD Won't Have
POST https://localhot.dnndev.me/MyModulePage/ModuleId/1234/index The POST HTTP Request Handler to submit data to the Page Model using [BindableProperty] Must Have
DELETE https://localhot.dnndev.me/MyModulePage/ModuleId/1234/index TBD Won't Have

Routing Table
A Razor Pages module can have many pages which have many routing features. The table below documents how the folder structure in a Razor Pages Module will map to the DNN Routes

File Path Matching URL
/Pages/Index.cshtml https://localhost.dnndev.me/MyModulePage/ModuleId/1234/ or https://localhost/dnndev.me/MyModulePage/ModuleId/1234/Index
/Pages/Contact.cshtml https://localhost.dnndev.me/MyModulePage/ModuleId/1234/Contact
/Pages/Store/Contact.cshtml https://localhost.dnndev.me/MyModulePage/ModuleId/1234/Store/Contact
/Pages/Store/Index.cshtml https://localhost.dnndev.me/MyModulePage/ModuleId/1234/Store or https://localhost.dnndev.me/MyModulePage/ModuleId/1234/Store/Index

HTTP GET Page Model

public class HelloWorldModel : DnnPageModel
{
    public string Message { get; private set; } = "PageModel in C#";

    public IDnnActionResult OnGet()
    {
        Message += $" Server time is { DateTime.Now }";
    }
}

Async Handler Methods
HTTP GET Page Model

public class HelloWorldModel : DnnPageModel
{
    public string Message { get; private set; } = "PageModel in C#";

    public async Task<IDnnActionResult> OnGetAsync()
    {
        // Simulate Service call
        await Task.Delay(100);

        Message += $" Server time is { DateTime.Now }";
    }
}

HTTP Post Page Model

public class HelloWorldModel : DnnPageModel
{
    [DnnBindProperty]
    public Customer Customer { get; set; }

    public async Task<IDnnActionResult> OnPostAsync()
    {
        if (!ModelState.IsValid)
        {
            return Page();
        }

        // Simulate a database save
        await Task.Delay(100);

        return RedirectToPage("/Index");
    }
}

DNN Base Classes

DnnPageModel
The DnnPageModel provides a shared implementation of the .NET Core PageModel that will work in .NET Framework and .NET Core. This is the expected Model that the DNN Module Pipeline expects when the module is loading. If this file doesn't inherit from this class the Module will not load correctly. The DnnPageModel includes DNN specific APIs for URLs, HTTP and DNN.

An example of what the abstract base class may look like

public abstract class DnnPageModel
{
    protected DnnHelper Dnn { get; private set; }
    protected HtmlHelper Html { get; private set; }
    protected UrlHelper Url { get; private set; }
}

To get an idea on what the cross-platform DnnPageModel may look at take a look at the Proof of Concept I wrote last year. DnnPageModel. Be advised that this Proof of Concept did not implement the Razor Pages spec correctly so the code may not 100% be copied into the final solution.

Required Methods/APIs

Method/Property Name Status Description
ViewData Must Have
PageContext Must Have
HttpContext Must Have
Request Must Have
Url Must Have
RouteData Must Have
ModelState Must Have Handles model validation
User Must Have
Response Must Have
TempData Must Have
BadRequest() Must Have
Challenge() Must Have
Content() Must Have
File() Must Have
Forbid() Must Have
LocalRedirect()
LocalRedirectPermanent()
LocalRedirectPermanentPreserveMethod()
LocalRedirectPreserveMethod()
NotFound() Must Have
OnPageHandler() Must Have
Page() Must Have Returns the default OnGet() HTTP Handler
PhysicalFile()
RedirectPermanent()
RedirectPermanentPreserveMethod()
RedirectPreserveMethod()
RedirectToAction() Must Have
RedirectToActionPermanent()
RedirectToActionPermanentPreserveMethod()
RedirectToActionPreserveMethod()
RedirectToPage() Must Have
RedirectToPagePermanent()
RedirectToPagePermanentPreserveMethod()
RedirectToPagePreserveMethod()
RedirectToRoute()
RedirectToRoutePermanent()
RedirectToRoutePermanentPreserveMethod()
RedirectToRoutePreserveMethod()
SignIn() Research
SignOut() Research
StatusCode()
TryValidateModel()
Unauthorized() Must Have
Redirect() Must Have
TryUpdateModelAsync()

DnnBindProperty (Attribute)
Provides the DNN Wrapper for binding properties to be used on POST HTTP requests. This needs to be included as a wrapper as the behavior doesn't exist in .NET Framework.

IDnnActionResult
This is kind of an unknown at this point as this has been used with different names and purposes throughout the MVC pattern and the Proof of Concept.

This is a placeholder that needs to be flushed out more and how it will work between .NET Framework and .NET Core.

Dependency Injection

This is a placeholder and needs to be flushed out. It will not be included in the 9.4 release

Razor Modules vs. Razor Pages Modules

With the addition of a new Module Pipeline we will now have 2 module types that have very similar names and it will be our job as Open Source Maintainers to document this as best as we can. I am open to ideas on reducing the confusion here but I don't see any way around calling this new module pattern Razor Pages Modules as this is the name Microsoft uses.

Razor Modules are an existing Module Pipeline that uses a simple .cshtml or .vbhtml view and optionally a model binding. See "Why can't we use Razor Modules?" below for more info on why we can't use it

If you want more information on the existing Razor Module Platform take a look at the DotNetNuke.Web.Razor library in the Platform Code

Description of alternatives considered

This was originally an effort that I undertook in March of 2018 and was put on hold for several reasons. By taking our time considering how the implementation works we have learned quite a bit. The initial implementation was written as a fork of the MVC Module Platform which I don't think is appropriate anymore.

The new Razor Pages Module Platform will be a combination of the Razor Module Platform and the MVC Module Platform as they both have things that will be needed to accomplish this. The code we originally wrote in 2018 will still be useful, but some things will not be.

Take a look at what we did last year:

Again, some of this code will be re-used and some of it will be scrapped as we work towards a lean Razor Pages implementation in DNN.

Why can't we use Razor Modules?

I am glad you asked why can't we just use the existing Razor Modules that already exist in DNN today. This is a great question and I asked myself this as I was researching the DNN Module Pipeline.

Razor Modules are tightly coupled to several System.Web objects and will not work in a .NET Core implementation. Since there are many modules in the field that use Razor Modules I believe it is best to not create any breaking change for them.

The Razor Module pattern will be leveraged as it has the building blocks for completing a Razor Pages Module Pipeline

Migration Plan

Razor Modules

#2613 Deprecates the existing Razor Module pattern. As we move forward with the spec and the implementation, we will document here how to migrate from an existing Razor Module to Razor Pages.

Screenshots

Not Applicable

Additional context

Add any other context about the feature that may be helpful with implementation.

Affected version

  • 9.4.0

Affected browser

  • Chrome
  • Firefox
  • Safari
  • Internet Explorer
  • Edge

Implementation Plan

The plan is to create the Razor Pages Module Platform as an Experimental Feature Toggle for DNN 9.4 and have it turned off by default. This will allow developers to start testing it out and provide feedback as soon as possible.

<appSettings>
  <add key="Experimental:RazorPages" value="false" />
</appSettings>

When you turn on Razor Pages it will disable existing razor modules since the ControlSrc conflict

When we have determined Razor Pages is production ready we will remove the feature toggle

Linked Work Items

This new feature may be too large to complete in one Pull Request and we should break it down to Linked Work Items to make it more manageable. As we create the linked work items we should add to the table below

Work Item # Target Release Completed
#2613 9.3.1 PR Submitted #2618
#2615 9.4.0 PR Submitted #2644
#2619
#2637 9.3.1 PR Submitted #2638
@mitchelsellers

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

This looks awesome. Two primary questions.

1.) For the page base, is there anything in .NET Framework that we should follow? Ideally, I'd love to not have anything too DNN specific in favor of injecting like what is done with .NET Core as a standard. (Think SignInManager, IHttpContextAccessor, etc.)

2.) Lets be sure when we implement to find a way to keep the files as .cshtml files, for VS/VS Code editor support etc.

@ahoefling

This comment has been minimized.

Copy link
Contributor Author

commented Feb 28, 2019

@mitchelsellers thanks for the feedback, to answer your questions:

  1. Take a look at POC PageModel as we used preprocessor directives to use different code for .NET Core vs .NET Framework. In the case of the PageModel I don't see an easy way around it and think we should have our own base class. As far as the APIs we can utilize a form of Dependency Injection so they can be included. If you look at the Directives table the plan as of right now is to include @inject for the .cshtml files.

    1. There are going to be some files that require a shared Dnn Base Class, but our goal is to try and make this as lean as possible.

    2. To further illustrate my point for needing a DnnPageModel take a look at the PageModel class that exists in .NET Core. Just about every property and method that exists there need to be replicated into our DnnPageModel. Anything that goes outside the scope of the PageModel should be injected and that I 100% agree.

    3. I don't think we are going to be able to identify every class that needs a base class right now, I wrote this up with pretty much a base class for everything to cover our basis as we develop this and realize certain things will need a base class.

  2. Making sure the files support VS/VS Code editor is at the top of the list.

Shared Services

Since we want the developer to be able to inject certain services do we have a small list of items we want injected?

@ahoefling ahoefling changed the title Add Razor Pages Module Pipeline (DRAFT) Add Razor Pages Module Pipeline Mar 1, 2019

@david-poindexter

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

Fantastic work on this @ahoefling - exciting times!

@bdukes

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2019

I would love it if the controlSrc could just point to the cshtml file. I had never heard of the Razor Module Pipeline before this RFC, and a quick GitHub search indicates it's not in use in any OSS module. Do you know of specific modules using the Razor Module Pipeline?

Regarding the PageModel base class, it appears that all of its properties are either coming from PageContext, which we could inherit from, or are coming via dependency injection, so we could override any behaviors that way. It would be amazing if it was possible to avoid having our own wrappers of these base types.

Thanks for your work on all of this @ahoefling, looking forward to seeing it all ironed out!

@bdukes

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2019

Also, there's one recurring thought I've been having that I'll just lay out here in case it piques anyone's interest. Something that Andrew's demo last year highlighted was that, while you can target .NET Standard, you still need to have separate packages for .NET Framework and .NET Core, b/c the dependencies won't end up being the same. I'm wondering if we could create a new packaging system that used NuGet, which would allow a module package to be just a NuGet package, and then DNN would be able to unpack it and grab the right versions of assemblies. This would also give us 1️⃣ dependency management (e.g. my module depends on this other module, or some library, etc.) and 2️⃣ a simple means of hosting a collection of extensions that are available to install based on those dependencies (i.e. we can just stand up a NuGet server, and easily configure the site to be able to look at extra third party servers, or the main NuGet feed for libraries, etc.).

If there's interest in that idea, I suppose it should be spun off into its own RFC. @ahoefling, from your perspective, does that sound like it would make packaging/distributing/deploying simpler for Razor Pages Modules?

@mitchelsellers

This comment has been minimized.

Copy link
Contributor

commented Mar 4, 2019

@bdukes If I could love this more times I would....a module as a NuGet package would be epic in my opinion

@ahoefling ahoefling referenced this issue Mar 7, 2019
1 of 1 task complete
@ahoefling

This comment has been minimized.

Copy link
Contributor Author

commented Mar 7, 2019

@bdukes

I would love it if the controlSrc could just point to the cshtml file.

I spoke with @mitchelsellers about this and we agree it will be best to deprecate Razor Modules and I just created #2613 which will deprecate it. This means we can update the module definition to use .cshtml instead of .razorpages. What we can do is if someone turns the feature toggle on it will disable Razor Module and turn on Razor Pages Modules. I will update the spec to reflect this change.

@bdukes

It would be amazing if it was possible to avoid having our own wrappers of these base types.

I 100% agree with this statement and there are going to be cases where we can't get away from wrappers such as the DnnPageModel. I wrote the original spec to wrap everything originally because at this point in time we don't know what need wrappers and what doesn't. As we create issues that implement those features we can determine what is needed and update the spec here.

@bdukes

If there's interest in that idea, I suppose it should be spun off into its own RFC

I 100% support this idea and think you should create an RFC to further investigate it

@bdukes

@ahoefling, from your perspective, does that sound like it would make packaging/distributing/deploying simpler for Razor Pages Modules?

Creating a NuGet package to use for our extension installer won't really help or hurt Razor Pages Modules. While we need to define the installation process more in the spec the working idea I have doesn't require .NET Framework or .NET Core assemblies in the module. The module will reference 100% .NET Standard assemblies and when the module is installed into DNN it will have the expectation that the .NET Framework or .NET Core assemblies will already be there.

@stephen-lim

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

Hi @ahoefling @bdukes

DotNetNuke.Web.Razor was heavily promoted as the new way to develop SPA modules. See blog post. I know many other developers built all kinds of things around it.

We use rely on it heavily to render Razor in a SPA setup for a very large module with hundreds of thousands of lines of code. It's extremely useful because it allowed us to gradually migrate one page at a time mixed in from legacy Web forms without rewriting a new module. I'm concerned the removal of it will break badly without leaving sufficient time to migrate to Razor Pages.

Can you please suggest a solution?

@mitchelsellers

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

@stephen-lim Just to make sure that I understand, you are using the API's in DNN to take a .cshtml file and give it a model to render to HTML?

If so, this is something that you can, and should, use the pure Razor libraries for. I know that @mikesmeltzer was talking about a potential blog post if this is the case to outline how to accomplish this.

@stephen-lim

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

@mitchelsellers Yes, but it's a lot more than just a RazorEngine type of thing. We need to use many helpers in the Razor library that make this step usable in SPA:

DotNetNuke.Web.Razor.Helpers.DnnHelper
DotNetNuke.Web.Razor.Helpers.HtmlHelper
DotNetNuke.Web.Razor.Helpers.UrlHelper

@ahoefling

This comment has been minimized.

Copy link
Contributor Author

commented Mar 22, 2019

@stephen-lim this is a big concern and I don't want to place any problems on your team or organization as a migration can be quite time-consuming.

@stephen-lim

Can you please suggest a solution?

We already have a migration plan that is pretty lightweight and you can implement it today even if you aren't on the latest version. I just submitted a similar solution to #2638 which is my official recommendation for a migration plan.

private StringWriter RenderTemplate(string virtualPath, dynamic model)
{
    var page = WebPageBase.CreateInstanceFromVirtualPath(virtualPath);
    var httpContext = new HttpContextWrapper(HttpContext.Current);
    var pageContext = new WebPageContext(httpContext, page, model);

    var writer = new StringWriter();

    if (page is WebPage)
    {
        page.ExecutePageHierarchy(pageContext, writer);
    }
    else
    {
        var razorEngine = new RazorEngine(virtualPath, null, null);
        razorEngine.Render<dynamic>(writer, model);
    }

    return writer;
}
@stephen-lim

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

@ahoefling In your example, how would the Razor code access the DNN Helpers to provide context for page building? This is a key requirement

@ahoefling

This comment has been minimized.

Copy link
Contributor Author

commented Mar 22, 2019

@stephen-lim

We need to use many helpers in the Razor library that make this step usable in SPA:

DotNetNuke.Web.Razor.Helpers.DnnHelper
DotNetNuke.Web.Razor.Helpers.HtmlHelper
DotNetNuke.Web.Razor.Helpers.UrlHelper

This is great insight as to things you need.

@mitchelsellers the APIs referenced are duplicated throughout the different module pipelines. Outside of the UrlHelper (which needs to be specific between the pipelines) we should be able to abstract those out so each module pipeline uses a shared instance. I'm not trying to add more work for us, but it could be worth the investigation.

Another thing to consider with the deprecation of the Razor library we plan to support very similar functionality using Razor Pages which will be built on top of the same fundamental technology. As we flush out the API we will make sure to have these APIs included. We are hoping to get some experimental features available soon in 9.4.0 where we will have a very good idea on the migration plan.

We are trying to make this migration from Razor Engine to Razor Pages to be as simple and painless as possible.

@stephen-lim when we get the experimental feature added to 9.4 could you test a migration for us to see if it covers your needs?

@stephen-lim

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

@ahoefling Yes, i'll be happy to test.

@mitchelsellers

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

@ahoefling 100%, the conversation thus far is that we will need to look at new ways to get access to the same information.

Looking at this quickly

  • DNNHelper - This is literally a wrapper around ModuleInstanceContext - I believe the "future" way to use this would be to have it included with an injection, rather than a static call
  • HtmlHelper - Really this provides access to localization, as the "raw" option has other methods. - In the future I believe this could either be rolled into an injection, or really for standardization should be part of the ModuleInstanceContext, as it is the "LocalResourceFile" that is needed
  • UrlHelper - Again, really this is just a wrapper to a few global calls, that could be done using other methods with the ModuleInstanceContext class

We have a lot of duplication, if we plan to get to .NET Core, it will be sad, but a reality that to have a quality product that is easy to understand we will need to get rid of some duplication and "less than perfect' implementations. The goal here is to make notes EARLY to try and identify usage, as we don't have any method to actually report on said usage.

@ahoefling

This comment has been minimized.

Copy link
Contributor Author

commented Mar 22, 2019

@mitchelsellers I love your idea hear of moving toward Dependency Injection for these APIs. While related to this work I don't think it needs to be part of the spec. Once we get the .NET 4.7.2 we need to start building a spec on Dependency Injection on how we see it being implemented.

@stephen-lim once we figure out the Dependency Injection story we can flush out how it will work with Razor Pages. Here is how I see it working without looking at the API to give everyone a quick idea

@injects DnnUrlHelp
@injects HtmlHelper
@injects DnnHelper

@* the rest of your cshtml markup goes here *@

Using the @injects directive in a .cshtml is a standard built into the razor spec from microsoft which will be supported in .NET Core

@stephen-lim

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

@ahoefling isn't RazorEngine under DotNetNuke.Web.Razor namespace that is being deprecated?

var razorEngine = new RazorEngine(virtualPath, null, null);

@stephen-lim

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

@ahoefling In your spec above, it would be nice if the routing can be dynamically changed such that we can return Razor pages from different folder paths than set in convention (even if they have to be inside the "pages" folder) and/or support partial pages. I recall the lack of support for partial views in the initial DNN MVC implementation disappointed a lot of folks when it was announced.

@ahoefling

This comment has been minimized.

Copy link
Contributor Author

commented Mar 22, 2019

@stephen-lim

it would be nice if the routing can be dynamically changed such that we can return Razor pages from different folder paths than set in convention

There are 2 parts to this question that I want to address.

Routing Table

The routing table mentioned in the spec (copied here for your convenience) is a carbon copy of how routing works in Razor Pages. I don't know of a special route manager, it is pretty simple the route is based on where the page is located in the file system.

File Path Matching URL
/Pages/Index.cshtml https://localhost.dnndev.me/MyModulePage/ModuleId/1234/ or https://localhost/dnndev.me/MyModulePage/ModuleId/1234/Index
/Pages/Contact.cshtml https://localhost.dnndev.me/MyModulePage/ModuleId/1234/Contact
/Pages/Store/Contact.cshtml https://localhost.dnndev.me/MyModulePage/ModuleId/1234/Store/Contact
/Pages/Store/Index.cshtml https://localhost.dnndev.me/MyModulePage/ModuleId/1234/Store or https://localhost.dnndev.me/MyModulePage/ModuleId/1234/Store/Index

Return Different Views

This feature of returning a different view is something that is built into MVC and is not a feature of Razor Pages. However there is support for Redirect and RedirectToAction which will work just like they do in MVC. That means in a OnPost() method on a PageModel you can tell the server to redirect the user to a different Razor Page or a MVC Action.

@stephen-lim

This comment has been minimized.

Copy link
Contributor

commented May 25, 2019

Hi @ahoefling, the RazorHost module is used in many places and I see it has a dependency on DotNetNuke.Web.Razor, will this continue to work after v11?

@valadas

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

Hi Guys, I am trying to cleanup the backlog and assign each issue in the release we hope to resolve it (nothing set in stone, we can always change that assigned release). Should this be an item assigned to 10 or 11 or other ?

@ahoefling

This comment has been minimized.

Copy link
Contributor Author

commented Aug 6, 2019

@valadas this item should be assigned to v10. Once v9.4 reaches GA and is released I plan to start submitting PRs for the Razor Pages Implementation. The intention is to get Razor Pages into DNN for v10 in an experimental mode if it isn't ready for production. Everything is going to be behind a feature toggle so we can make that decision at the last minute.

@stephen-lim RazorHost uses the Razor Module pattern in DNN and it is marked for deprecation in v11 (#2613). However, we are going to try and identify some migration strategies so people will have a path forward.

@valadas valadas added this to the 10.0.0 milestone Aug 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.