The object identifier does not represent a valid object.
PROBLEM:
When attempting to "run" an ASP.NET project on IIS 7.0 using Visual Studio 2008 the following error is displayed:
RESOLUTION:
Make sure that "Windows Authentication" is enabled in IIS on the applicable web application (web site or folder).
NOTES:
That was a little frustrating for me at first. No hits anywhere in our knowledge base or on Live. I figured I would ignore this and come back to it later but after about a week I finally decided this isn't something I wanted to deal with constantly. I started to troubleshoot it versus waiting to find somebody else's solution. One of the first things Visual Studio does when trying to debug an ASP.NET application is make a DEBUG request (versus a GET or POST) to IIS. If all goes well for the DEBUG request, VS automatically attaches as a debugger to the ASP.NET worker process (w3wp.exe in this case) and to IEXPLORE.exe. So into the IIS logs I went to see the result of that DEBUG request. Here was the entry for my failed debug attempt:
#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2008-06-03 12:11:16
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Cookie) sc-status sc-substatus sc-win32-status time-taken
2008-06-03 12:11:16 ::1 DEBUG /WebApp/Default.aspx - 80 - ::1 - - 401 0 0 157
You may notice that this is a 401.0. Normally when a "browser" (VS2008 in this case) first makes a request it is always anonymous. Then after seeing a 401, it will follow up the first request with a second request that includes credentials. In the IIS logs we'd expect to see a 401.2 (unauthorized due to sever configuration - i.e. I'm not accepting anonynous), then if using NTLM we'd see a 401.1 (NTLM challenge - i.e. you have only sent me half the credentials for that NTLM handshake) then finally a success status such as 200 (OK), 302 (Moved/Redirect), or 304 (Not Modified). Or if using Basic authentication or Kerberos there would be the 401.2 then the success status for the next log entry since those methods don't have a handshake. In my case here there was only a single 401 with no follow up attempt. Hmm... Why no follow up request with credentials? Next stop - IIS manager.
After highlighting my "WebApp" folder and double-clicking "Authentication" (shown above) in the IIS manager I saw that only Anonymous was enabled. Oh right... IIS 7.0 is secure by default. VS was making it's anonymous request and since IIS returned no "WWW-Authentication" headers specifying which auth method it is accepting, VS quit there. IIS 7.0 has only anonymous enabled by default and administrators have to consciously open up their server by enabling additional authentication types. After enabling "Windows Authentication" as well leaving "Anonymous" enabled, debugging worked fine. Thanks for the great error!!
Hope this helped somebody.