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@example.com">
<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
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 commands.