Override AccountController in Individual User Accounts - asp.net-mvc

I've created in Asp .Net Core 2.1 - mvc Individual User Accounts and add scaffold identity.
I need override route Identity/Account/Register to Account/Register. I guess I need access in AccountController and add attr [Route("")].
How can i do it?. In advance thanks for help.

In the latest Identity, there is no longer an AccountController. The ASP.NET Core team have made the (controversial) decision to move everything to Razor Pages. The old Identity scaffold of authentication and account management controllers and views now exists as the "default UI", which is included by default when you use AddDefaultIdentity. That method internally calls AddDefaultUI.
To modify the default UI, you must scaffold the pieces you desire into your project, which can be accomplished via right-clicking on your project in the solution explorer and choosing Add > New Scaffolded Item... That will then give you a window where you can choose among various available scaffolds, one of which is Identity. Selecting that option will pop another window allowing you to choose which Razor Pages you would like to scaffold. You can choose any or all. Since the default UI remains included, the scaffolded pages function as overrides, so anything not included falls back to the default UI version.
If you abhor Razor Pages as I and many others do and want the old-style MVC controllers and views back, you now have no choice but to create them yourself. You can scaffold all the Identity pages into your project as a guide and then shuffle the code into your controller(s) and views. Then, simply delete the scaffolded pages when you're done. You'll also need to use AddIdentity in ConfigureServices instead of AddDefaultIdentity, or the default UI will still take precedence. It's frankly a pain in the butt, but that's how it is.

Related

Need an Automatic Editor

what I'm looking for is some something similar to the automatically generated "delete" and "Create" functions that are created in MVC. I'd like one that is used to update a record. Preferably it would work much like a gridview (I'd prefer not to mix in ASPX pages), but if it creates a separate form, I'm okay with that too.
The best way to get started is to scaffold a controller. In Visual Studio right-click the Controller folder, Add > Controller, you'll have the option to scaffold a controller with Read/Write actions or using Entity Framework. In the latter case you'll need a create model to base it on before hand.
Once you've done this have a look for the Edit ActionResult, this allows you to edit single records. It's possible to do multiple records but it take a fair bit more work.

Embedding an MVC form inside the old master template architecture

I have an old Umbraco web application which was upgraded to v6 earlier this year.
It uses .NET ascx user controls and your standard .master pages as you'd expect.
I now need to create a brand new page which is essentially a booking form for an event.
I'd like to create it using MVC, as I do everything with MVC nowadays. I don't really want to duplicate the page layout / the frame. Is it possible to embed an MVC partial view inside the old master templates?
You can create the form in a .cshtml file and then add it as an Umbraco Macro. But the form couldn't use the MVC approach, it would have to be basic inline razor plus conditional statements. Which is fine but limiting. You could of course have the form posting to a controller action too but this get's a little tricky as it takes the form processing out of the page's event cycle.
Otherwise you are asking if you can reference an action in a masterpage, so no not really. I say "not really" because of course you can but it's unnatural and would make the project a nightmare for anyone to undestand of they were to pick it up. There is an article here as to how you might do it tho': http://www.hanselman.com/blog/MixingRazorViewsAndWebFormsMasterPagesWithASPNETMVC3.aspx
Also, there is also the Umbraco MvcBridge package. This was something a lot of devs used prior to being able to build directly in MVC. Essentially you can set up Macros to point to actions etc. but still within the webforms mode.
It's a great half-way house but I'm not sure abut the compatibility with v6.

creating Entry form in Umbraco for Add/Edit/Delete/Search functions

This is repeatedly asked many times, however i couldn't find appropriate solution for my problem.
I want to create an Entry Form which will consists of following elements:
Text boxes, drop down fields (auto populated) , check boxes , radio buttons
After my research
i found that i need to create user control, or script file for above form and access it via Macro.
I don't want to use User control as my first preference is to controller-View-Model (i.e. cshtml)
I want to follow MVC approach to create above form. So
1) Do i need to create a seperate project for Add/Edit/Delete/Search Data Entry form?
2) OR i need to create cshtml file for the same(not so clear about this approach)
I'm looking this data entry form with easier for customization and i could use it in other applications as well.
From Umbraco 4.10 up to 6.0.x you can use MVC in Umbraco so there's no need to use an usercontrol. You probably want to use a SurfaceController where you can add any Action you want. The rest is standard MVC (Razor views to build your textboxes, drop downs, ...).
Check out the Umbraco MVC documentation where they explain how to use MVC in an Umbraco project.

