Visual Studio is setting up my Azure web role to 127.255.0.0:82 instead of 127.0.0.1:80 - visual-studio-2010

I have Windows Azure SDK 1.6 installed along with Azure tools. I have one web role (with two endpoints, port 80 for http and port 443 for https) and only have one instance of the web role running (for testing purposes).
When I ran it from Visual Studio for debugging last week, it ran the emulator, attached it to IIS with a binding of 127.0.0.1:80 and everything was peachy.
But as of yesterday, as soon as I started it was trying to bind it to 127.255.0.1:82 and it stopped working with this error (from Visual Studio):
There was an error attaching the debugger to the iis worker process
for URL 'http://127.255.0.0:82'
Now if I manually go to IIS and change the bindings back, I can access the site through a browser but obviously I can't debug it via VS.
Why is Visual Studio doing this? What made it change from last week (I've only made code changes and I have commented them out)?
Edit: I know about this blog, but my issue seems to be different because for one reason I don't have errors in the event logs. And like I mentioned as soon as I change the bindings manually in IIS, I can access the site properly so the app pool is configured correctly.
Edit2: I have the following set:
<compilation debug="true" targetFramework="4.0" />
And my cloud project is set to startup project as well.

When I ran it from Visual Studio for debugging last week, it ran the
emulator, attached it to IIS with a binding of 127.0.0.1:80 and
everything was peachy.
I don't believe you ever debugged a Azure Emulator deployed project on 127.0.0.1:80 binding with IIS. There is a chance that what you've debugged is just the Web Application project and not the Azure Deployed one. Let me explain why:
Windows Azure Emulator uses internal emulated Load Balancer (LB).
This emulated LB binds to 127.0.0.1 port 80 (if port 80 is already
taken it uses port 81)
Windows Azure Tools are dynamically creating a virtual IP address
for every instance of a webrole you have. These dynamic IP Addresses
are 127.255.0.X, where X is the logical number of the instance (0,
1, 2, etc...).
Windows Azure tools creates a website in the local IIS, with binding
of 127.255.0.X and port 82
Step 3 is repeated for every instance you have defined.
When start debugging, your browser usually opens http: //127.0.0.1:81/ which is the address of the LB. But the request from this address is forwarded to the IIS and its binding to 127.255.0.X:82. You could not have debugged a Windows Azure Emulator deployed project by manually attaching debugger to 127.0.0.1:80, because, if everything was fine there is no w3wp process listening on that address:port, but Azure emulated LB.
When you only have the WebRole (no additional sites defined), Windows Azure Tools does know that it shall attach the debugger to 127.255.0.X:82 where a w3wp process is listening.
This is the clean working configuration of Azure Emulator & SDK & Tools v.1.6 (I think also 1.5 and even back to 1.3 where the Full IIS mode was introduced for first time)
Now if I manually go to IIS and change the bindings back, I can access
the site through a browser but obviously I can't debug it via VS.
Yes, you will be able to access the site, but in that way you are skipping the emulated LB, which is not the point when developing Windows Azure Applications.
If you are heving issues of that kind, I suggest that you clean your solution, restart the computer, and if the problem persist uninstall the SDK & Tools and perform clean full install of SDK & Authoring tols for Windows Azure v.1.6 using the Web Platform Installer.

Related

Remote Debugging of Azure Web Application

I'm currently using visual studio 2017 and trying to attach the debugger to my web app. I've deployed my app and i've attached the debugger through VS. I've also ensure on the azure portal that remote debugger is turned on. I've also went to https://xxxxxxxx.scm.azurewebsites.net/ and checked the processes and w3wp is available. From Unable to start debugging in VS2015 for Azure web app and Remote Debugging - Web App Azure it indicated to me it could be a port being blocked. so i went ahead and set my firewall outbound to allow the connections from UDP 3702 TCP 4020 TCP 4021 and ports 4022 and the problem still persist. I'm unable to connect to my connection target.
I've tried xxxxxxxxx.azurewebsites.net:4022 and xxxxxxxxx.azurewebsites.net
I'm all out of ideas and suggestions from the web. If anyone else has tips, that'll be great.
unable to connect to my connection target.
Please refer to this article to configure the firewall to enable remote debugging for VS 2017.
Remote debugging works for me using VS 2017 with following steps:
Turn on Remote debugging and choose VS 2017
Find and attach to process
Please try to enter {your_web_app_name}.azurewebsites.net:4022 and click Refresh button to check if you can see available processes.
Besides, you can right-click your web app, and then click Attach Debugger to remote debug the web app in Server Explorer.
Updates:
Get publish profile on portal

Problems debugging web role remote on Microsoft Azure

I am trying to debug a webservice remote on Microsoft Azure. The service is running in a web role.
I have configured remote debugging in the publish settings an can attach the debugger to the web role. Also, when I have selected the correct process, the debug symbols are loaded correctly and breakpoint's tool tips say that the breakpoint is hosted in "WallSHost.exe" which is the remote process.
What I would like to do, is to run a local client software which I am developing and step into the server code from there. When I step into the according service client call (F11), I get the above error message, saying (for the sake of Google in plain text here):
Unable to automatically step into server. Connecting to the server
machine 'xyz.cloudapp.net' failed. The Microsoft Visual Studio Remote
Debugging Monitor (MSVSMON.EXE) does not appear to be running on the
remote computer. This may be because a firewall is preventing
communication to the remote computer.
I have tried to disable the firewall on my (the client) machine with no effect. Has anybody seen that before or can tell me how fix this problem?
A quick checklist
deployed cloud service is a debug build
a debug build is selected from Build Configuration list (in publish wizard)
'Enable Remote Debugger For All Roles' is checked
no changes to code since deployment

How do I run (debug) WCF REST Service application on local IIS7 server

As the question says, I have a problem running the web app on local IIS.
Here is my situation:
WIndows over Oracle VM VirtualBox running on Linux Ubuntu.
Bridged Adapter so that Windows box gets local IP from my router.
Visual Studio 2010 + sp
WCF REST Service application plugin for project template
The application runs when using visual studio development server (on localhost).
Target framework is v4.0
What I need is that the application runs on IP instead on localhost (so I can consume it on remote computer in LAN), so I configured IIS7.
Here is IIS configuration:
I created a website with target framework v.4.0
I binded the site to my local IP on port 80
Path to the site is /inetpub/wwwroot iisstart.htm as default document
IIS runs ok. If I open "http://my_local_ip" I get the welcome logo.
The problem is in visual studio.
When I go to project properties "Web" section and select local IIS over vsd server is where I get lost. If I set "Project URL" to "http://my_local_ip/some_name" visual studio complains that it cannot find IIS server and so it was unable to create the virtual directory. I tried manually adding virtual directory in IIS manager, but no effect. If I use "http://localhost/some_name" as the "Project URL" the virtual directory gets created, but it makes no sense does it?
Could some one please enlighten me?
If I use "http://localhost/some_name" as the "Project URL" the virtual directory gets created, but it makes no sense does it?
I think you are mixing two different things here. When you ask VS to use localhost as the IIS Server for your project, it will connect to the local IIS to perform configuration tasks. If you ask VS to use "my_local_ip" you are telling VS that you IIS Server is remote, and therefore VS will use remote administration to configure IIS (VS can't know that my_local_ip is the local computer).
But remote IIS admin isn't enabled on a default WinServer box. Furthermore, it would require some additionnal network config. You should therefore tell vs to use the local server.
In fact, IIS site bindings and VS deployment parameters are too completely different things. So, deploy your site on http://localhost/your_site.
However, I don't really like the prospect of using VS debugging deploy to deploy a real app. The directory will contain all your project files... You should:
create your site on IIS manager and setup a virtual directory.
Either
ask VS to publish the site to a directory (your virtual directory)
ask VS to publish a WebDeploy package, then ask IIS manager to import the package.

Debugging ASP.NET MVC project in VS2010 and accessing on networked computers

I'm wondering if it's possible to allow users on my local network to connect to an ASP.NET MVC 3 app I'm running through VS2010 on my local PC. The purpose is to let others test during some rapid application development without deploying to a server.
By default, the port seems to be blocked. Is there a setting in VS2010 or IIS Express that I can change to allow access to it?
By default VS sets localhost bindings in applicationhost.config file (%userprofile%\documents\iisexpress\config\applicationhost.config), so you cannot access it from other machines.
To access your site from other machines,
you need to update your site bindings (in applicationhost.config file) and add a site binding with your machinename
Run VS as administrator
If firewall is blocking your port, unblock it
Following link may help you
Configure IIS Express for external access to VS2010 project

step into web service on another LAN server

I'm debugging a vb.net windows program which I've upgraded to a VS 2010 solution, targeting Framework 2. I need to step into a webservice's code. The web service is framework 3.5, also vb.net, running on a windows 2003 server on our LAN. I've seen a ton of crap on the Net about it, mostly other people who couldn't get it working either.
The error I get in VS2010 is the exact same one I got before upgrading the project from VS 2005:
Unable to automatically step into the server. Connecting to the server
machine [servername] failed. The Microsoft Visual Studio
Remote Debugging Monitor (MSVSMON.EXE) does not appear to be
running on the remote computer. Please see Help for assistance.
So I did what Help said to do and ran the VS 2008 remote debugging wizard on the host server. I have verified that the remote debugger is running as a service on that machine. And it still fails.
Little help? THANKS
Just in case anyone comes here looking for this answer, here it is. No goofy 'Attach to Process', no weird bad instructions
from websites going off on a million stupid tangents. This answer has been FALKENIZED.
When on the same LAN and on the same domain, remote debugging from Visual Studio 2010 works when you do the following steps.
on web service host machine, share the web application folder where the web service lives; give yourself 755 permissions.
oops, give yourself wrxr permissions.
on local development machine, map a network drive to the [web service host machine][web app] folder you just shared.
copy the Visual Studio 2010 remote debugger folder (containing msvsmon.exe + support files) to web service host machine.
Make sure you get the correct platform for your host server, e.g. x86, x64, etc. Remote debugger is found here:
C:\Program Files\Visual Studio 2010\Common7\IDE\Remote Debugger[platform]
on web service host machine, drag a shortcut from the newly-copied debugger to the desktop, then start the remote debugger
on local development machine, step thru code. when reaching a call to the web service, you'll be prompted to navigate
to the location of requested web service code file, which will then be available in your mapped path. Do it.
Finally after 1000000 headaches, you may start debugging your web service. CONGRATULATIONS

Resources