1
votes

I have a solution in VS2013 with the following setup:

  • App.Web (Web Project with only static files)
  • App.Web.API (Web API project with OWIN)

Both the projects have a default url pointing to their own localhost:portX (I am using IIS Express), so App.Web is listening on localhost:2222 and APP.Web.API is listening on localhost:3333.

I set up the App.Web.API to use OWIN and I added the package Microsoft.Owin.Host.SystemWeb for the autofire up in IIS.

I put a breakpoint in the configuration method of the OWIN startup class.

When I set the APP.Web.API as "startup project" in VS2013 the breakpoint is hitted.

But as soon I set the App.Web as "startup project" and then from the browser I make a request to the App.Web.Api, the breakpoint at the Startup class is not hitted anymore.

I tried to follow some suggestions found on the net (cleanup IIS Temp files, using OWIN attibute etc..) but it's not working.

It seems that with IIS Express the OWIN is only firing up if the project containing it is set as Startup Project.

Can someone explain what is happening?

1

1 Answers

1
votes

You can only have one project "Set as StartUp project" in your solution. This project will be the Start point of you App, and you can debug your application based on this "Start Point".

When you setup your App.Web.API as your Startup project, you will be able to debug your application in the Startup.cs of your Web Api.

When you setup your App.Web as your Startup project, you wouldn't be able to debug your application in Startup.cs of the Web Api project, because the Startup.cs is fired by your Web Api project, not your App.Web project.

Something that can help you is the red breakpoint button. If you set a breakpoint in the Startup.cs and you Start your App.Web project, you will be notice that the break point has a transparent color, with a warning symbol and the following message: "The breakpoint will not currently be hit. No symbols have been loaded for this document.". This means that based on your "Start Point", there's no way to get this code point.

So in your case, when you debuged your application from App.Web project, the Web Api methods were working because you had the project already attached to the IIS, and the Startup.cs was fired, but not by your debuging process, that's why the breakpoint had not fired.