As far as I understand that, there are two major options for Vue and .NET Core integration within single MVC/Razor project.
Option 1.
MVC/Razor-rendered non-reactive page is used for authentication with built-in ASP.NET Identity. Vue is not involved for authentication/authorization at all. As soon as users are authenticated, they are redirected to another MVC/Razor page that is used as a HTML template for Vue. It’s possible to combine MVC/Razor rendering and Vue. For example, user name on the top of the page can be rendered by MVC but button actions and data tables will be further processed by Vue. It’s possible to use many pages (so it will be MPA, not SPA), it comes naturally. Using *.vue files is not possible. MVC routing seems to be primary routing option (not sure, would be possible to combine with Vue routing and whether any needs for that). Vue JS files can reside anywhere in the project, for example, can be bound to the HTML pages similarly as CS files in Razor pages do (and it’s nice). Then, all these JS files along with Vue itself can be bundled to the wwwroot by Webpack. Vue CLI is not available but seems there is no need for that.
Option 2.
MVC/Razor is not used for rendering user pages at all. Authentication occurs by third-party solutions like IdentityServer and with Vue-managed pages. .NET Core is used exclusively as a WebAPI for Vue and to hold a project. Vue part is totally independent from the MVC/Razor part, they even render pages to the different HTTP ports so proxy is needed to convert Vue HTTP port to the MVC/Razor HTTP port to make Vue works in the single project. We can use either Microsoft.AspNetCore.SpaServices.Extensions or NuGet third-party VueCliMiddleware for that. All Vue files typically reside within a ClientApp folder and then are building to the wwwroot folder. Using *.vue files is possible. Vue CLI is available and recommended to scaffold new application to the ClientApp folder (but further CLI seems is not needed). Vue router seems to be the only option for routing. SPA seems to be the primary choice as a structure (not sure, whether MPA is readily available option). Webpack is still used for building Vue app from the ClientApp to the wwwroot.
I started mu Vue journey with Option 1 even without webpack and npm, just with CDN tag on the one of the Razor pages and it works very well. For me Option 1 seems less complex while more flexible. My primary concern is that Microsoft uses Option 2 as a built-in templates for Angular and React in Visual Studio, so I probably is missing something and soon I will be pushed to rewrite my app to the Option 2.
What you guys think which option is better and whether my understanding explained above, is correct?
Related
I maintain an ASP.NET MVC web application that uses the conventional MVC architecture except for any route that starts with /admin, which is handled by an older WebForms architecture. The MVC and WebForms code coexist in the same .NET 4.8 Framework project, and the user of the site can't even tell there's any difference, because the styling is the same and we use url prettifying tricks so that you can request /admin/something rather than /admin/Something.aspx.
This all works fine, except that WebForms is really showing its age and now we want to port the admin stuff to Vue. But I can't figure out how to deploy Vue such that it has the same coexistence with MVC.
I know that I could continue to use Razor pages and add Vue with a script tag, progressive enhancement style, but I think that makes it impossible to use single file components, which is one of the Vue features that seems important.
It seems like the most functional way to use Vue is to create a proper Vue site, with build step tooling, but how can I do this within an existing MVC project and just delegate one route to the new code, and port other routes over as needed?
I'm rewriting some templates and functionality previously developed using AngularJS 1.x which are currently managed and developed as static assets in an ASP.NET MVC application and are used alongside razor syntax (.cshtml). There are no components either. Imagine the AngularJS modules as a huge bunch of jQuery code linked and coupled with views.
This time, I'm implementing everything we need in a Vue 3 app in a separate git repository and I'm also using Vuex 4.
I'm hoping to be able to do the following:
Build the Vue app
Load the assets in BundleConfig.cs
Link the assets to my _layout.cshtml to have them on all my pages.
Use the components wherever I need them.
I'm going well on developing the components and functionalities within its standalone project, yet I'm facing several problems and/or ambiguities.
I have pages that are mostly if not entirely rendered by the client-side. These pages may or may not be handled by a client-side router such as vue-router.
I also have pages that are mostly rendered by the server and then stuff is added or dynamic contents are loaded by the client-side. These pages can't use a client-side router.
I'm not using a router and I'm having a hard time developing and testing those pages that are mostly rendered by Vue.
if I use a router I think I won't be able to do what I'm planning to do about those pages that are mostly rendered by the server. I really need all pages (whichever kind they are) to have access to my Vuex store.
What do you recommend I do to make it easier for myself both in development and production?
Should I create several static HTML files for each of my pages in Vue's public directory tweak Webpack's configuration in order to simulate what will happen in production (use within the ASP.NET project)?
Should I start having a router, put all pages that are mostly CSR under its control, and somehow configure it to have nothing to do with my other pages that are mostly SSR?
I need to be able to debug and test stuff when I run npm run serve and then do what I'm tasked to do. Unless the whole plan is a bad/wrong idea somehow.
I might also be able to build my Vue app as a library and then, in the ASP.NET project, init a small Vue app that imports that library and that itself is bundled with the back-end project. The whole reason I'm doing this is to make the client-side stuff reusable and easy to maintain. I don't want to take a GET SHIT DONE approach.
Thanks
I am using Razor templates (cshtml) to build HTML for use in emails. While I can get this all to work and I can send email from a ASPNetCore 3.0 web application I want to actually send email from another process which is NOT a web application. Ideally I would like to queue email, which can be triggered from any number of backend processes, and then send those from a timer like service which runs as a windows service or possibly a back-end worker running in Azure via something like Functions.
Is there any way to leverage razor templates from within a RCL in a .NetCore console or other application which is NOT hosted in AspNetCore??
I think there isn't a way to do this i am sry. :(
If I understand your question correctly, you can use RazorEngine, which I used in .NET Framework 4.6.2 Class Library. There is a .Net Core Nuget as well.
I referenced such Class Library projects from Console Applications, Windows Services and Azure Cloud Services (Worker Roles).
In my setup, I had to mark Razor files as Content so they are copied over to the bin folder. Also, it got more complicated if library is referenced by another library and then that library is used; content did not get copied over or it got flattened out (all razor views ended up in the root of the bin folder vs following directory structures), for which there is a fix by editing project file and adding your own copy build tasks. Or I had to embed razor views into DLL.
There might be improvements to this in recent years, as I said I used RazorEngine few years back. And it might be different in .Net Core RCL as well, but I believe it is possible.
Nowadays, I am using 3rd party services like SendGrid or MailJet. For me, using them avoids majority of the above issues and offers better insight into emails/templates/campaigns to Marketing and other non-tech users. They can edit and modify templates to their liking without (m)any code deployments.
You have to run the code through ASP.net core engine so that Razor code get converted into html.
Otherwise use simple html template.
I was wondering whether it is possible to deploy two ASP.Net MVC sites to do the following.
Main Website: contains all the controllers and views
CDN website: contains all the JavaScript and CSS (bundles JS and CSS that is consumed by the first site)
I was expecting that in the solution you would have two website projects. I think in debug mode this would work fine because the bundle names are consistent.
However, in production where you are not running in debug mode (turned off in web.config), the file names have a query parameter that varies e.g. http://www.test-domain.com/bundles/bootstrap?v=2Fz3B0iizV2NnnamQFrx-NbYJNTFeBJ2GM05SilbtQU1 (where bootstrap is the name of the bundle).
Does anyone know how to reference the bundles in the CDN website from the Razor views in the main website?
Answer
I realised that you don't have to include the query parameter for bundle name
If your MVC 5 project work well in Release mode in your local machine, it will work on Production too.
Only few more considerations you need to take care on production are :
Make sure CORS is enabled since you have js & css resources at different site(if domain name is different)
Make sure you references at MVC5 site having hosting views & back-end logic have correct references as you have created in CDN
Firewall/hosting port is allowed on both hosting machine to communicate.
Hope this helps.
BTW querystring appended to end of URL just make sure every request is differently served by Server not as cached, nothing to impact your application.
I'm creating an application with a .Net Web Api project wanting to use pure AngularJS as the client side. Since Web Api is built on top of MVC, it creates MVC specific and default items that I feel is not needed. These items include the HomeController, _ViewStart.cshtml, _layout.cshtml, etc. I tried removing them but it comes up with errors. Has anyone tried to remove the MVC stuff out of the web api project and used separate client side front-end? Is it even possible to remove the MVC items without errors?
Remove RouteConfig.cs from App_Start, remove the Views directory and all sub-directories including the Views internal web.config file. Comment out or delete all the lines in the Global.asax.cs Application_Start method except GlobalConfiguration.Configure(WebApiConfig.Register). Remove the HomeController, add an index.html and any needed Angular scripts and go at it. I also added solution folders to organize my views as reusing the existing Views folders did not work. I'm using VS 2015 but is should work for 2013 also. PWE
Web API is not built on top of MVC.
The default templates bring in MVC for the sake of supporting a help page, but you don't need to use it.
You can start with an empty web project and just check Web API.
The routing piece is server routing and it's part of what maps the URL to Controllers+Actions, it has nothing to do with Angular routing.
As Mike Cheel alluded to, there are no dependencies between MVC and Web API. However, if you use the built-in templates, it's easy to get the impression that the 2 are linked. They include a lot of stuff in these templates because they can't anticipate where you want to go with your project... so they try to cover all the bases.
For your purposes, you would probably be better off to start with an empty project and add only the components that you actually need. For this approach, some of the best tutorials and starter projects are from Taiseer Joudeh's "Bit of Technology" blog. His tutorials helped me to build an "MVC Free" web application from scratch that uses JSON Web Tokens and AngularJS Interceptors for security and Web API 2 and Entity Framework to serve up the data.
He has many tutorials on his website... but you might want to start with "AngularJS Token Authentication using ASP.NET Web API 2, Owin, and Identity". What what.. you didn't ask about security? Well... security is an issue that you will need to confront at some point anyway... and Taiseer presents a nice solution for securing an Angular/Web API application.