mvc rebuild strongly typed view

is there any way to re-build a strongly typed view when the model class has new fields added?
At present I have not modified the initial generated view so deleting and re-creating is not a problem.
When I start to customize it to my liking I will lose all changes and I was wondering if there was a good way to manage this?
Thanks
ASP.NET MVC offers two types of scaffolding, each with its own advantages:
The first kind of scaffolding is design-time scaffolding, which is done through the Add View dialog and T4 templates. The advantage of this is that the code is entirely generated and you can completely customize it. The disadvantage is that if you change your model you have to regenerate your view (by deleting it and adding back a new one).
The second kind of scaffolding is runtime scaffolding, which is done through the Html.EditorFor() and Html.DisplayFor() methods in your view. The advantage of this is that if your model changes then the scaffolding will be automatically generated at runtime. The disadvantage is that you cannot directly customize the rendering. You can, however, give this scaffolding many hints using DataAnnotations attributes such as [DisplayText], [UIHint], and so forth, so it is quite flexible - but it is not nearly as flexible as being able to 100% customize the rendering.
To customize the rendering of runtime scaffolding (editor templates and display templates) you can find more info on Brad Wilson's blog series.
You can manually add code to your view to reflect any changes in the model.
Default scafolding is there just to give you something.
One thing you might want to look at is t4 templates using wich mvc tooling generates your default views. google for it there are examples of how you can copy those to your project and modify to have mvc generate views you want instead of default ones.

ASP.NET MVC RC - Creating a MVC User Control with a codebehind

Trying to create a MVC User Control in the Release Candidate and I can't see to make one with a codebehind file. The same is true for MVC View pages.
Creating Views in the Beta would produce codebehinds...am I missing something?
Code behind kind of defeats the purpose of the MVC Framework. Functionality should be kept separate from the view, the MVC team felt that code behind pages went against this ideology and therefore removed them.
Your can create a custom helper method to create your control. Also I'm not sure if MVC has view components (Monorail/Castle) but that could be an option as well.
From ScottGu's Blog post:
*Views without Code-Behind Files
Based on feedback we’ve changed view-templates to not have a code-behind file by default. This change helps reinforce the purpose of views in a MVC application (which are intended to be purely about rendering and to not contain any non-rendering related code), and for most people eliminates unused files in the project.
The RC build now adds C# and VB syntax support for inheriting view templates from base classes that use generics. For example, below we are using this with the Edit.aspx view template – whose “inherits” attribute derives from the ViewPage type:
One nice benefit of not using a code-behind file is that you'll now get immediate intellisense within view template files when you add them to the project. With previous builds you had to do a build/compile immediately after creating a view in order to get code intellisense within it. The RC makes the workflow of adding and immediately editing a view compile-free and much more seamless.
Important: If you are upgrading a ASP.NET MVC project that was created with an earlier build make sure to follow the steps in the release notes – the web.config file under the \Views directory needs to be updated with some settings in order for the above generics based syntax to work.*
I answered this question here:
How to add a Code-behind page to a Partial View
Seems this wasn't particularly tricky, and is quite do-able
This answer worked for a Partial 'ViewUserControl' but the same should apply
Ok.
First: Add a Class file with the convention of .cs (i.e. view.ascx.cs)
Second: Add "using System.Web.Mvc;" to the class
Third: Change the Class to Inherit from "ViewUserControl<>"
Fourth: Add the following to the View's header:
CodeBehind="View.ascx.cs" Inherits="Project.Views.Shared.View"
Fifthly: Copy the files out of the solution and drag back in to reassociate the two together
Note: For this to work with a Normal MVC View you just need to inherit the class from "ViewPage"
The whole idea for ASP.Net-mvc was to get rid of the codebehind files...thats why asp web controls didnt matter that most didn't work.But with the changes of getting rid of the code behind comes with a different programming style..The idea is codebehind files are EVIL:
http://stevesmithblog.com/blog/codebehind-files-in-asp-net-mvc-are-evil/
the whole idea is to make sure people remember they are using asp.Net-mvc and not asp.et web pages. take alook at this link ,it explains it a little better:
http://blog.lozanotek.com/archive/2008/10/20/Visual_Studio_Templates_for_MVC_Views_without_Codebehind_Files.aspx
I think this tutorial is what you are asking.. but not really sure what you want..

Resources