Sending emails in C# is easy; for basic use cases you don’t need external resources to send a note because .NET BCL already ships it. On .Net Developer Center, there’s a short description how to do it.
Now, how to fetch the email? It turns out it is not that easy – it’s not supported by .Net BCL. I spent a while researching for the best library that matched my purposes and I want to share my views on a couple of components I looked at.
Note: Please bear in mind I was interested only in a small piece of functionality such library could provide. My need was only to fetch an email (in plain text) with attachments. That was supposed to be done via POP3. I was not really interested in features like advanced sending emails (e.g. email templates), request and delivery receipts, support for iCalendar, email in HTML, etc. To sum up, I did not test libraries from that angle and therefore this comparison will not suit needs of all developers.
Continue reading ‘Comparison of .Net libraries for fetching emails via POP3′
Visual Studio provides solid support for unit testing. One of the features are VSMDI files – test meta data file. The file is not much readable but Visual Studio comes with easy to use GUI for managing tests (grouping them in test lists, filtering, etc.).
All in all, VSMDI files are really helpful but…
- After a while there are several VSMDI files (MySolutionName1.vsmdi, MySolutionName2.vsmdi, MySolutionName3.vsmdi, …) in your project although only one is in use (and therefore added to source control). This is a known bug discovered in Visual Studio 2005. More information can be found there.
- Painful merging. Merging can be smooth or really painful. It is the latter with VSMDI. Sorry, with VSMDI there’s no such thing like merging. If you discover someone else has changed and checked in VSMDI file (conflict), just replace your local changes with server version and repeat your changes.
The reason for the mess here is each test is given ID which is a GUID which tends to change once in a while.
- Not runnable tests. This doesn’t happen too often but I’ve experienced it several times already. When you try to run some tests you are told they are not runnable because there are multiple tests with the same ID (again, IDs…) – see below. Of course you haven’t played with IDs…
At least this is an easy one (but not when you see that for the first time). Just refresh the whole test list view – select List of Tests in Test List Editor window and click refresh.
Ok, so that’s my list. Any points to add here?
It happened to me after connection to TFS was dropped. and I was moved to offline work mode. Default VSTS settings say whenever you start editing a file it will be automatically checked out and it will appear on Pending Changes window. However, after those connection problems I no longer experienced that behavior.
Solution
First of all it’s worth checking VSTS Source Control related settings according to this article. In my case everything was fine there.
The problem on my side was somewhere else. After I had gone offline I had to go online again (what a surprise?!). I was expecting that to happen after reconnecting to TFS, but that is not entirely true. What I had to do as well was use ‘Go online’ button at the top of solution explorer. Once pressed it listed all the files I had modified while in offline mode and VSTS started working as before.
Note: I assume you can rebuild the program you are having problems with because changes in its configuration settings are required.
If you are struggling with this problem you are probably running 64bit OS and executing 64bit exe that loads 32bit dll, or the other way – 32bit OS on which 32bit exe tries loading 64bit dll. For the sake of this post, let’s assume this is the former matter.
Solution
You need to assure that 32bit dll is loaded by the program with the same bittness, even if it’s running on 64bit platform.
In order to achieve that you need to change the configuration settings of the project whose outcome is that exe so that platform target is always x86, disregarding configuration platform. Let’s assume that program is written in C#.
Open project’s properties, go to Build tab and make change as below:
I’ve been using both Subversion and Team Foundation Server (TFS). Because I first used Subversion and started using TFS afterwards, I had to get used to TFS flavors. I think TFS is great but to be honest there were a few things I missed from Subversion and a few things that really annoyed me when I started using TFS.
So, this is a list of strong and weak points of TFS from the perspective of a developer who switched to it after using Subversion.
Weak points
- Subversion promotes a very clear view (similar to CVS) on the files tree on the server: trunk, branches, tags. In TFS everything is in one bag – branches are simple directories among the other content of ‘the trunk’. It still looks messy to me.
- If you want to edit a file you need to check it out for edit so that it’s listed in Pending Changes window after it’s changed. If you edit a file directly in Visual Studio it checks it out for edit automatically; however, if you make the changes outside Visual Studio (you need to change Read-only property prior to that) and forget to check it out for edit in Visual Studio the file is not listed in Pending Changes window. Consequently, the risk of not including that item while making a check-in increases (I personally experienced that a couple of times….)
- It’s dedicated to Windows platforms only, but this is hardly a problem for a team who uses Visual Studio
- Weak support for reverting changes – read more
- It’s not a free tool
- Complex installation
- Update, 2010-08-22 Lack of switching feature. With Subversion I could easily switch between trunk and branches / tags, still using the same source directory. The action was straightforward and quick. On TFS you need to make a full check out of the other branch, which is longer and requires additional actions (e.g. IIS settings for new virtual directories)
Strong points
- Integration with Visual Studio
- Integration with work items (bugs, tasks, scenarios, test cases, etc.) – in other words your team needs only one tool (Visual Studio Team System) for all project chores. This actually promotes TFS to be a more powerful tool that a source control only.
- Shelving changes – ability to set aside pending changes temporarily in order to switch to another task – read more
- SQL Server backend (e.g. backups)
To sum up, both Subversion and TFS are powerful. There’s not an easy answer which tool is better. Despite not giving a direct judgment, it really seems to me TFS is better for bigger projects – one tool needed for all kind of project tasks (work items, source control, bug tracking, planning). What are your thoughts?
P.S. Probably the list above would look differently if I first used TFS instead of Subversion
Note: What is described below applies to Windows Vista x64 (at least I used such OS). I’m not going to describe what to do with a mini dump – how to analyze it in a debugger (e.g. in Visual Studio); such information can be found in a very good article at CodeProject. What I’m going to present here is how to set up Windows Vista so that mini dumps are created when an application crashes, and enforce they are stored locally on the machine on which that happened.
I believe every developer uses debugger while product creation. However it’s also possible to debug the application after it’s delivered to the client. One of such techniques is postmortem debugging – the act of debugging the memory dump of a process, which is stored in a special file (not human readable).
Microsoft has created a special service – Windows Error Reporting. Prior to Vista, Dr. Watson was default Windows application debugger that created crash dumps. Starting with Vista, Microsoft has replaced Dr. Watson with a new, improved mechanism. In short (supposing Windows Error Reporting is enabled), if an application crashes a mini dump (representation of the state of the process) is created. Mini dump is much smaller but still provides plenty of needed information. Depending on settings, a mini dump can be sent to Microsoft for further analysis. This is default behavior which, at least in my case, resulted in no mini dumps stored locally on the machine where the crash took place.
Continue reading ‘Windows Error Reporting – first steps in postmortem debugging – how to collect mini dump?’
I had a load test that used a coded web test. At some point the coded web test changed, i.e. this line was added: Outcome = Outcome.Fail;.
After this change the test stopped working – it always ended with error message: ‘User aborted test run’. Apart from that each iteration of the web test produced MethodAccessException: Microsoft.VisualStudio.TestTools.WebTesting.WebTest.set_Outcome(Microsoft.VisualStudio.TestTools.WebTesting.Outcome).
Solution
The reason for the problem was I was using Visual Studio TS 2008 without SP1. Once I installed the SP1, which must have updated mstest, the test started running successfully again.
The key point here is before SP1 Outcome was read-only property, which I learned there.
It’s a fact that coded web test methods give more flexibility to the developer, i.e. common code reuse. So let’s create a coded web test in whose GetRequestEnumerator() method you want to call a common method which tests some other requests. Let’s make it look as GetCommonRequests() in the example below:
public class AWebTest : WebTest
{
private IEnumerator<WebTestRequest> GetCommonRequests()
{
WebTestRequest req1 = new WebTestRequest("http://google.com");
yield return req1;
WebTestRequest req2 = new WebTestRequest("http://google.com");
yield return req2;
}
public override IEnumerator<WebTestRequest> GetRequestEnumerator()
{
WebTestRequest req = new WebTestRequest("http://google.com");
yield return req;
GetCommonRequests();
}
}
You would expect to see three requests in the test result. You will see only one though…
Continue reading ‘How to invoke a common coded web test method from GetRequestEnumerator()?’
A coded web test, as opposed to a basic web test, brings more flexibility to the developer: conditioning, looping, code re-usage, etc. If you haven’t created one yet, you can follow an instruction on MSDN.
Now, because a coded web test can have some logic inside, it makes sense to add logging so that there’s a trace on what’s going on while it executes.
Continue reading ‘How to quickly add logging to a coded web test?’
I wanted to change a load test so that it works similar to what Gabriel Szlechtman described in his blog. Additionally, I followed MSDN instruction on how to create a Load Test Plug-In.
So I created a new project with a plug-in class, added a reference to it from load test project and wanted to hook the plug-in with the test. However, when I was doing the last step I was getting the following error:
Solution
The fix is quite simple. When I added a new class for the plug-in, it was defined without the access modifier (and therefore it was internal), which made the class accessible from other classes only in the same assembly. Adding public access modifier for the plug-in class solved the problem.
