While using ASP.NET 5, maybe you have some problems that you haven’t got the answer about how to deal with. In this tutorial, we will show you most common issues related with ASP.NET 5 and how to solve it if sometimes you face this kind of issues.

 

Solving Some Issues Related With ASP.NET 5

Incompatibilities

Here is the most common issue related with ASP.NET 5 that people usually find hard to resolve. When things break, it’s likely because you’re running your application on an incompatible DNX. If you ever see method missing of type missing exception or possibly an assembly load failure, chances are you ended up running betaX packages and betaY DNX or vice versa.

How to solve?

Just keep in mind that everything you see here is new. This project system is brand new (written from scratch), the NuGet client is new, the DNX is new and evolving quickly. You can make sure your DNX and packages are on the same version. Even more specifically, Assembly Neutral Interfaces were removed in beta4 but still exist in beta3 (more on this later) so if you an exception like this:

System.IO.FileNotFoundException: Could not load file or assembly  
'Microsoft.Framework.Runtime.IApplicationEnvironment,
  Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies.

It’s because that type has moved and a package you are referencing is trying to load the ANI still. Then, we’ve had plans to make it so that packages can mark the minimum DNX that they require to run to make the error message more clear. Also as time goes by, the breaking changes will die down and this issue will fade away.

Dependencies

Dependencies you put into project.json are top level only (this is unlike packages.config where the entire package closure is expanded directly). Versions are also always minimums (it’s just like a NuGet package). This means that when you specify Foo 1.0.0-beta4 you’re really specifying Foo >= 1.0.0-beta4. This means if you ask for MVC 0.0.1 and the minimum versions on your configured feeds is MVC 3.0.0, you’ll get that one. We also never float your version unless you specify it. If you ask for 1.0.0 and it exists, you will get 1.0.0 even if newer versions exist. Specifying empty versions is always bad and will be disallowed in later builds.

How to solve?

There’s a new NuGet feature called floating versions. Today it only works on the prerelease tag, but in the next version of NuGet it’ll work on more parts of the version. This is similar to npm and gem syntax for specifying version ranges in the package specification file.

1.0.0-* – Means give us the highest version matching the prefix (according to semantic versioning rules) or if there is no version matching that prefix, use normal behavior and we’ll the lowest version greater than the specified version. If you’re interested, you can see the new logic in the latest NuGet.Versioning packages. When you run restore in the latest builds, it will write out a file called project.lock.json. This file will have the transitive closure of dependencies for all target frameworks defined in project.json.

Step 1 – Getting to Know The project.lock.json

Think of it as a packages folder per project. In NuGet today, you get a solution level packages folder. That tells the project (via hint paths) what set of packages it can use for compilation and running. The project.lock.json file is effectively the same thing, it’s a “per project packages folder”, since we don’t copy anything local in the new project system (your bin folder is empty), it’s a way to scope the list of packages in %userprofile%\.dnx\packages so that projects don’t just run based on the global set of packages, but the ones that are relevant to that project. On top of that, it also stores the list of files and relevant content for compilation and runtime so that the runtime only has to read a single file instead of N nuspec files at startup time. This actually cut the startup time in 1/2 on azure websites.

Another function of the lock file is when you choose to check it into source control. If you run kpm restore –lock it will set the “locked”: true property in the file. When you actually lock the lock file (hence the name), kpm restore no longer does dependency resolution. It will just download the files listed in the lock file. This way it acts more like a packages.config.

Step 2 – Diagnosing Failures

When you get a build or runtime failure you can do the following way. Just take a look at the resolved dependencies using kpm list. This will show you the resolved versions of packages referenced by your project and what dependency pulled it in. Actual kpm list output:

Listing dependencies for ClassLibrary39 (C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json)

[Target framework DNX,Version=v4.5.1 (dnx451)]

 framework/Microsoft.CSharp 4.0.0.0
    -> ClassLibrary39 1.0.0
 framework/mscorlib 4.0.0.0
    -> ClassLibrary39 1.0.0
 framework/System 4.0.0.0
    -> ClassLibrary39 1.0.0
 framework/System.Core 4.0.0.0
    -> ClassLibrary39 1.0.0
*Newtonsoft.Json 6.0.1
    -> ClassLibrary39 1.0.0

[Target framework DNXCore,Version=v5.0 (dnxcore50)]

*Newtonsoft.Json 6.0.1
    -> ClassLibrary39 1.0.0
 System.Runtime 4.0.20-beta-22709
    -> ClassLibrary39 1.0.0

*means direct dependency

If you have a working visual studio (which breaks with DNX right now), you can look at the references node. It has the same data represented visually:

Let’s look at what a dependency failure looks like. Here’s the project.json:

{
    "version": "1.0.0-*",
    "dependencies": {
        "Newtonsoft.Json": "8.0.0"
    },

    "frameworks" : {
        "dnx451" : { 
            "dependencies": {
            }
        },
        "dnxcore50" : { 
            "dependencies": {
                "System.Runtime": "4.0.20-beta-22709"
            }
        }
    }
}

Newtonsoft.Json 8.0.0 doesn’t exist. So running kpm restore shows the following:

When diagnosing when restore might have failed, look at the HTTP requests made, they tell you what configured package sources kpm looked in. Notice in the above image, there is a CACHE request. This is the built in caching based on the type of resource (nupkg or nuspec) and has a configurable TTL (look at kpm restore –help). If you want to force kpm to hit the remote NuGet sources, use the –no-cache flag:

These errors also show up in Visual Studio in the package manager log output window:

You can read more about NuGet.config here to learn about how packages sources work and how they affect your application. When dependencies are unresolved, running the application will give you this:

> dnx . run
System.InvalidOperationException: Failed to resolve the following dependencies for target framework 'DNX,Version=v4.5.1':
   Newtonsoft.Json 8.0.0

Searched Locations:
  C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\{name}\project.json
  C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\test\{name}\project.json
  C:\Users\davifowl\.dnx\packages\{name}\{version}\{name}.nuspec
  C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\{name}.dll
  C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\{name}.dll
  C:\WINDOWS\Microsoft.NET\assembly\GAC_32\{name}\{version}\{name}.dll
  C:\WINDOWS\Microsoft.NET\assembly\GAC_64\{name}\{version}\{name}.dll
  C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\{name}\{version}\{name}.dll

Try running 'kpm restore'.

   at Microsoft.Framework.Runtime.DefaultHost.GetEntryPoint(String applicationName)
   at Microsoft.Framework.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
   at Microsoft.Framework.ApplicationHost.Program.Main(String[] args)

The runtime basically tries to validate that the entire dependency graph is resolved before attempting to run. If it suggests running kpm restore it’s because it can’t find the dependencies listed.

Another reason why you might get this error is if you’re running the wrong dnx flavor. If your application only specifies dnx451 and you try to run the dnx-coreclr, you might see a similar problem. Pay close attention to the target framework in the error message:

dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}

When you’re trying to run, you should remember that mental mapping from clr to target framework defined in your project.json. This also shows up in Visual Studio under the references node:

Best and Recommended ASP.NET 5 Hosting

If you are looking at creating website of your own, hosting it with ASP.NET 5 can be a great choice. While there are various companies today who offer you ASP.NET 5 hosting services, it is extremely important for you to understand and compare the features that various companies offer. To make this search easier for you, we have listed down top 3 hosting providers which you need to compare for the best and recommended ASP.NET 5 hosting.