I've been using the macro from this blog entry for attaching the Visual Studio debugger to an already running instance of the Web Application I'm currently working on. However, if I have more than one instance of the Visual Studio web server running it's pot luck which one it'll attach to.
Is there a way to determine what port is configured in the Web project so I can modify the macro to filter its choice of process to that one?
Further Info
I'm aware that you can set the port number to a static one - I've done just that from the get-go, what I'm trying to determine is how to programatically determine the defined port-number so I can modify the macro (in the linked blog entry) and ensure it connects to the right instance of the Visual Studio web server.
The way I have things running is I have two (or more) instances of Visual Studio running, each of which contains a Solution, which contains a web project and one or more other projects - typically an Installer project), so when I trigger the macro from a given instance of Visual Studio, I want to find the Web Project within that instances loaded solution and determine the port it's running against.
This code will get you a list of all ports for the projects in the current solution:
Sub GetWebProjectPorts()
Dim ports As String
For Each prj As Project In DTE.Solution.Projects
For Each p As EnvDTE.Property In prj.Properties
If p.Name.Contains("DevelopmentServerPort") Then
If Not String.IsNullOrEmpty(ports) Then
ports += ","
End If
ports += p.Value.ToString()
End If
Next
Next
MsgBox(ports)
End Sub
If that can help you, I have found a link that might actually to the trick.
However, it require DllImport call and a lot of fun.
You can take a look at that article there: http://bytes.com/forum/thread574901.html
Quotes from the actual site:
By calling into iphlpapi.dll using
PInvoke interop. Google around for
GetExtendedTcpTable and iphlpapi.dll,
I'm sure you will find some existing
stuff.
Willy.
And one last:
Here are some API-Methods for my
purposes:
GetTcpTable()
AllocateAndGetTcpExTableFromStack()
GetExtendedTcpTable()
I wrote a small programm that is able
to show me all Processes with the
belonging TCP-Ports (with
AllocateAndGetTcpExTableFromStack())
running under Windows XP.
Now my problem is, that under Windows
2000 I can't use
AllocateAndGetTcpExTableFromStack() or
GetExtendedTcpTable() so I'm only able
to use GetTcpTable() to list all
TCP-Ports but without the belonging
processes.
Did somebody have the same problem or
is there another way (.Net or WMI
etc.) to solve my problem?
Thanks in advance,
Werner
If you go to the properties for your web project and look under the "Web" tab, you can specify which port the project will always start up on. Then you can click "Enable Edit and Continue" so you don't have to stop debugging and restart continuously.
Related
We are developing an (internal) web service based on asp.net 4.8, with a fairly extensive REACT SPA front end.
For debugging purposes during development, we run an IIS server on the local (development) machine, and we do something separate to run a proxy web server for debugging the .js front end SPA (not relevant to the question at hand).
When we start up a Debug session in Visual Studio (2019), VS starts with "Contacting web server to start debugging" and then locks for a time. It clearly does something to start the web server (w3wp.exe), and waits for some reply, before doing what it is told to do in the "Start Action" section of the Web tab on the project properties page.
This is problematic behaviour because it does not attach to w3wp.exe until after it finishes it's "contacting web server to start debugging" operation. This is a huge problem, as our w3wp.exe starts doing all kinds of things that we have no visibility into.
So, can anyone explain to me:
What does VS actually do to "contact the web server"?
Can this be controlled? If so, how?
Can I get the debugger to attach to w3wp.exe right away?
Why does w3wp.exe start up and load its collection of binaries, only unload them and reload them, sometime multiple times?
In short, what the actual heck is going on under the covers at startup?
This (Identity Server 3 Contacting the web server hangs when launching debug mode) question and answer seem irrelevant to my situation
I note the field Override application root URL in the Servers section of the Web tab of the project properties and had hoped this might have something to do with it, but I cannot see any relation.
Partial answers that I will either edit as I find more info, or modify if others correct me, or delete if someone answers completely. The answers to (1) and (2) above are this:
VS obtains the URL of the target web site (I will call this targetServer) from the Project URL entry in the Servers section, Web tab, of the Properties page for the web project. This actually comes from the <webProjectName>.csproj.user file in the project directory. Depending on the selection of the drop down specifying the server type to use, it comes from:
IIS server (<UseIIS>true): the <IISUrl> element
External Host (<UseCustomServer>true): the <CustomServerUrl>
IIS Express: unknown
WARNING: When opening a project with <UseIIS>true, Visual Studio has the very nasty habit of interfering in the setup of your IIS server: it insists on changing the "Physical Location" attribute of the IIS server (that is, the server or virtual app, however you have it set up) to point to the project directory of the web project. Using the "External Host" option avoids this - see https://stackoverflow.com/a/48753054/1082063. (All other discussions of this issue that I have seen incorrectly say this cannot be controlled.)
VS then issues a request to the url <targetServer>/debugAttach.aspx, and the request shows as neither a "GET" nor a "POST", but a "DEBUG", whatever that is. Not sure what VS expects back from this before doing the specified Start Action
Presumably after VS gets some reply from its DEBUG request, it will attach to the process that resulted from this request. Not sure how it knows which process to attach to - perhaps the debugAttach.aspx returns process information?
VS finally executes whatever Start Action is specified in the section of that name on the Web tab of the project Properties.
I strongly suspect that the answer to (3) above is that one cannot get VisualStudio to attach any earlier than it does because it must use the information returned from the debugAttach.aspx request to know which process to attach to. However, putting the line System.Diagnostics.Debugger.Launch(); at the start of Application_Start will allow you to attach the debugger earlier when necessary. (In practice, once you get Application_Start correct, you seldom need to debug it.) See this: https://weblog.west-wind.com/posts/2011/Dec/15/Debugging-ApplicationStart-and-Module-Initialization-with-IIS-and-Visual-Studio for a very good article on the subject.
(4) was a result of quirks in our Visual Studio setup. The initial "hack" used to get around the WARNING in answer (2) just above, was to have a web site with a dummy "virtual path" and have the IISUrl element in Visual Studio point to this virtual path. Then VS could change the Physical path of this virtual path, and we didn't really care, because our Start Action was to start a proxy server for debugging .js in any case. The issue was that this resulted in two calls to Application_start, running on two separate threads: one for the main server and one for the virtual server. Because one of these was happening before the attach happened, we never knew it was happening and it was never caught in a break point. When our application_start became long (timewise - this is not a web server for public consumption...), the two executions of application_start became a nightmare.
The issue you're seeing in IIS is that VS is not launching w3wp.exe, but rather Attaching to Process. In order for VS to attach though the EXE has to be running first, and the time between starting up and attaching (if not already running) ends up being too late to catch the ASP.NET app initialization logic in Application_Start and Module initialization.
As mentioned in my old post there are several ways you can get this to work:
Restarting the application when the debugger is already attached
(by making a change in web.config to trigger an AppDomain reload)
Adding an explicit Debugger.Break() call in Application_Start
Use IIS Express to debug startup code
I've noticed that Visual Studio like to change the port used for my application from time to time, and I was wondering why. After some Stack Overflow reading, I've found solutions to prevent this (it is possible to assign a static port). However, I do not find it to be a problem (merely a curiosity) and do not need to a assign a static port. I just want to know why it does that.
While debugging my application, VS will run on one port. On another run 5 or ten minutes later, it will run on an entirely different port. As far as I know, no other processes on my machine are using these same ports, so why the change? Once it finds an available port, why does it not continue to use it?
This is by design. Either you can have random ports every time, or you can assign a fixed one per project. Keeps things simple I guess (rather than figuring out if the previously used port is taken or not and then based on that, use the old one or a new one)!
As Mrchief said, this is by design. You can opt to use IIS by creating a virtual directory and making the appropriate selection on the Web tab of the project properties.
Then your URL (can debug also) will look like:
http://localhost/myproject
Port 80 will now be the default :)
I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.
I have three Silverlight 3 applications in the same solution. In my asp.net hosting project I have a seperate page for all three projects. When I navigate between the pages, the only Silverlight breakpoints that get hit are the ones the initial page I load.
This problem has only started recently. I used to be able to debug between all silverlight projects at the same time. Any ideas? I have deleted the ClientBin folder, I have deleted all files and re-retrieved from source control. Nothing seems to be working.
"The problem has only started recently". What changed? Here are some guesses:-
You upgraded to Windows 7
You installed some more memory
Some other memory guzzling app is no longer running when you are testing.
By default IE8 will run multiple processes at least 2. One for the browser frame and one for the content of the intial tab. As you open more windows and tabs IE may add new processes to the set it is currently using.
When you debug VS will launch an new IE8 session and will attach to the process handling the content of the single tab that is open, (it doesn't bother attaching to the parent frame process). However as you navigate about your application IE8 will start new process that VS won't be attached to. This forces you to open the Attach to Process dialog and do it manually.
You can control this IE8 feature (called BTW LCIE, Loosely Coupled IE) from the Registry.
In the Key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main add a new DWORD value TabProcGrowth. Set its value to 1. Now IE8 will only ever create 2 processes per session one for the frame and one for all the tab and window contents which is the one the VS will attach to.
This perhaps is a bit draconian if you also use IE8 as your general browser. One option is to leave IE8 for test purposes and use another browser for general browsing. Another option is a variation of the above. Instead of creating TabProcGrowth as a DWORD create it as a string type instead and set is value to "small". In this mode IE8 is much less aggressive in the number of processes it will open. Of course you could create a couple of scripts to create and delete the registry entry.
Note without the registry entry IE8 uses its own hueristics that depends on available memory etc to determine if a new process is warrented or not. This might explain why in the past your debugging worked and that for apparently no reason it stopped working.
Here was the issue:
One of my child windows had a Silverlight that calling a .Net Ria Service. The service call ended in an error.
The next time several I debugged, the debugger did not attach to the child windows. I had to attach to the child windows manually.
I fixed the Ria Service call so that it did not end in an error. And had to manually attach to the child windows in that debugging session. However in subsequent debugging sessions, the debugger automatically attached.
I tried breaking the Ria Service call and I had to manually attache again. What is a little weird is that closing Visual Studio and even rebooting the machine does not make Visual Studio automatically attach again. You have to have a debugging session where the child window make a sucessful call to a Ria Service to fix it.
NOTE:
The RIA error that was breaking my debugger was caused by a misspelled include in the domain query (ie...
return Context.SOME_ENTITY.Include("Misspelled_Association_Property");
) not all RIA exceptions cause this problem.
My scenario has a number of specific cases that I will go over. I don't have all the things handy to test a more general scenario, but I will when I finish my project unless someone does this first.
Here is what I have:
I am using the a LinqToEntitiesDomainService from the July 2009 Preview release of .Net RIA Services.
To complicate things a little more, since my application is using an Oracle backend, I am using DevArt's dotConnect Entities provider as the EntityFramework model for my domain service.
When I get time, I will try this on the Nov 2009 RIA and a standard SQL backend and EF to see if I still have the same issue. If this is the case I will report it to Microsoft as a visual studio bug.
When you run an application from within visual studio, it seems to pick a random port on localhost. For example, running an application right now, I get
http://localhost:3240/ApplicationStuffHere
I realize this port gets loaded into the solution file, via
VWDPort = "3240"
How does this get decided on? it seems fairly random.
By default, ASP.NET Web Application Projects are configured to launch and run using the built-in VS Web Server (aka Cassini) on a random HTTP port on the machine.
This port number can be changed if this port is already in use, or if you want to specifically test and run using a different number:
(source: scottgu.com)
I know this is a little bit old, but I was wondering the same thing. I eventually found the answer for VS2005, but figured I'd share it with the stack overflow community.
Open your project
Click (not right click) on the name of the project in the solution explorer (that top, bolded line)
Hit f4 - this will bring up a properties panel
Change "Use dynamic ports" to False
Optionally change the Port number to whatever port you want to use
And you're done.
This port number is initially assigned randomly, but Visual Studio will try to use that same port number every time the application starts.
Check out the Properties of your web application in solution explorer (Right click > Properties)
The web tab is the one you are looking for.
Kindness,
Dan