New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brand new ASP.NET project: internal server error. #508

jbehrens94 opened this Issue Apr 29, 2015 · 18 comments


None yet
Copy link

jbehrens94 commented Apr 29, 2015

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

This comment has been minimized.

Copy link

suhasj commented Apr 29, 2015

What version of Mono do you have ? There is a bug open for Mono on this I think it might be fixed in the latest 4.0.1 but can you confirm your version ?


This comment has been minimized.

Copy link

barranger commented Apr 30, 2015

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


This comment has been minimized.

Copy link

TomSchillemans commented Apr 30, 2015

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


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=, Culture=neutral, PublicKeyToken=null'.

This comment has been minimized.

Copy link

migueldeicaza commented Apr 30, 2015

Set a higher limit for file descriptors open:

ulimit -n NNN


This comment has been minimized.

Copy link

ielcoro commented Apr 30, 2015

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 :-(


This comment has been minimized.

Copy link

jrock2004 commented Apr 30, 2015

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


This comment has been minimized.

Copy link

ielcoro commented Apr 30, 2015

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?


This comment has been minimized.

Copy link

riccardo-moschetti commented Apr 30, 2015

@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


This comment has been minimized.

Copy link

whiteboardmonk commented May 1, 2015

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

$ ulimit
$ mcs --version
Mono C# compiler version
$ dnx --version


This comment has been minimized.

Copy link

pauldipietro commented May 2, 2015

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


This comment has been minimized.

Copy link

thierryrama commented May 2, 2015

Same here with

Euler:FirtWebApp thierry$ ulimit
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.
    TLS:           normal
    SIGSEGV:       altstack
    Notification:  kqueue
    Architecture:  amd64
    Disabled:      none
    Misc:          softdebug
    LLVM:          supported, not enabled.
    GC:            sgen
Euler:FirtWebApp thierry$ dnx --version

This comment has been minimized.

Copy link

ilyaskorik commented May 3, 2015

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


This comment has been minimized.

Copy link

jbehrens94 commented May 5, 2015

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


This comment has been minimized.

Copy link

miguellira commented May 8, 2015

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 ]]
    open -a "Visual Studio Code"
    [[ $1 = /* ]] && F="$1" || F="$PWD/${1#./}"
    open -a "Visual Studio Code" --args "$F"

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


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:

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

and an updated Startup.cs configuration to handle recent changes (aspnet/Announcements#13)

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

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.


This comment has been minimized.

Copy link

jasoncavett commented Jul 17, 2015

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 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: "."

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

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


This comment has been minimized.

Copy link

ChidoYo commented Nov 16, 2015

There's a solution that worked for me here:
Adding the following to the ~/bash_profile :
Worked for me and I'm on OSX 10.11.1
I was getting the error above after installing new bower components.


This comment has been minimized.

Copy link

ace-eddy commented Feb 11, 2016

worked for me on OS X El Capitan today.


This comment has been minimized.

Copy link

aspnet-hello commented Dec 31, 2017

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.

jkotalik pushed a commit that referenced this issue Nov 1, 2018

Panwang/addinglog (#508)
* adding windows event log

* adding windows event log

* fix a wrong bool variable

* some updates

* fix bad merge

natemcmaster added a commit that referenced this issue Nov 14, 2018

Disable building the VSIX in 2.2 by default (#508)
We don't release the UserSecrets VSIX from this branch

ryanbrandenburg pushed a commit that referenced this issue Nov 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment