I'm introducing LESS into an existing ASP.NET web forms application. In order to get intellisense to work, I decided to set up the LessCssHttpHandler to intercept requests for files ending in .less.css. That way, Visual Studio still thinks we're dealing with a CSS file. I did this by adding the following line to my web.config file:
<add type="dotless.Core.LessCssHttpHandler, dotless.Core"
validate="false" path="*.less.css" verb="*" />
In order to get this to work, I had to tweak my IIS settings so that .css files get handled by the ASP.NET framework. Unfortunately, by doing so, now my existing .css files (which aren't handled by the dotless HTTP handler since they don't end in .less.css) aren't returning any content. This makes sense since the ASP.NET framework doesn't really know what to do when it sees a file with that extension.
Is there some sort of base HTTP handler I can set up in addition to the one I have above to handle normal .cssfiles? Something like:
<add verb="*" path="*.css" type="insert some base HTTP handler here that will simply return the contents of the file" />
Looks like the StaticFileHandler is what I was looking for. This is how we ended up adding it to our httpHandlers node in web.config:
<add verb="*" path="*.less.css" validate="false" type="dotless.Core.LessCssHttpHandler, dotless.Core, Version=1.1.0.7, Culture=neutral, PublicKeyToken=96B446C9E63EAE34, processorArchitecture=MSIL" />
<add verb="*" path="*.css" type="System.Web.StaticFileHandler" />
We use Chirpy for our LESS support (as well as our google closure compiler support). It allows you to configure file extensions for LESS, such as .less.css, and then you can have Intellisense support.
It doesn't do translation at runtime but rather at design time within visual studio. When you edit and save the LESS file, Chirpy kicks in and processes the LESS file which generates the css file. This way we avoid having to hand off css file serving to ASP.NET.
I tend to use the console compiler and rename the less file to .css
The httphandler is usually only for people who need parameters in their CSS.
Related
We have a website that makes use of .less files (the pre-compiler dotless has been installed using nuget), however the .less files are not handled as css files.
When trying to view the website in firefox, the console gives use the following error:
The stylesheet http:// website/css/init.less was not loaded because its MIME type, "application/octet-stream", is not "text/css".
Our dotless file is trying to import more files:
#import "imports";
..
But even replacing this text with css code, the styles are still not applied. But if I go to that file in Visual Studio, it is displaying all the css from the files that are imported.
If you're using the dotLess handler to process and serve your .less files on the fly (which is fine for debugging, but you might want to consider pre-compiling for release), you need to ensure that you also send them down with the correct mimetype.
You can do this either at the server level in IIS Admin (if you're likely to using this for multiple sites on the machine), or at the local site level via the web.config - note that you can't do both, IIS will complain that there are multiple entries for the file extension.
To do this in the web.config, within the <configuration><system.webServer> element add the following elements:
<staticContent>
<mimeMap fileExtension=".less" mimeType="text/css" />
</staticContent>
Obviously, if you've already got some mimemap entries, just add the mimemap there.
This will ensure that IIS claims that the .less files served from the handler as CSS rather than the default application/octect-stream.
If that's still not serving them as processed, there are a couple of other things you'll need to check:
Ensure that the handler is correctly registered in both the <system.webserver><handlers> and <system.web><httpHandlers> sections (depending on the version of IIS you're using:
<add name="dotless" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
and
<add path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler, dotless.Core" />
Ensure that IIS is configured to send all requests through the ASP.NET handlers configured in step 1. By default, .less files are probably being considered "static files" and will only be handled by the StaticFileModule.
So this is a bit of asp.net I feel like way too many people don't understand. That is to say, I don't understand it and I've asked a bunch of people/googled and no one else seems to know the specifics either.
By default ASP.Net applications will serve files in Content and Scripts directories as static content. In fact, if I create other directories, I think it will serve static content in these as well.
However, the contents of some directories won't be served - the typical Asp.Net Mvc Controllers directory for example. In addition, you can always configure routes in asp.net (or OWIN handlers) that will pick up certain routes but not either.
Nothing seems to be configured anywhere. I have my suspicions, but I'm really not clear on what exactly is the rule for what gets served as static content and what gets processed by asp.net?
I've always found this graphic helpful: https://web.archive.org/web/20211021221111/https://www.4guysfromrolla.com/images/step2.gif
Specifically, the HttpHandlers mentioned in that graphic correspond to this section of the Web.Config file in your .NET web project's root directory:
<system.webServer>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
The path attribute of that tag can be used to configure only certain directories being handled by a certain class. At that point, IIS will hand off the HTTP request to the appropriate class, with the proper context and thread etc. My guess is that if you are running IIS with multiple frameworks, each has a distinct path associated with its add-handler tag.
Additionally, IIS has its own default settings for what file extensions are mapped to what handler classes. These can also be modified in the IIS management interface, so it's possible that your super-helpful ops team added that for you there even if it's missing from your web.config. At the end of the day, though, it's a relationship between url-HttpHandler class that determines static-file versus dynamic.
Edit:
There's another set of tags, outlined at this ServerFault answer:
https://serverfault.com/questions/175499/serving-cs-csproj-files-on-iis7-5
That describes a <add fileExtension=".cs" allowed="false" /> tag that operates on the file extension as opposed to a pattern on the entire path. This is what disallows files ending in .cs, and .csproj from being served. Additionally, since you're operating on an installation of IISExpress, you should know that it uses a different configuration file than the standard machine.config. The path for that file is described at this answer:
Where is the IIS Express configuration / metabase file found?
All this gets muddied a little by the notion of self-hosting, aka no IIS. Nancy does this, I believe, and ServiceStack can as well. I have no experience doing that, but the way they handle paths is probably a little different.
I manage a large asp.net site which has previously been converted from static html site to asp.net.
For several reasons (mainly SEO) we decided not to rename all the files to .aspx back when we originally converted the site. This was very easy to do by simply adding the buildProvider and httpHandler to the web.config.
<buildProviders>
<add extension=".html" type="System.Web.Compilation.PageBuildProvider"/>
</buildProviders>
<httpHandlers>
<add path="*.html" verb="*" type="System.Web.UI.PageHandlerFactory"/>
</httpHandlers>
Now I am upgrading the site to use Asp.net WebPages with Razor cshtml files. I can rename all the files if necessary, and use url rewriting to make the urls stay the same, however it would be much easier if I could just configure the web.config to tell it to parse .html files as if they were .cshtml.
I have searched around quite a bit, and could not find anything equivalent to the PageHandlerFactory for razor pages. It appears as though it is just an internal mechanism in the .net 4.0 ISAPI handler.
The site is currently running on Windows 2003 server and IIS 6. We will be upgrading to 2008/IIS 7.5 in the near future, but I'd prefer not to wait for that.
Is there any way to get the .html files to be parsed by razor as if they were .cshtml files?
Thank you to SLaks for pointing me in the right direction, but it still took a few hours of digging in the MVC source to figure out the solution.
1 - Need to put RazorBuildProvider in web.config
<buildProviders>
<add extension=".html" type="System.Web.WebPages.Razor.RazorBuildProvider"/>
</buildProviders>
And add System.Web.WebPages.Razor to assemblies if it isn't already there.
<assemblies>
[...]
<add assembly="System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</assemblies>
2 - Add 2 lines in global.asax Application_Start() method
// Requires reference to System.Web.WebPages.Razor
System.Web.Razor.RazorCodeLanguage.Languages.Add(
"html", new CSharpRazorCodeLanguage());
WebPageHttpHandler.RegisterExtension("html");
Call WebPageHttpHandler.RegisterExtension.
You may also need to register a custom WebPageRazorHostFactory to tell the Razor engine what to do with the file; I'm not sure.
As this actually been resolved for use with VS2012 / .net 4.5.
As using the examples above in a C#5 project I get no luck :(
I manage a large asp.net site which has previously been converted from static html site to asp.net.
For several reasons (mainly SEO) we decided not to rename all the files to .aspx back when we originally converted the site. This was very easy to do by simply adding the buildProvider and httpHandler to the web.config.
<buildProviders>
<add extension=".html" type="System.Web.Compilation.PageBuildProvider"/>
</buildProviders>
<httpHandlers>
<add path="*.html" verb="*" type="System.Web.UI.PageHandlerFactory"/>
</httpHandlers>
Now I am upgrading the site to use Asp.net WebPages with Razor cshtml files. I can rename all the files if necessary, and use url rewriting to make the urls stay the same, however it would be much easier if I could just configure the web.config to tell it to parse .html files as if they were .cshtml.
I have searched around quite a bit, and could not find anything equivalent to the PageHandlerFactory for razor pages. It appears as though it is just an internal mechanism in the .net 4.0 ISAPI handler.
The site is currently running on Windows 2003 server and IIS 6. We will be upgrading to 2008/IIS 7.5 in the near future, but I'd prefer not to wait for that.
Is there any way to get the .html files to be parsed by razor as if they were .cshtml files?
Thank you to SLaks for pointing me in the right direction, but it still took a few hours of digging in the MVC source to figure out the solution.
1 - Need to put RazorBuildProvider in web.config
<buildProviders>
<add extension=".html" type="System.Web.WebPages.Razor.RazorBuildProvider"/>
</buildProviders>
And add System.Web.WebPages.Razor to assemblies if it isn't already there.
<assemblies>
[...]
<add assembly="System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</assemblies>
2 - Add 2 lines in global.asax Application_Start() method
// Requires reference to System.Web.WebPages.Razor
System.Web.Razor.RazorCodeLanguage.Languages.Add(
"html", new CSharpRazorCodeLanguage());
WebPageHttpHandler.RegisterExtension("html");
Call WebPageHttpHandler.RegisterExtension.
You may also need to register a custom WebPageRazorHostFactory to tell the Razor engine what to do with the file; I'm not sure.
As this actually been resolved for use with VS2012 / .net 4.5.
As using the examples above in a C#5 project I get no luck :(
Forgive me if this is basic. I've never made one before and can't seem to figure out why it's not working. I wrote a little handler to do some parsing on CSS files. I added this:
<system.web>
<httpHandlers>
<remove verb="*" path="*.css"/>
<add verb="*" path="*.css"
type="MyNameSpace.CssRelativePathHandler,CssRelativePathHandler" />
</httpHandlers>
</system.web>
Nothing ever happens. CSS files get parsed normally. No errors, nothing, the code never runs. What am I missing? Shouldn't this cause the handler to be used when *.css files are served? (I added the "remove" later, since I thought perhaps I needed to do that to override a built-in hander, again, no difference either way).
This is IIS 6. I added the IIS 7 code anyway (after searching for answers) but makes no difference.
<system.webServer>
<handlers>
<add name="CssHandler" verb="*" path="*.css"
type="MyNameSpace.CssRelativePathHandler,CssRelativePathHandler" />
</handlers>
</system.webServer>
You need to configure IIS6 to send requests for .css files to ASP.Net.
Had you been using IIS7, your <system.webServer> element would have done that for you, but IIS6 predates this.
For IIS 6 you need to have to tell it to send *.css files to ASP.NET.
Launch IIS Manager
Right-click on Default Web Site
Click on the Home Directory tab
Under Application Settings click on Configuration...
Add a new association for .css and map it to .NET executable:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
It sounds like you need to configure IIS to enable ASP.NET to execute the .css extension.
Phil Haack has a walkthrough on doing that (just replace .mvc with .css under the heading "Mapping .mvc to ASP.NET"):
http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Or you can set up a wildcard mapping in IIS 6:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5c5ae5e0-f4f9-44b0-a743-f4c3a5ff68ec.mspx?mfr=true
I'd recommend going with the first method as doing the wildcard approach will send all requests to ASP.NET - so it has a more overhead.
PS: Further down Phil's post, he also lists "IIS6 Extension-less URL" and also covers the wildcard mapping method.