This is a guest post by Albin Sunnanbo introducing a great hack to work with mails in test environments.
If you have a .NET application that sends emails, this is probably something for you.
PickupMailViewer is a simple web viewer for emails saved by the
specifiedPickupDirectory SMTP setting in a .NET application.
Download the source, publish to your test server, configure pickup directory and you should be up and running within five minutes.
Outgoing Emails in Test Environments
In your test environment will typically not send real emails, but rather use the specifiedPickupDirectory delivery method for your SMTP-settings in
web.config. This puts all outgoing emails as *.eml files in the file system instead of sending real emails.
IMHO that is the way to go regarding emails in your test environment.
However, there is one drawback, the emails gets dropped in a folder somewhere on your test server. Typically in a location that nobody looks at regularly. In my case I first have to connect a VPN, then open a remote desktop connection to our server, open the folder and copy the desired file back to my own computer (no eml viewer, a.k.a. Outlook, on the test server) and finally open it in Outlook.
Even worse for our testers that don’t even have permissions to login on the test machine. They have to ask a developer to get their emails out of the test system. As you can imagine this only happens when it is absolutely necessary.
In administrative systems, there is often a need to import and parse csv files. .NET actually has a built in CSV parser, although it is well hidden in a VB.NET namespace. If I had known about it I wouldn’t have had to write all those custom (sometimes buggy) parsers.
To really test the parser, I’m going to parse a csv file in the Swedish format.
Name; FactoryLocation; EstablishedYear; ProfitMillionSEK
Volvo; "Gothenburg, Sweden; Gent, Belgium"; 1926; 0,345463
#A comment line
Saab; Trollhättan, Sweden; 1945; -3 009
Note that there is an embedded
; in the FactoryLocation field of Volvo, which is part of the field text and not a field delimiter.
In the Prevent EF Migrations from Creating or Changing the Database post I showed how to prevent the application from automatically creating or updating the database. Instead I want the installation program to do that. With a Web Setup Project for the installation an MSI Custom Action is needed.
The actual work of updating the database is done by the
migrate.exe tool. To make the MSI package run it properly turned out to be a bit of a challenge. I first included
migrate.exe in the installation package to have it deployed to the
bin directory together with the assemblies of the system. There is support for running an exe file as a custom action in the web setup projects. Ufortunately I couldn’t get
migrate.exe to work unless the working directory was set to the
bin directory. The working directory for custom actions is
c:\windows\system32 by default. To handle that, a small vb-script was used.
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
web.config for web applications)
<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.-->
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=184.108.40.206, 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