Brand new ASP.NET project: internal server error.

[jbehrens94]

I just created a new project on OS X with yo aspnet for a ASP.NET web application. I have ran dnvm upgrade && dnu restore after which I ran dnx . kestrel and the command responds with Started!.

Not only does the project not run on port 5004, but on port 5001. Also I'm getting this internal server error:

An unhandled exception occurred while processing the request.

IOException: kqueue() FileSystemWatcher has reached the maximum nunmber of files to watch.
System.IO.KqueueMonitor.Add (System.String path, Boolean postEvents,      System.Collections.Generic.List`1& fds) [0x00000] in <filename unknown>, line 0

[suhasj]

What version of Mono do you have ? There is a bug open for Mono on this https://bugzilla.xamarin.com/show_bug.cgi?id=28693. I think it might be fixed in the latest 4.0.1 but can you confirm your version ?

[barranger]

It is that bug, and unfortunately it still occurs in 4.0.1

The fix is to to add this to your .bash_profile

export MONO_MANAGED_WATCHER=disabled

The bad thing is that it means you have to stop and restart the server to see even the smallest html change

[TomSchillemans]

I hope this is fixed soon.. isn't it possible to increase the number of files to be watched? Since that is the error.

Edit

After @barranger's temporary solution, I got the following error. It still is a newly created ASP.NET WebApp!

TypeLoadException: Could not load type 'Microsoft.Framework.Runtime.ILibraryExport' from assembly 'Microsoft.Framework.Runtime.Interfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

[migueldeicaza]

Set a higher limit for file descriptors open:

ulimit -n NNN

[ielcoro]

Same problem here as @TomSchillemans, also disabling MONO_MANAGED_WATCHER yields the same type load error.

Tried @migueldeicaza solution with no luck. ulimit (without -n) returns unlimited as current limit, setting .n does nothing to it (at least in OSX).

I´m stuck :-(

[jrock2004]

@iceclow I had an issue with file limits with OmniSharp. This tut helped me properly setup ulimits

http://docs.basho.com/riak/latest/ops/tuning/open-files-limit/#Mac-OS-X

[ielcoro]

Thanks @jrock2004 tried those steps, without luck. After restarting the system my ulimt -n shows 999 (cause you cannot set it 65536), however the issue remains.

Any thoughts?

[riccardo-moschetti]

@jrock2004 is that setting working on Yosemite for you? I created the limit.maxfiles.plist and limit.maxproc.plist files but still get the same error. The only workaround valid for me is export MONO_MANAGED_WATCHER=disabled at the moment

[whiteboardmonk]

I'm facing the exact same issue on OSX 10.10.2 for a newly created yo aspnet project.

$ ulimit unlimited $ mcs --version Mono C# compiler version 4.0.1.0 $ dnx --version 1.0.0-beta4-11566

[pauldipietro]

Same as @whiteboardmonk with the only difference is my being on 10.10.3.

[thierryrama]

Same here with

Euler:FirtWebApp thierry$ ulimit
unlimited
Euler:FirtWebApp thierry$ mono --version
Mono JIT compiler version 4.0.1 (tarball Mon Apr 27 01:00:48 PDT 2015)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
    TLS:           normal
    SIGSEGV:       altstack
    Notification:  kqueue
    Architecture:  amd64
    Disabled:      none
    Misc:          softdebug
    LLVM:          supported, not enabled.
    GC:            sgen
Euler:FirtWebApp thierry$ dnx --version
1.0.0-beta4-11566

[ilyavaiser]

This is a very annoying bug. Confirm it under OSX 10.10.3 with ulimit unlimited.

[jbehrens94]

Confirmed under OS X 10.10.3 with ulimit unlimited. Also Mono C# compiler version 4.0.1.0 and dnx --version 1.0.0-beta4-11566.

[miguellira]

FWIW... I managed to get a pseudo-stable setup on my Mac OS X. Here's what I did:

1. Installed mono 4.0.1 via Homebrew.
2. Complied the latest version of mono (4.1.0) from git master via a stable Jenkins tarball (in my case d105620) to the "would be" homebrew directory (/usr/local/Cellar/mono/4.1.0)
3. Added the following to my ~/.bash_profile to switch between mono versions when running dnu build and launching Visual Studio Code:

alias dnu="brew switch mono 4.1.0 && dnu"

code () {
  brew switch mono 4.0.1
  if [[ $# = 0 ]]
  then
    open -a "Visual Studio Code"
  else
    [[ $1 = /* ]] && F="$1" || F="$PWD/${1#./}"
    open -a "Visual Studio Code" --args "$F"
  fi
}

Finally, instead of disabling the watcher I enabled it by also adding this to my ~/.bash_profile:

export MONO_MANAGED_WATCHER=enabled

With all that in place I am currently running the latest DNX (1.0.0-beta5-11735 as of this post)

Active Version              Runtime Arch Location             Alias
------ -------              ------- ---- --------             -----
       1.0.0-beta4          mono         ~/.dnx/runtimes      
  *    1.0.0-beta5-11735    mono         ~/.dnx/runtimes      default

and a default yo aspnet template with an updated project.json pointing to the latest bits:

[snip]
    "dependencies": {
        "EntityFramework.SqlServer": "7.0.0-*",
        "EntityFramework.Commands": "7.0.0-*",
        "Microsoft.AspNet.Mvc": "6.0.0-*",
[snip]

and an updated Startup.cs configuration to handle recent changes (https://github.com/aspnet/Announcements/issues/13)

[snip]
        public Startup(IHostingEnvironment env, IApplicationEnvironment appEnv)
        {
            // Setup configuration sources.
            var configuration = new Configuration(appEnv.ApplicationBasePath)
[snip]

and I have a fully working restore/build/run setup. Also, as long as I launch Visual Studio Code from the command line (or ensure my current mono version is 4.0.1 prior to launching) I have full statement completion/intellisense.

[jasoncavett]

Since this is linked over from Bug 28693 on Xamarin, I wanted to add some additional details on how I have been able to recreate.

OS: OSX Yosemite 10.10.4 Mono Version: 4.0.2 (Stable 4.0.2.5/c99aa0c Wed Jul 1 14:19:56 PDT 2015)

I can recreate the issue every time after I use Bower to install dependencies.

$ dnu restore
$ bower install
$ dnx . kestrel

If I skip over the Bower install (using CDNs for my JS and CSS, for example), everything works fine.

In addition, I can also recreate this bug if I run a Gulp task to watch for changes to files in my SASS folder.

The task(s):

gulp.task("sass-compile", function() {
  gulp.src([paths.scss], {
    base: "."
    })
    .pipe(sass())
    .pipe(gulp.dest("."))
});

gulp.task("watch-sass", function() {
  gulp.watch([paths.scss], ["sass-compile"]);
});

Just to be sure, I ran sass --watch input_folder:output_folder and the issue occurred there as well.

[ChidoYo]

There's a solution that worked for me here: https://github.com/OmniSharp/generator-aspnet/issues/138 Adding the following to the ~/bash_profile : export MONO_MANAGED_WATCHER=false Worked for me and I'm on OSX 10.11.1 I was getting the error above after installing new bower components.

[rideddy84]

export MONO_MANAGED_WATCHER=false worked for me on OS X El Capitan today.

[aspnet-hello]

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.