4

I have a solution with many projects. On Debug, I have three web projects that I want to start up on their own Cassini ASP.NET web development servers. In the solution properties → Common PropertiesStartup Project, I have multiple startup projects chosen with the three web applications' Action set to Start. All three web development servers start, and all three web pages load.

However, Visual Studio is only attaching to two of the WebDev.WebServer.EXE processes. I have to manually go attach to the third process in order to debug it with the debugger.

This behavior just started happening, and I'm at a loss as to how to troubleshoot this.

Also to note, I have stopped and restarted the development servers several times with no change in behavior. Also, when attaching to the process manually, I see that the Type property of the two automatically attached WebDev.WebServer.EXE processes is Managed, while the Type property of the unattached WebDev.WebServer.EXE process is TSQL, Managed, x86. When looking at the project's properties, however, I am targeting AnyCPU, and do NOT have SQL Server debugging enabled.

The two projects that attach correctly are C# web applications.

<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>

The project that is not attaching correctly is a VB.NET web application.

<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</ProjectTypeGuids>

The behavior is the same on another workstation. So odds are that it's not a machine-specific problem.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Aaron Daniels
  • 9,563
  • 6
  • 45
  • 58
  • Possible duplicate of *[The Visual Studio debugger is not attaching when at the root of a website](https://stackoverflow.com/questions/911250)*. – Peter Mortensen Apr 14 '18 at 17:29

5 Answers5

1

This might be a shot in the dark, but I would look at the csproj files, to see if the one that isn't working has any obvious differences. In particular, I would look for a <ProjectTypeGuids> element. Anything that relates to web-hosting is of interest too, of course; so anything under:

<ProjectExtensions>
  <VisualStudio>
    <FlavorProperties GUID="{349c5851-65df-11da-9384-00065b846f21}">
      <WebProjectProperties>

(or similar, depending on your flavor of project; compare between the 3 for anything that looks out of place)

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • I edited my question and specified my ProjectTypeGuids. When comparing the ProjectExtensions section, the only difference between the three different projects is the port number. – Aaron Daniels Dec 14 '09 at 15:10
  • hmmm... ok, it was worth looking though. – Marc Gravell Dec 14 '09 at 16:27
  • I agree. I think you got me looking in the right direction though. – Aaron Daniels Dec 14 '09 at 16:38
  • I'm thinking the issue may be around the code types the debugger is using. Why would the one vb.net project be T-SQL, Managed, and x86? Whereas the others are simply managed. Would a strongly typed dataset cause this? I have Native Code and SQL Server options unchecked in the Project Properties - Web - Debuggers section. – Aaron Daniels Dec 14 '09 at 19:16
0

I set multiple startup projects and choose each of the web applications in the properties of the solution (Right click the solution in Solution ExplorerProperties).

Is the third project an IIS web project (set in properties)? We have numerous IIS projects that run together and we don't have any issues debugging.

Try solution → PropertiesConfiguration PropertiesConfiguration and see what projects get build and when.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Burt
  • 7,680
  • 18
  • 71
  • 127
  • All three are web application projects. The only difference is that the one that wont attach to the debugger is a VB.NET project, whereas the others are C# projects. – Aaron Daniels Dec 14 '09 at 15:14
0

Not sure what the problem might be, but when I've had problems with complex projects before I've found it helps to look at the .vbproj or .csproj files directly.

Have you tried creating a new VB.NET project and simply copying over the files from the non-working project?

I'd also try adding a 4th, very simple C# web application project to see if perhaps 3 is some sort of magic number for your configuration (though I'm currently working on a solution with more than 3 and have no problems debugging). You could do the same with a simple VB.NET web application - you'll know then whether it's a problem with webserver #3, VB.NET in general, or your specific project.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
chris
  • 36,094
  • 53
  • 157
  • 237
  • Looking through them, I cannot find any discernible differences. I've created a new VB.NET project just to see if it was something to do with VB.NET, but it worked just fine. I didn't copy everything over as it is a large web application under source control. Plus, I would like to know what is causing the issue just as much as I want the issue fixed. – Aaron Daniels Dec 14 '09 at 19:19
  • 1
    If you copy everything over to the new project, in theory the .vbproj file should look the same as the one that's not working. Diff them, and you may have a clue as to what's causing the problem. You don't have to check in the changes, if you find the problem is in the .vbproj file you can simply edit it then check it in. – chris Dec 14 '09 at 19:42
0

Right click on the main solution -> Properties -> Common Properties -> Start Up Project ->

Make sure it's set to "Multiple startup projects" and all are set to "Start" instead of none or start without debugging.

Also double check each projects .user file and make sure AlwaysStartWebServerOnDebug is set to true along with any other debugging options.

JKG
  • 4,369
  • 2
  • 17
  • 10
0

Is debugging enabled in the Web.config file of the web application? Is it set to Debug mode when you start it in Visual Studio?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Venemo
  • 18,515
  • 13
  • 84
  • 125
  • Yes. The other two projects attach just fine. If those weren't configured, nothing would attach. Thanks for the thought though. – Aaron Daniels Dec 17 '09 at 16:22