9

I have ASP.NET with MVC and Razor markup website and I want to run it on my Linux VPS.

I have mono 3.2.8 and xsp4 3.0.0.0 version, both from Ubuntu repository (installed using apt-get install mono-complete mono-xsp4)

When I upload my website to server and run xsp4 in the website's folder, it start and prints out that it's listening on port 8080. However when I use my web browser to navigate to my website, it displays runtime error and xsp4 outputs this to console 

Missing method System.Web.HttpApplication::RegisterModule(Type) in assembly
/usr/lib/mono/gac/System.Web/4.0.0.0__b03f5f7f11d50a3a/System.Web.dll, referenced 
in assembly /tmp/root-temp-aspnet-0/55726984/
assembly/shadow/df4b0596/52105b83_8d5b5e15_00000001/Microsoft.Owin.Host.SystemWeb.dll

Missing method RegisterAllAreas in assembly /tmp/root-temp-aspnet-
0/55726984/assembly/shadow/dc5a60b8/51013ead_8d5b5e15_00000001/<website_name>.dll, type
System.Web.Mvc.AreaRegistration

It's a fresh Ubuntu 14.04 installation. I'm developing my website on Windows, using Visual Studio 2013. Any idea how to fix these errors?

isklenar
  • 974
  • 2
  • 14
  • 34

2 Answers2

4

The upstream bug report regarding this issue is located here.

A suggested workaround until the bug is fixed and the method implemented is to use Microsoft.Web.Infrastructure.DynamicModuleHelper.DynamicModuleUtility.RegisterModule instead of HttpApplication.RegisterModule.

The issue here describes a workaround, which would be to change HttpApplication.RegisterModule to Microsoft.Web.Infrastructure.DynamicModuleHelper.DynamicModuleUtility.RegisterModule in PreApplicationStart.cs in OWIN (the previous master already had the relevant IFDEF for NET 4.0, but it was reverted for some reason) or to include the DLL they specify or register the module manually in the web.config .

The alternative that doesn't require any code change to OWIN is to implement the missing method in Mono and fix the bug and then backport the fix to your Mono version.

Appleman1234
  • 15,946
  • 45
  • 67
  • I had the same MissingMethodException with the default MVC WebApplication template (with Individual Authentication) created in Visual Studio 2013, using Mono 4.0.1. I need to solve it as my existing project is based on this default template. Do you mean rebuilding the HttpApplication class from the source code with the modification in PreApplicationStart.cs that you mentioned? Can you explain more on this please? – brian May 08 '15 at 15:04
  • I mean rebuilding OWIN so that it resembles the left handsize of the following [comparison](https://katanaproject.codeplex.com/SourceControl/diff/file/view/b85af2f1cfbf98f15b9d6a6a6a4cd8ef3923f0dc?fileId=src%2FMicrosoft.Owin.Host.SystemWeb%2FPreApplicationStart.cs&olderChangeSetId=501be946a5a99edf1140fbf5cbce0a29324870c1) – Appleman1234 May 08 '15 at 22:07
  • Thanks for your help. I have further questions on this and I posted it here: http://stackoverflow.com/questions/30186770/need-help-in-modifying-owin-katana-for-running-vs2013s-mvc-webapplication-in I wonder if you can help me on this. Thanks. – brian May 12 '15 at 09:27
3

This is not really a full answer but perhaps what I did may help someone get a little further.

After filling in some unrelated voids on the dev branch of Mono (which at the time was v3.99) like AppendTrailingBackslash(), GetBufferlessInputStream() and a few other functions, I was able to get an MVC5 app to come up and function OK on Ubuntu using XSP4.

I then tried to use OWIN and the mono-built version of SignalR.

I did what Appleman1234 suggested above, implement RegisterModule() in HttpApplication.cs to do what Microsoft.Web.Infrastructure.DynamicModuleHelper.DynamicModuleUtility.RegisterModule() does. This does seem to work and injects the module string into the system.web/httpModules section without error.

This combined with manually specifying the OwinHttpHandler in my system.web:

<system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
    <customErrors mode="Off" />

    <httpHandlers>
      <add verb="*" path="*" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler, Microsoft.Owin.Host.SystemWeb" />
    </httpHandlers>

</system.web>

and calling the default MapSignalR() in my Startup Configuration():

var appBuilder = app.MapSignalR();

and after hacking up some of the SignalR code (I was getting some ReadOnlyException on a NameValueCollection as it tried to remove the Accept-Encoding from the request headers... I figured I'd get to that later), I think I got it to initialize all the way to the point where I could at least browse to /signalr and get some meaningful errors back (missing connectionId, unknown protocol, etc). I didn't get to actually testing the SignalR functionality, but I am about to do so by using a separate client program.

I am hosting this using xsp4/mono 4.5.

However, in doing so I think I clobbered the rest of the handlers/pipeline because I cannot really browse to anything else in the website (stylesheets, scripts, etc), as I get a 404

Also note that:

(1) HttpRuntime.UsingIntegratedPipeline returns false in the context of XSP4.

(2) I had to comment out the exception in HttpApplication.cs/AsyncInvoker::Invoke(), which originally threw this exception:

throw new Exception("This is just a dummy");

Given this, is there simply not yet enough Async and other support in Mono to get OWIN/SignalR to work? I am thinking that since UsingIntegratedPipeline returns false that it's a no-go for XSP4?

Dan
  • 894
  • 9
  • 21
  • Dan, I have exactly the same problem you described here. I followed your suggestions and successfully loaded the SignalR as the OWIN middleware (although i have not tried to see if the SignalR part actually works). But as you had described, after adding the tag, all the css and script files can no longer be loaded. I wonder if you have fixed this problem yet. Thank you. – brian May 18 '15 at 08:34
  • Hi! No, sorry, I left this problem as it was and pushed it down on my mental stack. I did however happen to notice that even when using SignalR in a standalone console app (which has always worked as there is no dependency on SystemWeb), on Linux/Mono it does not connect via websockets. It's always something lesser, like serverSentEvents. I think this is because [System.Net.WebSockets](http://go-mono.com/status/status.aspx?reference=4.5&profile=4.5&assembly=System) is not fully implemented in Mono 4.5. I may implement my own handler using SuperWebSockets (which **does** with with Mono) – Dan May 19 '15 at 12:32