When developing a system that sends mails, often the mails shouldn’t be sent for real when testing. Instead they should be made available for investigation. Fortunately, that functionality is built in with the .NET SmtpClient.
There is even no need to change the code. It’s just a matter of configuration. Add the following lines to the app.config (or web.config for web applications)
<system.net><mailSettings><smtpdeliveryMethod="SpecifiedPickupDirectory"from="[email protected]"><specifiedPickupDirectorypickupDirectoryLocation="c:\temp"/><!-- The network host setting isn't used, but without it an exception occurs when disposing of the SmtpClient.--><networkhost="localhost"/></smtp></mailSettings></system.net>
<system.net>
<mailSettings>
<smtp deliveryMethod="SpecifiedPickupDirectory" from="[email protected]">
<specifiedPickupDirectory pickupDirectoryLocation="c:\temp" />
<!-- The network host setting isn't used, but without it an exception
occurs when disposing of the SmtpClient.-->
<network host="localhost"/>
</smtp>
</mailSettings>
</system.net>
The pickup directory setting is meant to be used with a local mail server that watches a directory for new mails. I have no mail server watching my c:\temp directory. Instead, the mails are just dropped there as .eml-files that can be opened using a mail program (e.g. outlook).
Recently I was involved in a problem where we had a WCF service referencing a 32 bit dll. The service was set to to “Start WCF Service Host when debugging another project in the same solution”. Unfortunately that ended up with an exception.
Could not load file or assembly ‘My32BitLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. An attempt was made to load a program with an incorrect format.
When a CLR process starts, the exe file determines if it will be loaded as a 32 or 64-bit process. In this case the WcfSvcHost.exe is started as a 64-bit process, loads the service dll (compiled as “Any CPU”) and then fails when trying to load the My32BitLib assembly which is compiled as “x86”.
The solution is to create a special 32bit version of WcfSvcHost and setup the debugging environment to use that instead of the standard WcfSvcHost
Entity Framework Migrations are handled from the package manager console in Visual Studio. The usage is shown in various tutorials, but I haven’t found a complete list of the commands available and their usage, so I created my own. There are four available main commands.
There are lot of code generation tools available. Microsoft Visual Studio has had code generation possibilities since I started using it in the mid 90-ties. Code generation can be a blessing for getting something up and running quickly, but also a curse when maintaining code.
Whenever a code generation tool is considered, there are two very important aspects that need to be considered:
Is there support for regeneration when the code needs to be updated?
Are there possibilities to make adaptions without loosing them on regeneration?
Unfortunately a lot of the tools fail on at least one of these points. The blessing that helped creating something working quickly becomes a curse during further development and maintenance.
When developing a system that sends mails, often the mails shouldn’t be sent for real when testing. Instead they should be made available for investigation. Fortunately, that functionality is built in with the .NET SmtpClient.
