1

I've got a situation where I needed to change the solution and project names within a OWIN-based WebAPI website. Everything worked great before this change, and to my knowledge the renaming was successful because of the following:

  1. The solution builds fine and all my unit tests run sucessfully both locally and on our TeamCity build server
  2. The application runs fine on our test server (full IIS 8) and in production (also full IIS 8)

My issue is that after this rename I can not get the Startup class to execute when I run this in IIS Express no matter what I try. I suspect there is some cached folder that contains multiple Startup class on my machine because in our test environment I needed to remove all the old DLLs that were using the previous name before things started working.

I know Startup isn't executing because I have breakpoints in it that are not firing (and in fact are not enabled because VS doesn't see the symbols loaded):

enter image description here

Here's what I've tried thus far:

  • Uninstalled IIS Express 10.0 (I have VS 2015 RC on my dev machine), clean out all IIS folders, then re-installed IIS Express 8
  • Cleaned out all temp ASP.NET folders on my dev machine
  • Cleaned out all obj/bin folders within my own solution

In my case I'm specifying the Startup class using the following in my Startup.cs:

[assembly: OwinStartup(typeof(Startup))]

...but again, this all worked just fine before I tried to renaming the solution and projects. I don't think this is a general IIS Express problem either because I can successfully run other OWIN-based solutions locally (e.g., our implementation of IdentityServer3) without issues...although that solution didn't require any name changes.

Is there some other aspect of using IIS Express that might get tripped up by changing the name of a solution or project file?

For reference I have already examined the following possible causes (without any luck): - OwinStartup not Starting ... Why? - OWIN Startup Class Missing - ASP.NET Temporary files cleanup - OwinStartup not firing

Sam Storie
  • 3,934
  • 3
  • 37
  • 70
  • Try navigate to `Startup` class in `OwinStartup` attribute using F12. – tia May 14 '15 at 16:42
  • @tia - It resolves to the class shown in the image above (i.e., the expected class). Note, I only have a single Startup class in this solution. – Sam Storie May 14 '15 at 16:45

2 Answers2

3

While I can't fully explain why this solves the issue, I was able to fix this by changing my projects to build to the regular bin/ folder.

I apologize for not mentioning this in my original question, because I didn't think it was relevant, but I had previously changed my ASP.NET project to build to bin\Debug and bin\Release depending on the configuration. This seemed to work just fine, but caused this issue once I changed the name of the projects.

Sam Storie
  • 3,934
  • 3
  • 37
  • 70
  • Changing build output to another folder, then back to bin, solved the problem for me aswell. Thanks you saved me some good amount of time!! (VS2015) – Cristian E. Apr 07 '16 at 08:35
  • Good to hear @Christian. Do you have any idea why that works? – Sam Storie Apr 07 '16 at 12:01
  • 1
    As I understand it, IIS looks for the runtime assembly in the bin\ folder specifically. So, if you're outputting to bin\Release or bin\Debug, it won't detect those assemblies. Check out a default web project template and you should see that both environments output to bin\, unlike class libraries or console apps which would have specific Debug\ and Release\ folders beneath bin\. I would guess that the project file itself wasn't synced up after the rename, and therefore it wasn't writing files to the proper folder for IIS to pick up. Using the UI to change the bin folder likely fixed that? – Dustin Cleveland Jun 26 '18 at 16:51
2

I know this is old, but just wanted to add that I ran across this using a custom template. In my case I had a working solution with a startup, made it a template but the template didn't work.

Come to find out, it was because the new project had a space in its name. So adding 

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

to my existing startup file fixed it.

Paul Roub
  • 35,100
  • 27
  • 72
  • 83
bill
  • 21
  • 1