Archive for February, 2010

Web Service Connection Actively Refused. You are running Cassini.

February 25, 2010

Scenario:
You are eating your liver because when you try to access your Web Service your app crashes with

No connection could be made because the target machine actively refused it

The Stack Trace includes the following:
SocketException (0x274d): No connection could be made because the target machine actively refused it 127.0.0.1:1204]
System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) +239
System.Net.Sockets.Socket.InternalConnect(EndPoint remoteEP) +35
System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception) +224

[WebException: Unable to connect to the remote server]

Why the Pain ?

Quite possibly your Web Service is not running in any Web Server. In my case IIS was not set up on my local machine and I am therefore using Cassini, the built-in Web Server with Visual Studio.

BUT

While there was a Cassini process for my Web App there was no Cassini process for my Web Service. The sucker was moribund. No wonder it didn’t work. The solution is to start your Web Service which I did by starting a Cassini process for it.

In Visual Studio:

1) Set StartUp project as WebService
2) Run project (i.e. hit F5)
3) A Cassini Process starts up. This is the one serving your WebService. Never let it stop.
4) Now make your Web project that consumes your web Service your StartUp Project
5) Run it.
6) Another Cassini Process starts up. This one is serving your web site
7) Bob’s your nerdy cousin with the extreme ear wax. i.e. you will now be able to use your Web Service and the horrifying Active Refusal error message is gone.

So to make that clear, if you’re running Cassini, you need one Cassini Process for each Web Service you are consuming plus another Cassini Process to serve your actual Web Site. In my case I have one Web service so I need a total of two Cassini processes running to support my application.

Slightly misleading error message there. Should say “Web Service is not running.” ‘Actively refused’ makes me think of Credentials…and repressed memories about asking chicks out when I was a teenager, stuff like that.

Advertisements

Yet Another Reason Why Breakpoints Will Not Be Hit In Visual Studio: You are running Cassini.

February 24, 2010

I would imagine this is probably the most common reason why breakpoints are not hit: the Web Application is running under Cassini.

Cassini is the built-in Web Server that comes with Visual Studio 2005/2008. It’s a lightweight Web Server provided to spare you the trouble of setting up IIS on your local machine. But being lightweight it can’t do everything and one thing it cannot do is provide debug support. This ASP.NET forum post, ‘Debugging aspx hosted by Cassini’ provides some discussion on the issue.

To debug in Visual Studio when running Cassini you have to manually attach the debugger to the Cassini Process.

To paraphrase Kiliman in his forum post:

In VS.NET, it’s Debug | Processes…

Find WebDev.WebServer.exe in list of running processes and click Attach. Make sure Managed Code or Automatic is selected from the Attach To: DropDownList

If you don’t want to manually attach the debugger every time, then make your site IIS based then go to the Project Properties and change your settings from from internal webserver to IIS.

Here’s an interesting tip from an old Cassini information page for Framework Version 1.1 that allows you to Debug under Cassini without manually attaching that might still work in later Framework versions. I haven’t tried it myself yet. Basically you make Cassini the Start Application for your Debug Build Configuration and define your Web App as a Command Line Parameter.

The reason that Cassini cannot participate in Visual Studio .NET Debugging without the debugger manually attaching to the process is that Visual Studio Debug Builds send a special (non-standard) HTTP Request to the Server using the DEBUG Verb called a Debug HTTP Request. IIS knows how to handle Debug HTTP Requests but Cassini does not.

The DEBUG Verb is used by IIS to verify that the process of the application is running and to automatically select the correct process to attach the Visual Studio debugger to. Its a non-standard HTTP Verb invented by Microsoft for its own purposes, that’s why generic Web Servers like Cassini don’t handle it. See Stack Overflow here.