Debugging Web Services on Your Local Machine

Scenario: Visual Studio 2005, one solution, two projects; one project is your Web Service project, the other your client. IIS is not on your client.

• Clicking "Properties" of the Web Services project, click the "Web" tab. Change the entry under "Use Visual Studio Development Server" from "Auto-assign Port" to "Specific port".
• Clicking "Set Startup Projects" of the solution, change the entry from "Current selection" to "Multiple startup projects." Change the Action from "None" to "Start."
• Make sure your client project is set up as the Startup Project.
• If you haven't already, add the Web Reference in your client project, choosing "Web Services in this solution."
• Make sure that your dependencies are set so that your client project is dependent upon your Web Services project.

Now when you debug, each time you press F5 you will start up the Cassini web server at the port you hard coded in Step 1; then your client project will run and connect to the service. Terminating the debugging session will terminate both your client and the Web Services projects.

This could eliminate your getting the "System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it" exception in the Reference.cs file.

CruiseControl.NET VSS SSDIR

Switched from a test SourceSafe database to production, which was on a separate machine. The ccnet.config file used to have a line that specified the srcsafe.ini file, saying
<ssdir>C:\local\srcsafe.ini</ssdir>
which worked fine.

I switched it to
<ssdir>\\remotemach\vssdb\srcsafe.ini</ssdir>
and started getting the message
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: No VSS database (srcsafe.ini) found. Use the SSDIR environment variable or run netsetup.

I stumbled around for a while, but finally changed the <ssdir> tag to just the directory, removing the srcsafe.ini file, as in
<ssdir>\\remotemach\vssdb\</ssdir>
and that got it working.

Batch FxCop and Visual Studio's Website Project

Using Continuous Integration, you want to run FxCop against the build. Using Visual Studio's new "Website" project (Rick Strahl has some commentary about it), the aspnet_compiler creates DLLs with random names embedded. This is good, because it's unlikely that that DLL is cached anywhere. But it's bad, because FxCop wants to know what the DLL names are.

There's probably a better way to handle it, but we simply run aspnet_compiler twice: the first time with the -fixednames parameter, running FxCop against that build, then the second time without the -fixednames parameter generating uncached DLLs.

NAnt String Concatenation

I'm not familiar with Ant, but in NAnt, the plus sign can act as a string concatenation operator, so you can say something like

<mkdir dir="${work-dir}\Svcs" if="${not directory::exists(work-dir+'\Svcs')}">

You can also use the Concat function. Both are documented.

Thunderbird / SpamPal / SSL / STunnel / 2 ISPs

Lots of good info setting up SpamPal with STunnel to communicate with ISPs requiring SSL for email. But recently, my ISP also required SSL, and I was already using the STunnel connection for Google.

Not a problem. Just make two entries in your stunnel.conf file, like so:

; incoming email from GMail
[pop3gm]
accept = 127.0.0.1:1110
connect = pop.gmail.com:995

; incoming email from ISP
[pop3is]
accept = 127.0.0.1:1111
connect = pop.myisp.com:995

In Thunderbird, the "User Name" in the Server Settings of Account Settings is My.Name@gmail.com@localhost:1110 for the GMail account, and My.Name@myisp.com@localhost:1111 for the ISP.