API (MVC Portable Area) Not Working

[nethrelm]

I just did a clean install of a Gold R5 (precompiled, published WAP) on my web server (Windows Server 2008 R2 Standard SP1, IIS 7.5). Everything works as expected except for the sections of the site that use the MvcContrib Portable Areas (namely, the api area). It looks like the view engine is failing to find the views. Here is the exception detail when attempting to access the ~/api/help page.

[InvalidOperationException: The view 'Index' or its master was not found or no view engine supports the searched locations. The following locations were searched:
~/Areas/HelpPage/Views/Help/Index.aspx
~/Areas/HelpPage/Views/Help/Index.ascx
~/Areas/HelpPage/Views/Shared/Index.aspx
~/Areas/HelpPage/Views/Shared/Index.ascx
~/Views/Help/Index.aspx
~/Views/Help/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx
~/Areas/HelpPage/Views/Help/Index.cshtml
~/Areas/HelpPage/Views/Help/Index.vbhtml
~/Areas/HelpPage/Views/Shared/Index.cshtml
~/Areas/HelpPage/Views/Shared/Index.vbhtml
~/Views/Help/Index.cshtml
~/Views/Help/Index.vbhtml
~/Views/Shared/Index.cshtml
~/Views/Shared/Index.vbhtml
~/Views/InputBuilders/Index.aspx]
System.Web.Mvc.ViewResult.FindView(ControllerContext context) +422
System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context) +147
System.Web.Mvc.<>c__DisplayClass1a.<InvokeActionResultWithFilters>b__17() +33
System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func`1 continuation) +613
System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(ControllerContext controllerContext, IList`1 filters, ActionResult actionResult) +263
System.Web.Mvc.Async.<>c__DisplayClass25.<BeginInvokeAction>b__22(IAsyncResult asyncResult) +230
System.Web.Mvc.<>c__DisplayClass1d.<BeginExecuteCore>b__18(IAsyncResult asyncResult) +28
System.Web.Mvc.Async.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) +20
System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult) +53
System.Web.Mvc.Async.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) +20
System.Web.Mvc.<>c__DisplayClass8.<BeginProcessRequest>b__3(IAsyncResult asyncResult) +42
System.Web.Mvc.Async.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) +20
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +469
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +375

[nethrelm]

Okay, so it turns out that it will work if I just host the contents of the website folder directly, and do not do a precompiled publish of the web site. I am not sure why this is the case, and it bothers me that I can't do a precompiled version for better performance, but I guess it is what it is. If anyone knows something I don't, please enlighten me.

[nethrelm]

One last follow up on this for those who may be interested: I did manage to get it working. It turned out that the culprit is a missing VirtualPathProvider owned by the MvcContrib library (AssemblyResourceProvider), which is not added to the HostingEnvironment by the BuildManager when the application is precompiled. There is a workaround, by creating it yourself in the static AppInitialize method. If you don't know about AppInitialize you can read the details about it elsewhere. Essentially, it is similar to Global.aspx in that it will be called by the runtime when the application starts. It MUST be in the App_Code folder, however, which does not exist by default in the WAP version of Gold (but can be easily added of course). The following is the content of the startup file that will get the necessary VirtualPathProvider added to the HostingEnvironment:

Code: Select all

using System.Reflection;
using System.Collections.Specialized;
using System.Web.Hosting;
using MvcContrib.UI.InputBuilder.ViewEngine;

public static class AppStart
{
    public static void AppInitialize()
    {
#if DEBUG
        return;
#else
        // we create a new instance of our own VirtualPathProvider.
        AssemblyResourceProvider providerInstance = new AssemblyResourceProvider();
        
        // any settings about your VirtualPathProvider may go here.

        // we get the current instance of HostingEnvironment class. We can't create a new one
        // because it is not allowed to do so. An AppDomain can only have one HostingEnvironment
        // instance.
        HostingEnvironment hostingEnvironmentInstance = (HostingEnvironment)typeof(HostingEnvironment).InvokeMember("_theHostingEnvironment", BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField, null, null, null);
        if (hostingEnvironmentInstance == null)
            return;

        // we get the MethodInfo for RegisterVirtualPathProviderInternal method which is internal
        // and also static.
        MethodInfo mi = typeof(HostingEnvironment).GetMethod("RegisterVirtualPathProviderInternal", BindingFlags.NonPublic | BindingFlags.Static);
        if (mi == null)
            return;

        // finally we invoke RegisterVirtualPathProviderInternal method with one argument which
        // is the instance of our own VirtualPathProvider.
        mi.Invoke(hostingEnvironmentInstance, new object[] { (VirtualPathProvider)providerInstance });
#endif
    }
}

Credit for this solution goes to someone far more clever than myself. Here is the URL where I finally came upon the solution to this strange issue: http://sunali.com/2008/01/09/virtualpat ... web-sites/

[jmestep]

If you haven't already done it, it would be good if you could send a bug report using the feedback tab in the admin since you know all the details on this. You can just put the link to this topic in your bug report.