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.
Related
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
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?
After publishing a MVC5 web application of mine to my IIS server (Individual User Accounts), it would seem that the URL is accessed incorrectly.
During debug, it would be e.g http://localhost:1234/api/Account/UserInfo?=XXXXX
The debug works just fine. The only issue kicks in after I've published it via my IIS7 server.
After publishing and using Google Chrome's console, it would appear that the page is requesting for a resource at mydomainname.com/api/Account/UserInfo?=XXXX instead of mydomainname.com/WEBAPPLICATIONNAME/api/Account/UserInfo?=XXXX.
My best guess is to modify the URLs in /Scripts/app/app.datamodel.js but it would just cause more parsing problems.
I've searched around and can't seem to find any related problems. I hope someone here will be able to lend a hand.
Look like you are using relative path like "/api/Account/UserInfo". Instead i'll recommend you to use #Url.Content("/api/Account/UserInfo"). This will solve your problem
Explanation
In local system when we run application in WebDev server it never have sub folder (like WEBAPPLICATIONNAME) therefore you relative path work correctly. but when you host your application in IIS under Default website in another new website /Virtual folder (like 'WEBAPPLICATIONNAME') then "/api/Account/UserInfo" fall back to Default Website because for '/' in starting. #Url.Content or #Url.Action make sure to add virtual directory name, hence changing your path to "/WEBAPPLICATIONNAME/api/Account/UserInfo" in IIS.
I profiled my ASP.NET MVC application and I saw strange a function calls.
You can see it on image
Always when mvc render layout we invoke system.web.optimization.scripts.render which invoke JsMinify.Process and Minifier.MinifyJavaScript, but I thought what minification should be one time on the start app.
Am I right?
Maybe must I set some settings for optimization it?
Conditions:
localhost
release
BundleTable.EnableOptimizations = true;
Great Question!
Intuitively, you are right, minification of assets should be performed on application Startup. You assume that assets are delivered identically to all browsers. But Microsoft believes that much of JS and CSS is browser specific.
If you check asp.net site's reference on ASP.NET 4.5 Bundling and Minification, they specifically state:
Bundling and minification in ASP.NET 4.5 is performed at runtime, so
that the process can identify the user agent (for example IE, Mozilla,
etc) , and thus, improve the compression by targeting the user browser
(for instance, removing stuff that is Mozilla specific when the
request comes from IE).
:
What about caching?
Bundling isn't as obtuse as a profiled would have you think. If you look up MVC 4 Bundling and Minification reference, they point out:
Bundle Caching
Bundles set the HTTP Expires Header one year from when the bundle is
created. If you navigate to a previously viewed page, Fiddler shows IE
does not make a conditional request for the bundle, that is, there are
no HTTP GET requests from IE for the bundles and no HTTP 304 responses
from the server.
This is far more information than you need, but the message is that, JSMinify has a check for relevant cached minified assets.
When you factor in further that we already use minified version of our assets (eg jquery.min.js, jquery-ui.min.js), you can appreciate that .Net minification is a supplemental process.
Why does Minification of all types have to happen
I've got some complex routes setup in my asp.net mvc 3 project, unit tested and working on development. For the most part they're working with IIS7 and Integrated Pipeline and having mapAllRequests=true.
But I'm also doing some funky routing with 'some' of the requests for images and css. I'm not sure if it's the logic or if it's IIS taking over when it see's css or img files. I want IIS to take over if it finds the static file otherwise send it to the mvc routing, is this possible?
Not with app pool in integrated mode - all requests are passed to the application. By default, MVC does not route requests for static files (it maps url-paths to them just like non-mvc asp.net, which is the behavior that you want).
You can change that behavior (routes.RouteExistingFiles = true) if you want to do something special within responses to static files. More info about this property:
ASP.NET MVC RouteExistingFiles question
Considerations when turning on RouteExistingFiles
http://msdn.microsoft.com/en-us/library/ie/cc668201.aspx
I hope this helps.