asp mvc custom view location - asp.net

I have configured my controller to return a view from a custom location rather than the typical Views folder. This has been achieved by adding the following code to Global.asax
var razorEngine = ViewEngines.Engines.OfType<RazorViewEngine>().First();
razorEngine.ViewLocationFormats = razorEngine.ViewLocationFormats.Concat(new string[]
{
"~/UI/app/{1}/Views/{0}.cshtml"
}).ToArray();
It is working fine but i am facing issues with linking css, images and js files to the cshtml page. When loading the page, seems like those files are 404 not found and on the console i receive "Failed to load resource: the server responded with a status of 404 (Not Found)".
Not sure if I am missing something or why it is unable to find the path to my content files.
The way i referenced the content files were as follows: ~/path to the location

Solved the issue by adding web config to the custom directory and making sure the BlockViewHandler path was set to "*.cshtml".
e.g. From
<add name="BlockViewHandler" path="*" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler" />
To
<add name="BlockViewHandler" path="*.cshtml" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler" />
Hope it helps others :)

Related

web.Config Request Filtering, Block files that start with _

I'm dealing with a legacy classic asp app, and I would like to prevent files that start with underscore "" from being retrieved via a browser request. Ideally I want any file that starts with "" to show a 404 not found exception.
The reason being is I don't want to name my files with the .Inc extension because It makes it a pain in development as I lose syntax highlighting, intellisense, and other things I'm using in Visual Studio.
As this is running in IIS8, is there any way I can filter the request to block these files before the ASP handler processes the page?
Temporary Answer:
I mapped ASPClassic in the http handlers twice. First I mapped it to _*.asp. However I used an invalid dll for the asp dll, which will cause an error:
The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server.
Which is a 404.2
Then I mapped the normal *.asp handler.
HttpHandlers don't pass to the next HttpHandler if it matches a request.. So the first HttpHandler to match the request is the one that get's used.
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
<remove name="OPTIONSVerbHandler"/>
<remove name="TRACEVerbHandler"/>
<remove name="ASPClassic"/>
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0"/>
<add name="ASPClassic_No" path="_*.asp" verb="GET,HEAD,POST" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll2" resourceType="File" />
<add name="ASPClassic" path="*.asp" verb="GET,HEAD,POST" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="File" />
</handlers>
</web.Server>
Furthermore, server side includes still work on these files because SSI isn't request dependent.
If anyone knows a cleaner, non hacky way of doing this, I'm all ears!
I was using this asp file to do it prior to this:
<%
notFound_fullName = Request.ServerVariables("SCRIPT_NAME")
notFound_pathArray = split(notFound_fullName, "/")
notFound_fname = notFound_pathArray(UBOUND(notFound_pathArray))
If (InStr(1, notFound_fname, "_") = 1) Then
Response.Status ="404 Not Found"
Response.End
End If
%>
However, I ran into a scenario where I needed it to be included on a page that included it on the page, while also including it on the page that was being included.
E.g.
_cUser -> include 404handler code (alone with no other includes)
_baseWebService -> Include _AllClasses (includes 404 handler again)
Which won't work with option strict, becuase it's either redefining variables, or the variable isn't defined because option strict is on....

LessAssetHandler is not invoked for path inside area

I have a problem with LessAssetHandler which ships with BundleTransformer.Less library. I use LessAssetHandler in debug mode as a HttpHandler for transforming less files. Everything works fine except that the files inside ASP.NET areas are not handled by LessAssetHandler. For example file /Content/Style/page.less is handled by LessAssetHandler, byt for file /Areas/Admin/Content/Style/page.less this handler is not invoked. I have configured handler in the folling way:
<system.webServer>
<handlers>
<add name="LessAssetHandler" path="*.less" verb="GET" type="BundleTransformer.Less.HttpHandlers.LessAssetHandler, BundleTransformer.Less" resourceType="File" preCondition="" />
<handlers>
</system.webServer>
How can I force MVC to route less files from area through LessAssetHandler?
Registration of LessAssetHandler is correct. The exact same code is added to Web.config file during installation of NuGet package.
BundleTransformer.Less can work in ASP.NET MVC application with areas. It is possible, that you have incorrectly registered the bundle.
Bundle registration should look like the following:
var adminStylesBundle = new CustomStyleBundle("~/Bundles/AdminStyles");
adminStylesBundle.Include("~/Areas/Admin/Content/Style/page.less");
adminStylesBundle.Orderer = nullOrderer;
bundles.Add(adminStylesBundle);

VirtualPathProvider doesn't (quite) work in production on IIS 7.5

