[asp.net-mvc] OwinStartup not firing

I had the OwinStartup configuration code working perfectly and then it stopped working. Unfortunately I'm not sure exactly what I did to get it to stop working and am having a really hard time figuring it out.

To make sure I have the basics covered, I doubled checked to make sure the I have the

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

attribute assigned properly and made sure that I don't have an appSetting for owin:AutomaticAppStartup that is set to false so I made one set to true to be safe as there was nothing there before.

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

I also tried specifically calling out the appSetting:

<add key="owin:appStartup" value="WebApplication.Startup" />

Before it stopped working I upgraded the Microsoft.Owin.Security NuGet packages to 2.0.2, so I tried reverting them to 2.0.1 (that was a pain) but it didn't change anything. I have WebActivator installed on the project and am using that to bootstrap other things but I've tested that on a fresh WebApplication template and it works there so I don't think that is the culprit.

I also tried removing my Startup class and using Visual Studio to add a new one using the OWIN Startup Class type in Add New Item and that isn't getting called either. Next I tried adding a second Startup class since I know it will throw an exception if there is more than one OwinStartup attributes defined, but it isn't throwing any exception there.

Not sure what else to try. Any thoughts?

Update

Turns out that Resharper removed the reference to Microsoft.Owin.Host.SystemWeb when I used it to remove unused references.

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.

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>

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!

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>

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.

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.

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>

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>

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.

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

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

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.

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

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).

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

Changed the AppPool to v4 and everything was okay.

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))

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:

1. Request a webpage
2. Attach to w3wp.exe process
3. Touch the web.config file
4. Request a webpage

Extra tip

Maybe doing this will flush a cache:

5. In web.config add the optimizeCompilations attribute with a false value

   <compilation debug="true" ... optimizeCompilations="false">

6. Run site

7. Undo the change in web.config

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

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\.