Static Analysis has interested me for nearly as long as I’ve been coding, so when I was offered to try out NDepend I got really excited. I already rely on the warnings the compiler can give and code analysis rules for my projects and a tool such as NDepend seems like the next logical step. I was not disappointed.
I think that the code analysis rules offered by Visual Studio are powerful and helps improve code quality, but they have a user experience that’s more punishing than encouraging. Code Analysis rules are evaluated after the code is written and after it has passed the compilation – which means when you are sort of done. Then it comes and tells you that you’re not done. That’s demoralising. There’s also no hint of how many rules you did in fact dit pass. The NDepend analysis is different. It is run from the NDepend Dashboard and it shows not just rules violations, but it can also show that your code is good.
With Coveralls.IO it’s possible to get code coverage on all pull requests submitted. For Kentor.AuthServices I’ve set up AppVeyor builds that uses Coveralls.Net to upload coverage numbers to Coveralls.IO.
When I set up the code coverage I already had AppVeyor builds running. I wanted something that worked together with AppVeyor. I tried out a few options and quickly found out that I also wanted something that used the Visual Studio Code Coverage engine. The project had 100.00% coverage in Visual Studio when I started and when I tried another coverage engine it showed some lines as skipped. I wanted consistency with the Visual Studio Code Coverage, which coveralls could give me.
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.