I have an actual folder with the same name as a controller. So the resulting link from this:
<li><%= Html.ActionLinkForAreas<BlaController>(c => c.Index(1), "BlaDiBla")%></li>
e.g.
www.bla.com/foldername (where foldername = controller name)
Stopped working.
I am wondering how I can avoid this behaviour as easy as possible (I need the folder with the same name though).
Thanks.
Best wishes,
Christian
IIS does not get priority, but the ASP.net routing engine in System.Web.Routing looks for physical files (or directories) before looking at the Routes you have defined.
You can switch this at a global level with the RouteCollection.RouteExistingFiles property, which will then give your route definitions priority over the file system. Make sure you test all your routes when you change this!
See also this question Considerations when turning on RouteExistingFiles.
Related
I am developing a Clojure/ClojureScript SPA based on http-kit, compojure and tiny bits of hiccup on backend and mainly reagent on frontend. Project is done with leiningen, based on hand-wrecked chestnut template.
When I tried to make more complex URLs than just "/" the following setup created a mess for me:
When producing the initial hiccup to serve HTML and adding includes for CSS and JS files I followed the examples and added them as relative urls like
(include-css "css/style.css")
;and
(include-js "js/compiled/out/goog/base.js")
(include-js "js/compiled/myproject.js")
(note absence of slash in the beginning)
In the chestnut template I got default :asset-path option for cljsbuild set to "js/compiled/out"
Of course, when I tried to add a route to the same page with the http://my-domain/something URL in addition to root http://my-domain/ and load it, the thing failed to get any of my assets (trying to fetch them under e.g. /something/js/compiled/myproject.js).
I was able to fix this issue for explicitly included assets by making those urls relative to root (prepending a slash to each of them). It left me with the same problem with the script tag with src="js/compiled/out/cljs_deps.js" injected by cljsbuild, but this one I fixed by making :asset-path relative to root as well.
It all seems to work properly now, but the fact that I had to make some head-scratching and a surprisingly large amount of googling to finally resolve this makes me feel this is not the default approach. Hence the questions:
Did I do the right thing by converting all asset urls to relative-to-root ones? (Keeping in mind that I'm working on an SPA)
If yes, why isn't this a default approach and why I keep seeing relative-to-current location URLs everywhere (including all the examples on the web as well as lein templates)?
Update:
The relevant part of my app's compojure routes looks like this:
(defroutes home-routes
(resources "/")
(GET "/" _
(friend/authenticated
(html-response
(app-page))))
(GET "/something*" _
(friend/authenticated
(html-response
(app-page)))))
I want to know what is the best way to handle stuff like "help files" in mvc. I was thinking about this last night and I have a solution but is it a best practice (or good enough practice). Ignore html files.
routes.ignoreroute("{filename}.html");
Alternatively I was thinking that I could do a view with pages for help files.
Ie /Views/Shared/Help/helpfilename
I wanted to avoid the database solution but if that is best practise I am ok with that too.
Select html-content where helpcontentname=varible and helplanguage=variable
Static files are served automatically, there is no need to add any ignore routes. By default RouteCollection.RouteExistingFiles = false
Except:
true if ASP.NET routing handles all requests, even those that match an existing file; otherwise, false. The default value is false.
The wording is not the best, but basically what it means is; if the file exists and the value is false, IIS will serve the file directly, without starting up an HttpRequest in the ASP.Net pipeline. (The same reason you don't have to ignore Scripts, StyleSheets, or Images)
I can't understand the benefit(s) that I can get from Url.Content() method in ASP.NET MVC. For example, you see src='#Url.Content("~/Contents/Scripts/jQuery.js")'. Why should I use it? What reasons might exist for using it? What benefits, advantages, etc. over using plain old simple references like src='/scripts/jquery.js?
Update: Based on the answers, I'd like to know if there is any other reason for using it, other than handling virtual folders? Because I haven't seen using virtual applications that much (which of course doesn't mean that it hasn't been used that much).
Usually, your web application is published as: www.yoursite.com/. The ~ character matches the root of the site /.
However, if you publish your site withing a virtual directory www.yoursite.com/mywebapp/, the the ~ character would match "/mywebapp/".
Hard-coding Urls with "/" character would cause wrong page references.
Mapping virtual paths is it's only purpose.
If you do not ever need to map them and are sure your app or it folders will not sit under other apps then it won't serve you any purpose.
From the docs note if you don't use ~ you get no change in the result anyways:
"Remarks
If the specified content path does not start with the tilde (~) character, this method returns contentPath unchanged.
"
It is usefull if your applications root path is not the root path of your server. Url.Content("~/") returns the root folder of your application.
How to fix ?
Multiple types were found that match the controller named 'Home'. This can happen if the route that services this request ('{controller}/{action}/{id}') does not specify namespaces to search for a controller that matches the request. If this is the case, register this route by calling an overload of the 'MapRoute' method that takes a 'namespaces' parameter.
The request for 'Home' has found the following matching controllers:
MyProject1.Controllers.HomeController
MyProject2.Controllers.HomeController
Probably need a little bit more details. For e.g. Did you change the namespace from MyProject1 to MyProject2?
Check your bin folder to see if any of dlls from the old namespace are still around. If that's the case cleaning them up and recompiling should fix the issue.
Make sure you edit the default namespace setting in your web project properties, on the Application tab.
I assume this is in your Views. Be certain the namespaces in your views is correct.
What is the best way to support multiple languages for the interface in an ASP.NET MVC application? I've seen people use resource files for other applications. Is this still the best way?
If you're using the default view engines, then local resources work in the views. However, if you need to grab resource strings within a controller action, you can't get local resources, and have to use global resources.
This makes sense when you think about it because local resources are local to an aspx page and in the controller, you haven't even selected your view.
I found this resource to be very helpful
Its a wrapper round the HttpContext.Current.GetGlobalResourceString and HttpContext.Current.GetLocalResourceString that allows you to call the resources like this...
// default global resource
Html.Resource("GlobalResource, ResourceName")
// global resource with optional arguments for formatting
Html.Resource("GlobalResource, ResourceName", "foo", "bar")
// default local resource
Html.Resource("ResourceName")
// local resource with optional arguments for formatting
Html.Resource("ResourceName", "foo", "bar")
The only problem I found is that controllers don't have access to local resouce strings.
Yes resources are still the best way to support multiple languages in the .NET environment. Because they are easy to reference and even easier to add new languages.
Site.resx
Site.en.resx
Site.en-US.resx
Site.fr.resx
etc...
So you are right still use the resource files.
The Orchard project uses a shortcut method called "T" to do all in-page string translations. So you'll see tags with a #T("A String to Translate").
I intend to look at how this is implemented behind the scenes and potentially use it in future projects. The short name keeps the code cleaner since it will be used a lot.
What I like about this approach is the original string (english, in this case) is still easily visible in the code, and doesnt require a lookup in a resource tool or some other location to decode what the actual string should be here.
See http://orchardproject.net for more info.
Some of the other solutions mentioned as answer do not work for the released version of MVC (they worked with previous versions of alpha/beta).
Here is a good article describing a way to implement localization that will be strongly-typed and will not break the unit testing of controllers and views: localization guide for MVC v1
This is another option, and you'll have access to the CurrentUICulture in the controller:
Check MVC3-multi-language