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.
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.
When I ran a load test on my environment (Visual Studio TS 2008) for the first time I got the following error:
Error occurred running test. XXX could not access the result repository: Invalid object name ‘LoadTestRun’
Solution
The reason for that was I hadn’t had created a database schema for load tests. In order to do it I executed <VS location>\Common7\IDE\loadtestresultsrepository.sql which did all the job.
Please refer to msdn for more information.
Writing comments is something you need to get used to; sooner or later you will understand it’s worth writing comments. Haven’t you find yourself in a sitation where you don’t understand what a couple of lines of YOUR OWN code do? I have…
XML documentation comments are also important, particularly for public members/methods. Even if your project doesn’t require generating full XML documentation of the code, using Intellisense can be much more effective if it summarizes the method you are trying to use. If you want to generate XML documentation for C# in the twinkling of an eye you MUST install Roland Weigelt’s GhostDoc plugin for Visual Studio. Let me cite the author:
Continue reading ‘Robust generation of XML documentation comments for C#’
C2C is a history now. I attended .NET stream and one session on SQL. The conference as a whole was very interesting, well organised, and basically developing. It was a Polish conference so most sessions were conducted in Polish but there were a couple of speakers from abroad too, and they spoke in English.
Basically I’m happy I had a chance to attend the conference. Below are my notes and comments. Please note they are my comments; should I write something which is not true or accurate, please let me know, sometimes pace was fast so I might have skipped something
Continue reading ‘Summary of Communities to Communities (C2C) 2009 Conference’
