OwinStartup not firing

Make sure you have installed Microsoft.Owin.Host.SystemWeb package in the project. This package is needed for startup detection in IIS hosted applications. For more information you can refer to this article.

If you've upgraded from an older MVC version make sure you don't have

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

in your web.config. It will suppress calling the startup logic.

Instead change it to true

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

I realize you already mentioned this but sometimes people (like me) don't read the whole question and just jump to the answers...

Somewhere along the line - when I upgraded to MVC 5 this got added and I never saw it until today.

Alternative answer to the original problem discussed - Owin "not firing." In my case I spent hours thinking it wasn't firing due to being unable to set a breakpoint in it.

When debugging OWIN startup in visual studio

IIS Express - Running "F5" will break on the OWIN startup code

IIS - Running "F5" will not break until after OWIN (and global.asax) code is loaded. If you attach to W3P.exe you will be able to step into it.

If you are having trouble debugging the code in the Startup class, I have also had this problem - or I thought I did. The code was firing but I believe it happens before the debugger has attached so you cannot set breakpoints on the code and see what is happening.

You can prove this by throwing an exception in the Configuration method of the Startup class.

DEBUGGING TIPS

If debugging does not work try using IIS Express or try the method below for local IIS

Using local IIS

For some reason this method enables debugging of this method:

Request a webpage Attach to w3wp.exe process Touch the web.config file Request a webpage

Extra tip

Maybe doing this will flush a cache:

In web.config add the optimizeCompilations attribute with a false value Run site Undo the change in web.config

I had a similar issue to this and clearing Temporary ASP.NET Files fixed it. Hope this helps someone.

I had the same problem. Microsoft.Owin.Host.SystemWeb package was installed but during the installation NuGet was not able to add the dll as a reference for some reason. Make sure your project has that reference. If not you can try to reinstall:

update-package Microsoft.Owin.Host.SystemWeb -reinstall

I had an error like below on reinstall but somehow it worked:

System call failed. (Exception from HRESULT: 0x80010100 (RPC_E_SYS_CALL_FAILED))

I had same problem when I added Owin to an existing web project. I eventually found the problem was due to the following in the web.config file.

<assemblies>
  <remove assembly="*" />
  <add assembly="System.Web.Mvc" />
  <add assembly="System.Web.WebPages" />

   ...

</assemblies>

The remove assembly="*" was causing the problem. When I remove this line the Owin startup code ran. I eventually change it to the following and it worked perfectly

<assemblies>
  <remove assembly="*" />
  <add assembly="Microsoft.Owin.Host.SystemWeb" />
  <add assembly="System.Web.Mvc" />
  <add assembly="System.Web.WebPages" />
  <add assembly="System.Web.Helpers" />
...
</assemblies>

In my case this Microsoft.Owin.Host.SystemWeb package is present in the project.

But below two tags are not present in web.config.

<add key="owin:AutomaticAppStartup" value="true" />
<add key="owin:appStartup" value="namespace.className.methodName" />

after adding them it works smoothly.

In my case, the IIS application pool was not set to v4. It was v2.

Changed the AppPool to v4 and everything was okay.

In my case, my web.config had

<authorization>
  <allow users="?" />
</authorization>

To force it to fall back to Owin, I needed it to be

<authorization>
  <deny users="*" />
</authorization>

In my case, my website's output path is changed by somebody, the IIS Express even not load OWIN, and the setup class will not be hit of course. After I set the output path as "bin\", it works well.

I found the following article to be very helpful:

https://weblog.west-wind.com/posts/2015/Apr/29/Adding-minimal-OWIN-Identity-Authentication-to-an-Existing-ASPNET-MVC-Application#MinimalCodeSummary

In my case, I had to set the following before Owin authentication would work instead of windows authentication:

<system.web>   
    <authentication mode="None" />   
<system.web>

This worked for me:

add authentication mode="None"

<system.web>
    <compilation debug="true" targetFramework="4.6.1" />
    <httpRuntime targetFramework="4.6.1" />
      <authentication mode="None" /><!--Use OWIN-->
  </system.web>

I am not sure if this will still help someone, but I've done all of the solutions above (and from some other posts) to no avail.

What fixed the issue on my end was to put a backslash to the end of RedirectUri value in the web.config (crazy, I know!). RedirectUri is a parameter in UseOpenIdConnectAuthentication.

So, instead of:

<add key="ida:RedirectUri" value="https://www.bogussite.com/home" />

Do this:

<add key="ida:RedirectUri" value="https://www.bogussite.com/home/" />

And updated the Reply URL on the Azure App Settings as well.

That somehow made the Startup to run as expected (probably cleared some cache), and the breakpoints are now firing.

FYI. I was modelling my code from here: https://github.com/microsoftgraph/aspnet-connect-sample

After converting a class library to a Web Application Project, I ran into this and became stubborn. Turned out, in my .csProj file, I had this:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>bin\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>bin\Release\</OutputPath>
  <DefineConstants>TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
</PropertyGroup>

thus building the various dll's into a subfolder of the bin-folder (which ifc. won't work). Solution was to change both text-contents for OutputPath to just bin\.

For me it was because they are not in the same namespace. After I remove my AppStart from "project.Startup.AppStart" and let they both Startup.cs and Startup.Auth.cs with "project.Startup" namespace, everything was back to work perfectly.

I hope it help!

If you are seeing this issue with IIS hosting, but not when F5 debugging, try creating a new application in IIS.

This fixed it for me. (windows 10) In the end i deleted the "bad" IIS application and re-created an identical one with the same name.

I think what some people were trying to get to above is that if you want to programatically make your OWIN server "come to life", you'd be calling something like this:

using Microsoft.Owin.Hosting;

    IDisposable _server = WebApp.Start<StartupMethod>("http://+:5000"); 
              // Start Accepting HTTP via all interfaces on port 5000

Once you make this call, you will see the call to StartupMethod() fire in the debugger

In case you have multiple hosts using the same namespace in your solution, be sure to have them on a separate IISExpress port (and delete the .vs folder and restart vs).

I messed around with a lot of the suggestions on this post.

I had the following but still could not land on a break point. Throwing an exception proved the code was being entered.

<appSettings>
...
  <add key="owin:AutomaticAppStartup" value="true" />
  <add key="owin:appStartup" value="SSOResource.Startup, SSOResource" />
...
</appSettings>

Finally out of desperation I looked at project->properties, and then under the WEB section I also checked the NATIVE CODE checkbox (ASP.NET should be already checked).

That finally fixed it for me.

Note : I am using Visual Studio 2017 Professional.

First add the OWIN Auth Class and then enable OWIN:AutomaticAppStartup key in your web.config like Now it will fire