c# '' - OWIN Startup Class Missing

the to (17)

Have a look for the Startup.cs file, you might be missing one of these. This file is the entry point for OWIN, so it sounds like this is missing. Take a look at OWIN Startup class here to understand whats going on.

As your error specifies, you can disable this in the web.config by doing the following...

To disable OWIN startup discovery, add the appSetting owin:AutomaticAppStartup with a value of "false" in your web.config

I'm getting this error as my project is not able to find the reference for OWIN startup class. I've even installed all the OWIN reference packages through Nuget still getting the same issue. I'm using Visual Studio 2012 and MVC4.

The following errors occurred while attempting to load the app.

  • No assembly found containing an OwinStartupAttribute.
  • No assembly found containing a Startup or [AssemblyName].Startup class. To disable OWIN startup discovery, add the appSetting owin:AutomaticAppStartup with a value of "false" in your web.config. To specify the OWIN startup Assembly, Class, or Method, add the appSetting owin:AppStartup with the fully qualified startup class or configuration method name in your web.config.

My case? I had startup file, but it is excluded in the project. I just included it and the error left.

I kept getting the same error when I started my project using the Browser Link Dashboard in VS2013. But, when I ran my project in debug mode, it would work. I could not figure out why and how to get the Browser Link Dashboard working. I checked the startup file, it was fine, added the appSetting line as described in some of the answers "", but nothing worked.

Apparently, what I was doing wrong was clicking on the WRONG link in the Browser Dashboard. All the Solutions projects links show in the Browser Dashboard, but only the startup projects link works. You need to click on the link of the startup project.

Example: I have 2 projects, both show in the Browser Dashboard, but only the one marked as the start up project will work (shows as bold in the Solution Explorer.) I thought this may help someone do the obvious, it cost me 2 days to stumble on to the obvious.

If you don't want to use the OWIN startup, this is what you should add to your web.config file:

Under AppSettings add the following line:

    <add key="owin:AutomaticAppStartup" value="false" />

This is how it should look like in your web.config:

    <add key="owin:AutomaticAppStartup" value="false" />

Are you really trying to add OWIN to your project or is this something unexpected?

  1. In case you want to add OWIN, adding a Startup class is the way to go.

  2. In case you don't need any reference to Owin:

    delete Owin.dll from your /bin folder.

    Owin.dll is the one trying to identify the Startup class.

I had this problem, understand this isn't what was wrong in the OP's case, but in my case I did have a Startup class, it just wasn't finding it by default.

My problem was the I had spaces in my Assembly Name, and hence the default namespace was different from assembly name, hence the namespace for the startup class was different than the assembly name.

As the error suggests, by convention it looks for [Assembly Name].Startup for the class... so be sure the namespace for your Startup class is the same as the Assembly name. Fixed the problem for me.

This could be faced in Visual Studio 2015 as well when you use the Azure AD with a MVC project. Here it create the startup file as Startup.Auth.cs in App_Start folder but it will be missing the

[assembly: OwinStartup(typeof(D_ToolsWebApp.Startup))]

So add it and you should be good to go. This goes before the namespace start.

I tried most of the recommended fixes here, and still couldn't avoid the error message. I finally performed a combination of a few recommended solutions:

  1. Added this entry to the top of the AppSettings section of my web.config:

    <add key="owin:AutomaticAppStartup" value="false"/>

  2. Expanded the References node of my project and deleted everything that contained the string OWIN. (I felt safe doing so since my organization is not (and won't be) an active OWIN provider in the future)

I then clicked Run and my homepage loaded right up.

Create One Class With Name Startup this will help you..

public class Startup
   public void Configuration(IAppBuilder app)

In our project, we didn't need the OWIN functionality, so we removed all the owin references from the initial ASP.NET MVC template project. The problem occured after removing the OWIN startup class.

The problem was the extra owin dll's in my bin folder. When I deleted them, the problem was resolved. You should delete them by deleting the bin folder. Clean Solution does not delete these dlls.

Somehow, IIS still executes the OWIN dll's when they are in the bin folder.

While I can't fully explain why this solved the issue for me, I ran into a problem like this after I changed my API project to build to separate \debug and \release folders. Once I reverted that change back to build to a single \bin folder things started working.

I wrote up my experience here: Can't get the OWIN Startup class to run in IIS Express after renaming ASP.NET project file

I had this problem when I got the latest on TFS while other projects were open in multiple instances of VS. I already have all the fixes above. Reopening VS fixed the problem.

On Visual Studio 2013 RC2, there is a template for this. Just add it to App_Start folder.

The template produces such a class:

using System;
using System.Threading.Tasks;
using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(WebApiOsp.App_Start.Startup))]

namespace WebApiOsp.App_Start
    public class Startup
        public void Configuration(IAppBuilder app)
            // For more information on how to configure your application, visit http://go.microsoft.com/fwlink/?LinkID=316888

I ran into this problem after experimenting with SignalR and then removing it from the project. To resolve I had to delete the contents of the bin folder for the site on the remote server and then publish again.

In my case I logged into ftp server. Took backup of current files on ftp server. Delete all files manually from ftp server. Clean solution, redeployed the code. It worked.

Just check that your packages.config file is checked in (when excluded, there will be a red no-entry symbol shown in the explorer). For some bizarre reason mine was excluded and caused this issue.

Thanks to Kiran Challa's comment and source code from this answer I was able to figure out that an assembly (the ReportViewer 11 assembly for SQL Server Reporting Services) was missing on the production server.

Although no ApiController is in this assembly it seems to cause that controllers in assemblies - in this case my Web project's assembly - that are referencing the missing assembly are not found.

Apparently this behaviour is related to this piece of code from the Web API's DefaultHttpControllerTypeResolver source:

List<Type> result = new List<Type>();

// Go through all assemblies referenced by the application
// and search for types matching a predicate
ICollection<Assembly> assemblies = assembliesResolver.GetAssemblies();
foreach (Assembly assembly in assemblies)
    Type[] exportedTypes = null;
    if (assembly == null || assembly.IsDynamic)
        // can't call GetExportedTypes on a dynamic assembly

        exportedTypes = assembly.GetExportedTypes();
    catch (ReflectionTypeLoadException ex)
        exportedTypes = ex.Types;
        // We deliberately ignore all exceptions when building the cache. If 
        // a controller type is not found then we will respond later with a 404.
        // However, until then we don't know whether an exception at all will
        // have an impact on finding a controller.

    if (exportedTypes != null)
        result.AddRange(exportedTypes.Where(x => IsControllerTypePredicate(x)));

I don't know if it has to be this way and I am not quite convinced by the comment in the code but this catch ... continue block is rather silent about a possible problem and it took me a huge amount of time and frustration to find it. I even knew that the ReportViewer wasn't installed yet. I tried to install it and dependent assemblies but it was blocked by another running process on the server, so I decided to postpone the installation until I could contact the administrator and focus on MVC and WebAPI testing first - big mistake! Without Kiran's debugging code snippet I had never had the idea that the existence of a ReportViewer.dll could have anything to do with controller type resolution.

In my opinion there is room for improvement for the average developer like me who doesn't have a deeper knowledge about the inner workings of Web API.

After installing the missing ReportViewer.dll the problem disappeared.

Here are questions about the same symptom which might have the same reason:


I have issued a request for improvement on CodePlex:


Edit 2 (Aug 11 '13)

The issue has been fixed for WebAPI v5.0 RC. See the link above to the workitem and its comments section for details.

c# asp.net-mvc-4 visual-studio-2012 owin