There are times when developing that I want to be able to see what the contents will be for emails generated from my application, but I do not want the emails to actually go to the reciepients.  In addition I may not have my local development machine set up to relay mail.

Sometime, updating the development system email addresses to a generic address makes sense.  Other times, I do not or cannot do this, so instead, I opt for the following technique.

With this approach, you add a configuration setting to your config file, and the result is that the email will be placed in a directory of your choosing, but will not actually be sent.

To accomplish this, add the below setting to your config file:

 <system.net>
    <mailSettings>
      <smtp deliveryMethod='SpecifiedPickupDirectory'>
        <specifiedPickupDirectory pickupDirectoryLocation="C:\All\Maildrop" />
      </smtp>
    </mailSettings>    
  </system.net>

 Now, when you send your email using code similar to below, the email will appear in the directory you specified.

 MailMessage message = new MailMessage();
 message.From = new MailAddress(...

... other code to set to, body goes here

SmtpClient smtpClient = new SmtpClient();
smtpClient.Send(message);

If you are using Visual Studio and you want to debug a windows service, you may recieve the following message:

Cannot start service from the command line or a debugger.  A Windows Service must first be installed (using installutil.exe) ...

There are ways to avoid this message and this site provides a good approach http://www.worldofasp.net/tut/WindowsService/Creating_Windows_Services_in_NET_99.aspx

I have also found that in Visual Studio if you have a break point set within your service and you run the service in debug mode you can just leave the message pop up in place.  Basically, if you get the pop up, but do not click out of it, just leave things as they are and wait for the first "tick" in your service, it will then run and hit your break point.  This seems to be a work around and hopefully if you are in a pinch and need a quick way to debug a service, this will work for you.

When using the LINQ to SQL designer surface in Visual Studio, each time you add an object (table, procedure, etc), you will end up adding connection string information to your config file.  This can be confusing as the names used for the connection string may be different then what you want to use and you may end up with multiple connection strings, especially if you have multiple developers working on the same project.

To address this issue, you can:

1. Create a partial class for your data context and create a parameter-less constructor as follows
   
   public partial class LinqAppDataContext
       {
           public LinqAppDataContext()
               : base(ConfigurationManager.ConnectionStrings["AppConnectionString"].ToString())
           {
   
           }
       }
   
   In this example, I already have a LinqAppDataContext class, and I am creating a partial class that calls the constructor on the base class that takes a connection string.  I then pull this connection string from the config file.
   
   
2. Step 1 is a one time setup.  The remaining steps need to be followed each time you add a new object to the designer surface
   
   
3. Add a new object to the designer surface (for example, drag a table from the Server Explorer)
   
   
4. Click on an empty section of the designer surface (dbml file)
   
   
5. In the properties window, go to Connection, then clear the information from the Connection String property and then set the Application Settings property to false.  By doing this, the parameter-less constructor from step 1 above will kick in and pull the connection string from your config file.
   
   
6. Verify that no extra connection strings have been added to your projects settings or config files