I have been working on a project that has common bits of functionality, specifically I wanted to share the master file and related images/js/etc. To that end, the master page and its dependent files are all wrapped into a "global" DLL that is utilized by all "subprojects". This all worked great in development, but deployment yielded a surprise which seems to catch a lot of people off guard: VirtualPathProvider doesn't work when precompiled.
Now thanks to this blog post containing a workaround I was able to give another attempt at getting it to work. Regretfully, it still doesn't.
I opted to get rid of my Global.asax implementation and went with the blog post's AppInitialize approach:
public static class AppStart
{
public static void AppInitialize()
{
HostingEnvironment hostingEnvironmentInstance = (HostingEnvironment)typeof(HostingEnvironment).InvokeMember("_theHostingEnvironment", BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField, null, null, null);
MethodInfo mi = typeof(HostingEnvironment).GetMethod("RegisterVirtualPathProviderInternal", BindingFlags.NonPublic | BindingFlags.Static);
mi.Invoke(hostingEnvironmentInstance, new object[] { new MasterPageProvider() });
}
}
Since the actual provider works in debug, I won't include it. If you would like to see it, don't hesitate to ask. Just wanted to keep the question as short as possible.
The interesting aspect to this whole situation is that production yields no errors about not being able to find the master page. To me, this means the provider is working, but for whatever reason the rest of the resources (js/css/etc) aren't being retrieved from the assembly properly.
So my question comes down to this: what are the reasons that this solution would work great in development, but not in production on IIS 7.5?
UPDATE 11/20/2011
Tried out David Ebbo's suggestion and had no results unfortunately. My web config looks something like this now:
<configuration>
<connectionStrings>
<clear />
<!-- ... -->
</connectionStrings>
<system.web>
<pages>
<controls>
<!-- ... -->
</controls>
</pages>
<compilation debug="true" targetFramework="4.0" />
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
</configuration>
UPDATE 11/21/2011
Just to verify my suspicion that the VirtualPathProvider was actually working, I commented out the third line (mi.Invoke(....) and redeployed the site. As I suspected, it now breaks due to not being able to find the MasterPage file. This issue appears to be related to only static files being delivered through the VPP.
IIS 7.5 will handle the static files itself. You need to put a line for each static file you want it to ignore in your web.config file to make them get routed through your VPP. See below for examples.
<system.webServer>
<handlers>
<add name="Images" path="*.png" verb="GET,HEAD,POST" type="System.Web.StaticFileHandler" modules="ManagedPipelineHandler" resourceType="Unspecified" />
<add name="Stylesheets" path="*.css" verb="GET,HEAD,POST" type="System.Web.StaticFileHandler" modules="ManagedPipelineHandler" resourceType="Unspecified" />
</handlers>
</system.webServer>
Maybe the problem is that requests for static files are not going through ASP.NET by default in IIS.
Try whether turning on runAllManagedModulesForAllRequests in web.config helps. e.g.
<modules runAllManagedModulesForAllRequests="true" />
Take a look at this post. It explains how to get static files through a virtual path provider in IIS 7. I believe this will solve your problem.

Having jpg and gif handled by IsapiModule in IIS7

I'm struggling to get my HttpHandler to process requests for jpg and gifs.
I've gone to the website's Handler Mappings and added the following line:
Path: *.jpg,*.gif
State: Enabled
Path Type: Unspecified (I've also tried setting this to File)
Handler: IsapiModule
Entry Type: Local
Running through Visual Studio works, so I know its not my code. It also works on IIS6.
I've tried setting the app up in both classic and integrated mode.
Here's the appropriate Handler mappings specified in the web.config:
<add name="*.jpg,*.gif_*" path="*.jpg,*.gif" verb="*" type="ThumbnailGenerator,Utilities" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="JPEG-GIF" path="*.jpg,*.gif" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
I fixed this by clearing out the handlers from web.config, then manually adding the using IIS: [Handler Mappings] -> [Add managed handler]
I'm not sure what difference this made, because the web.config looks pretty much the same as I had setup before, but now it works.

Mapping classic asp pages to .net in IIS

I'm trying to map requests for classic asp pages to be handled by .net, so that it runs through a custom httpmodule.
In IIS I have remapped asp requests to aspnet_isapi.dll - I'm sure I've done this bit right
Now in my test app I am getting this error:
Server Error in '/TestASPRedirect' Application.
--------------------------------------------------------------------------------
This type of page is not served.
Description: The type of page you have requested is not served because it has been explicitly forbidden. The extension '.asp' may be incorrect. Please review the URL below and make sure that it is spelled correctly.
Requested URL: /testaspredirect/test.asp
Searching online for this error shows a load of people having problems with cassini, but this is not really relevant, I am testing this on both IIS 5.1 on XP dev machine, and have tested on IIS6 also getting the same error.
I have followed instructions for adding and registering a httphandler (see http://support.microsoft.com/default.aspx?scid=kb;en-us;Q308001), but I don't know what to put in the ProcessRequest routine to ensure the request gets passed on. What is the default .net httphandler, can I just map to this in web.config?: so something like:
<httpHandlers>
<add verb="*" path="*.asp" type="standard.nethttphandler"/>
</httpHandlers>
How do I tell asp.net that it needs to pass ASP requests on and not block?
Actually you are only one step far from the success. Adding following section to your Local website(or virtual directory) web.config file:
<configuration>
...
<system.web>
<compilation>
<buildProviders>
<add extension=".asp" type="System.Web.Compilation.PageBuildProvider"/>
</buildProviders>
</compilation>
<httpHandlers>
<add path="*.asp" verb="*" type="System.Web.UI.PageHandlerFactory" validate="true"/>
</httpHandlers>
</system.web>
It looks like the .asp extension is mapped to the HttpForbiddenHandler.
If you're using ASP.NET 1.1 then open the following file:
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config
If you're using ASP.NET 2.0 then open this file:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config
Search for "path="*.asp"", then comment out that line. It'll like something like:
<!-- machine.config/ASP.NET 1.1-->
<add path="*.asp" verb="*"
type="System.Web.HttpForbiddenHandler"/>`
<!-- web.config/ASP.NET 2.0-->
<add path="*.asp" verb="*"
type="System.Web.HttpForbiddenHandler" validate="true"/>`
Locate the below file:
C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\<FramworkVersion>\Config\web.config
where <FramworkVersion> is folder name:
open it in an XML editor .. (even notepad is fine)
and add below line :
<add path="*.asp" verb="*" type="System.Web.UI.PageHandlerFactory" validate="True"/>
under below XPath:
configuration/system.web/httpHandlers
replace the existing one!
Add below line:
<add extension=".asp" type="System.Web.Compilation.PageBuildProvider"/>
under below XPath:
/configuration/system.web/compilation/buildProviders
Worked like gem for me :)

Resources