Why does Visual Studio create a new .vsmdi file?

Question

If I open a solution in Visual Studio 2008 and run a unit test then VS creates a new .vsmdi file in the Solution Items folder and gives it the next number available e.g. My Solution2.vsmdi.

Any idea why VS is doing this and how I can get it to stop doing this?

Solution 1

It appears that the VSMDI problem is a known bug and has been around since VS2005 Team System but it has no clear fix as yet. Another reason to NOT use MS Test.

An MSDN blog details how to run unit tests without VSMDI files.

Solution 2

Assuming that the VSMDI file is under source control, here's a Microsoft Support article about this issue: Multiple vsmdi Files after Running Team Test with VSMDI file under Source Control

Which says:

Someone ran a test while someone else was modifying the vsmdi file. Team Test detects that the VSMDI file is out of sync;therefore, Team Test it makes one and thus you see the incrementing vsmdi files.

And:

Going forward you want to make sure the file is not marked for auto checkout when it is modified. When the current tester has the VSMDI file checked out you, do not want other users to be able to check it out. You want your developers to checkout the file, run a test, and check it back in.

Solution 3

I work around this by always checking out the .vsmdi.
It seems that this only happens when the .vsmdi file is read-only, e.g. not checked-out in a version control system that uses that kind of lock-local-files behavior (Perforce etc).

Comments

[akavel]

the first link was unaccessible at the time I clicked it, but you can read it archived thanks to The Wayback Machine: web.archive.org/web/20080302162715/http://…

[gerryLowry]

@ Jon Limjap: you wrote "Another reason to NOT use MSTest". I'm curious: what are your other reasons to NOT use MSTest? Also, what unit testing framework(s) do you prefer? BTW: strange, I get a .vsmdi error but the tests seem to run regardless which is way too weird for my preference. regards ~~ gerry (lowry) [email protected]

[Jon Limjap]

gerry, You do have to take note that this is a very old answer. At that time, MSTEst was a relative novelty in the test driven development scene. It was to be avoided because it was difficult to use: a proxy class had to be generated between the actual object to facilitate test capability. This is very much unlike NUnit and NUnit based tools (MbUnit, xUnit, etc) which were quite mature as open source unit testing frameworks at that time. My preference then and up until now is MbUnit.

[gerryLowry]

Jon, thank you for explaining. Have you looked at xUnit.net? Jim Newkirk (NUnit 2 author) and Brad Wilson created xUnit.net [xunit.codeplex.com/]. Daniel Cazzulino (Moq author) uses xUnit.net for testing Moq. Why is MbUnit your preference?

[Jon Limjap]

gerry, My preference isn't really a preference but more of a comfort zone thing -- we've been using it for a long running project, with Rhino mocks as our mocking framework. One of these days I might give xUnit and Moq a try, and maybe it could change my mind. Let's see. :)

[Mitch Denny]

Hi guys, you don't actually need a proxy object to interact with classes under test in MSTest. You might make that assumption if you have only used it briefly. I pretty much never use those helper classes and generated stubs and write tests in MSTest just like anyone would with NUnit. It is simply a matter of preference.