I have a fairly big view component that I want to use in two different asp.net core MVC projects. So far I found two approaches for accomplish this:
Encapsulating it into a DLL
Making a shared (dummy) web project
What are the trade-offs between these two approaches? My view component has nested view components and it requires java-script to implement some dynamic functionality.
With ASP.NET Core 2.1 onwards you want to use Razor Class Libraries (RCL) which were designed for this very scenario.
RLC lets you create reusable UI with razor views, pages, controllers, page models, view components and data models. Added benefit is that views (even partial) are overridable by main app where the Razor markup (.cshtml file) takes precedence allowing for per-app changes without modifying the original shared component.
From the Visual Studio File menu, select New > Project.
Select ASP.NET Core Web Application.
Name the library (for example, "RazorClassLib") > OK. To avoid a file name collision with the generated view library, ensure the
library name doesn't end in .Views.
Verify ASP.NET Core 2.1 or later is selected.
Select Razor Class Library > OK.
Reference the RCL from main app (you can also make the shared library as NuGet package)
Start the application and visit /MyFeature/Page1
Read the full documentation
Related
Having recently migrated from years of web forms, I’ve built numerous dot net core razor page apps - So I’m not a complete beginner but I am struggling to understand the best way to approach one particular scenario. I have a page that captures some header information but also needs to capture some additional data that is specific to the “type” of record being edited. In webforms I dynamically loaded a user control for the relevant type using a path name (the path name of the user control being linked to the type so the system knew what form to load). With user controls I could then handle the form submission which meant the logic could be completely different for each type/form. Whereas I can use view components to create the relevant UI in the same way in my razor pages app, I can’t then handle the post back from there. So what would be the best way to approach this in razor pages? To make matters more complex, the type (and thus the objet i want to capture) could be defined in a RCL (another project). Also the type needs to be defined in a database entry, so I need to be able to load it from a string. Whereas a standalone page for each type would be easy, the management of this data is on one place in the core system so I can’t have a different page for each one.
I am building a Blazor app and I have a need to reuse a bit of code that returns teh results of a linq query. My question is where do i put general code? What is the accepted place in the structure? I've got the following folders to choose from:
Authentication
Controllers
Data
Models
Pages
Services
Shared
and then once i've got this how do i call this public method? Is it enough that it is public or do i need to create a class variable of type x? Pretty basic stuff but i'm stuck.
I've puyt the methoid in once page component/class anmd then to use it elsewhere I 've created a new new instance of the class component so i can reference the method but is this the best way?
thanks
John
If the page you are reusing has html or css then use a .razor otherwise, use a .cs
Looking at your folder structure, MVC is not a good choice to architect Blazor apps as MVC is for Stateless and Blazor is not Stateless. There are several choices on how to accomplish getting data into a component, my favorite is DI.
I am using the standard new ASP.NET Core 3.1 + Angular project template and I am trying to find the text displayed on the standard Log In page:
This is displayed at https://localhost:xxxxx/Identity/Account/Login
Searching all files in the solution for any text from this form returns no results and I am starting to think it's in a DLL or some other place I don't see. Is that the case?
Where can I modify that text?
ASP.NET Core provides ASP.NET Core Identity as a Razor Class Library. And it enables us to apply the scaffolder to selectively add the source code contained in the Identity Razor Class Library (RCL), then you can modify the code and change the behavior based on your actual scenario and requirement.
For more information about "Scaffold Identity in ASP.NET Core projects", you can refer to this doc: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/scaffold-identity?view=aspnetcore-3.1&tabs=visual-studio
This appears to have been moved into a Razor Class library, source here.
When creating a new ASP.Net Core web project in ASP.Net Core 2.0, and choosing the 'Individual account' authentication option, the authentication views/controllers where originally implemented using ASP.Net MVC. Recently it appears they have been updated to use Razor pages. My questions is...is there a way I can revert the new project template to using the MVC instead of Razor pages or at the very least is there a way I can see what code the MVC template used to create?
Simply, no. Identity now comes with a Razor Class Library containing a default UI, which as you've noted, is Razor Pages-based. If you want the old-style MVC setup, you'll need to create it yourself. You can scaffold the Default UI pages into your project and then refer to these to move code into controllers/views. Then, when you're done with that, remove the default UI pages in your project, and turn off the default UI in general by using AddIdentity<TUser, TRole> instead of AddDefaultIdentity<TUser> (which adds the default UI under the hood).
FWIW, I used to be totally opposed to Razor Pages until I endeavor the same thing you're about to embark on. After moving all the code into controllers, I started to remember how much of a mess it actually was. There's so much boilerplate code involved in auth: sign in, sign out, registration, password resets, 2FA, third-party login, etc. You end up with monstrous controllers with hundreds or even thousands of lines of code. Even if you try to break it up into many different controllers, that just kind of makes it worse. Long and short, Razor Pages actually works pretty well for something like this. It keeps each unit of functionality self-contained, so you know exactly where your need to go to edit stuff. I'd encourage you to give it a go as-is, first, and see how it works for you.
Also, one of your main concerns may be the Web Forms style of routing with Razor Pages, where you the path becomes the URL, and if you're like me, that probably offends your sensibilities. This can actually be changed, though it's not documented well at all. You can simply specify whatever route you'd like the page to have with the #page directive. For example, you could do something like following in Login.cshtml:
#page "/signin"
Then, you can access the page via /signin, instead of /Identity/Account/Login.cshtml.
From a maintenance and deployment standpoint, does it make sense to have one Web API 2 project with many (30+) controllers, or 30+ micro Web API 2 project with one controller each?
I started down the path of having them all in a single project whose structure would look like this:
Comapany.Project.Api (solution)
AccountController
OrderController
InventoryController
//many more here
AddressController
I've come to think this will be problematic when deploying since we just use a file system publish that deletes all files prior to publish. If I make a change to the orderController and have to deploy during the day to production, I will bring down many other services.
I'm about to rework my project structure to something like this:
Company.Project (solution)
Company.Project.AccountApi
Comapny.Project.OrderApi
Company.Project.InventoryApi
//many more here
Company.Project.AddressApi
Then I would have a
Company.Project.Core
This core project would contain some shared code like extension methods, custom exceptions, actionFilters, etc.
I know the answer to this could be very subjective. However, I'm looking for concrete reasons to choose one solution structure over the other. Thanks
I stick with all controllers in one project. I also tend to like to use a single Web API controller per domain / tier / whatever you do to logically break down your application into more manageable pieces so that the amount of controllers can be mitigated.
I've documented my practices on my GitHub Wiki.