Run ASP.NET5 web application with Kestrel server on Windows - asp.net-core

Question

I have successfully run the 'HelloWeb' sample from the ASP.NET5 GitHub repo with the Kestrel server on Windows 8.1 by using:
dnx . kestrel
Now I want to run my own application with kestrel. I tried it from Visual Studio 2015RC and with several runtimes using dnx directly. The result is always:
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the
requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.RuntimeAssembly.get_DefinedTypes()
at Microsoft.AspNet.Hosting.Server.ServerLoader.LoadServerFactory(String serv
erFactoryIdentifier)
at Microsoft.AspNet.Hosting.Internal.HostingEngine.BuildApplication()
at Microsoft.AspNet.Hosting.Internal.HostingEngine.Start()
at Microsoft.AspNet.Hosting.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Framework.Runtime.Common.EntryPointExecutor.Execute(Assembly ass
embly, String[] args, IServiceProvider serviceProvider)
at Microsoft.Framework.ApplicationHost.Program.ExecuteMain(DefaultHost host,
String applicationName, String[] args)
at Microsoft.Framework.ApplicationHost.Program.Main(String[] args)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Framework.Runtime.Common.EntryPointExecutor.Execute(Assembly ass
embly, String[] args, IServiceProvider serviceProvider)
at dnx.host.Bootstrapper.RunAsync(List`1 args, IRuntimeEnvironment env)
at dnx.host.RuntimeBootstrapper.ExecuteAsync(String[] args)
at dnx.host.RuntimeBootstrapper.Execute(String[] args)
Is there any way I can find what types cannot be loaded?
Update
Here is the project.json
{
"webroot": "wwwroot",
"version": "1.0.0-*",
"dependencies": {
"Microsoft.AspNet.Mvc": "6.0.0-beta6-14023",
"Microsoft.AspNet.Server.IIS": "1.0.0-beta6-11864",
"Microsoft.AspNet.Server.WebListener": "1.0.0-beta6-12245",
"Microsoft.AspNet.StaticFiles": "1.0.0-beta6-11996",
"EntityFramework.SqlServer": "7.0.0-beta6-13336",
"EntityFramework.Commands": "7.0.0-beta6-13336",
"Microsoft.Framework.ConfigurationModel.Json": "1.0.0-beta5-11337",
"Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta6-12521",
"Microsoft.AspNet.SignalR.Server": "3.0.0-beta6-12519",
"Microsoft.AspNet.Authentication.OAuthBearer": "1.0.0-beta4",
"Kestrel": "1.0.0-beta4"
},
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5000",
"kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004",
"ef": "EntityFramework.Commands"
},
"frameworks": {
"dnx451": { },
"dnxcore50": { }
},
"exclude": [
"wwwroot",
"node_modules",
"bower_components"
],
"publishExclude": [
"node_modules",
"bower_components",
"**.xproj",
"**.user",
"**.vspscc"
]
}
I tried to start it with Kestrel from within VS and set Kestrel to use the following runtime which resulted in the shown error messages in VS.
Runtime: 1.0.0-beta6-11921 .NET Framework x86
Exception thrown: 'System.Reflection.ReflectionTypeLoadException' in mscorlib.dll
Exception thrown: 'System.Reflection.TargetInvocationException' in mscorlib.dll
Exception thrown: 'System.Reflection.ReflectionTypeLoadException' in mscorlib.dll
Exception thrown: 'System.Reflection.ReflectionTypeLoadException' in Microsoft.Framework.ApplicationHost.dll
Exception thrown: 'System.Reflection.TargetInvocationException' in mscorlib.dll
Exception thrown: 'System.Reflection.ReflectionTypeLoadException' in mscorlib.dll
Exception thrown: 'System.Reflection.ReflectionTypeLoadException' in dnx.host.dll
Final update
The problem was the kestrel package version. For whatever reason the Nuget manager only suggested me Kestrel beta 4 while all other packages got installed as beta 6. After manually setting Kestrel to beta 6 in project.json everything worked. I accept Gerald Davies answer as he gave me the right direction.

Answer 1

The error would seem to indicate a mismatch between the runtime being used, the runtime expected by the application, and possibly the dependencies available for the specific runtime.
First use dnvm list and verify which runtime is being used (active). Please post that in an update. If the wrong runtime is set to active you will need to change that using dnvm use. Also compare this to the values in global.json for your solution.
You may need to restore dependencies. This can happen if the build in VS is using a different runtime than what is set as active by dnvm. You can force a dependency restore by dnu restore.
A `dnu restore' is always needed but VS sometimes hides this by doing it automatically as dependencies change but only for the current runtime VS is executing against. Remember dependencies may vary by runtime.
This is complicated by the fact the VS uses global.json to determine which dnx to execute against (version, runtime, and architecture) but on the command line unless explicitly indicated dnx/dnu use the "active" runtime set by dnvm. Technically dnvm just sets the path to a particular runtime so when use execute dnx or dnu you are running a specific one (version, runtime, and architecture) depending on what the path is.
The key thing is that the dnx that VS executes against and the dnx that you execute against on the command line are not necessarily the same. Changing the "target" in VS (global.json) or in dnvm (dnvm use) doesn't automatically update the other.
So for example VS may automatically restore dependencies for the beta4 version of non-core clr x86 dnx but due to the path (set by dnvm) when you execute on the command line you are executing against beta6 version of the core clr x64. If those dependencies have not be restored then you will get an error.

Answer 2

To find the real cause of the exception, you can debug this error by using --debug switch of dnx. Try:
dnx --debug . kestrel
Then you can attach to dnx.exe with Visual Studio and see the exact exception and retrieve it's LoaderExceptions property. I had similar problems, both caused by runtime mismatch and source code errors.