Multiple vsmdi files

Question

Hi,

We are getting multiple vsmdi files.Everytime someone runs a unit test the solution is automatically checked out and a new vsmdi file is created using the naming pattern MySolutionName1.vsmdi, MySolutionName2.vsmdi, etc.

I've compared the files and they are the same. They live in the solution root and always have.

The workaround that we have is to undo checkout on the files in question and then it works fine unti one next restarts the IDE.

Any ideas? anyone else getting odd behaviour with vsmdi files?

I've C&P'd the XML contents below:

  <?xml version="1.0" encoding="utf-8" ?>

- <Tests>

  <edtdocversion branch="retail" build="50727" revision="42" />

- <TestCategory type="Microsoft.VisualStudio.TestTools.Common.TestCategory">

- <id type="Microsoft.VisualStudio.TestTools.Common.TestCategoryId">

  <id type="System.Guid">8c43106b-9dc1-4907-a29f-aa66a61bf5b6</id>

  </id>

  <name type="System.String">Lists of Tests</name>

  <description type="System.String" />

  <enabled type="System.Boolean">True</enabled>

- <parentCategoryId type="Microsoft.VisualStudio.TestTools.Common.TestCategoryId">

  <id type="System.Guid">00000000-0000-0000-0000-000000000000</id>

  </parentCategoryId>

- <runConfiguration type="Microsoft.VisualStudio.TestTools.Common.Link">

  <id type="System.Guid">3ed5d32d-a99a-4c9b-a5db-e2498da28775</id>

  <name type="System.String">Local Test Run</name>

  <storage type="System.String">localtestrun.testrunconfig</storage>

  <type type="System.Type, mscorlib">Microsoft.VisualStudio.TestTools.Common.TestRunConfiguration</type>

  <enabled type="System.Boolean">True</enabled>

  </runConfiguration>

  </TestCategory>

  </Tests>

Answer 1

Hello,

Are you modifying the tests, or maybe modifying the test lists hierarchy in the test manager (Test | Windows | Test Manager) ? The .vsmdi file will be checked out whenever you actually modify test lists. If you modify tests themselves, then your .cs file will be checked out. Just running the tests shouldn't be doing that.

Can you please elaborate more on your scenario? If you can enumerate the exact steps you follow and that cause the vsmdi file to get checked out and afterwards a new vsmdi file to be created, that would be really good in trying to understand what is happening.

Thanks.
David Gorena Elizondo
[MSFT] VSTS

Answer 2

Hi David,

Thanks for your time. We have a solution represented as something like:

MySolution.sln
    - ProjectA
    - ProjectB
    - FolderC
        - ProjectD
        - ProjectE
    - Solution Items
        - MySolution.vsmdi
        - localtestrun.testrunconfig
        - MyProjectD.testrunconfig
        - MyStrongNameKey.snk
        - Settings.settings

The steps from ground zero are:

1. Open Solution
2. Use "Test View" window (don't group by or anything - plain and simple)
3. Select any test, go right click / context menu -> Run.
4. Voila! checked out solution and added new file "MySolution1.vsmdi"

It has been happening since we started writing Unit Tests. I'm happy to send you screenies or the solution.

Paul.

Answer 3

Hello Paul,

I've talked to some people on my team about your problem, and this is something that we have seen, but have not been able to repro consistently. It seems to be a problem with the state of the machine and not the solution itself. Having access to your machine to try to debug would be really good, but I don't know that it is possible. What you can try (what we have done in the past to solve the problem) is to check everything in, delete it from your local machine, and then get all the sources back to your machine.

If you can try this, please let me know if it helps

Thanks,
David Gorena Elizondo
[MSFT] VSTS

Answer 4

Hello David,

Thanks very much for your help. Unfortunately, I can report that deleting all local content and getting again from TFS SCC did not work.

Also, FYI, I note that all other members of my team have the same issue. Some have VS 2005 Developer Ed., some have VS 2005 Team Suite.

Any other ideas would be most appreciated.

Regards,

Paul.

Answer 5

Paul,

Is it possible that you send me your solution? I want to try to repro it in my machine
[e-mail]

Thanks,
David Gorena Elizondo
[MSFT] VSTS

Answer 6

Hi Paul

I've been looking at your solution, and when I add it to my source control, everything works just fine. But after spending some time trying to figure out what is happening, I came up with an idea of what might be happening. First of all, I noticed that all files in your solution are read-only. This might be because you copied the solution that is under source control and that is how you sent it to me.

So, if I open your solution locally in my box, without adding it to my source control, and I try running one of your tests, just as you mention, another vsmdi file will get created. This is expected since Visual Studio uses the vsmdi file when running tests, and if it notices that it is read-only, then it will try to generate a new one.

So, by explaining this scenario, I will move on to the next one. You can add your solution to source control. Everything looks fine, but then you might not have the status of your working folder (source control folder and local folder) active. This would cause the exact same scenario as the one I described (For instance, if everytime you open Visual Studio a message pops up asking if you want to work uncontrolled, or if you want to remove binding information, then this is definitely the problem!). To verify if this is the case, go to your source control folder, double click it, and then in the tabbed window that opens, hit the combobox that reads "Workspace: <Computer name>", and choose "Workspaces...". Click Edit on the dialog that opens, and make sure that the status of your project is active and correctly pointing to your local folder.

If this is not the case, I'm still almost positive that the problem is a binding problem. Source Control may have lost some binding and is not correctly syncing your vsmdi file. Try checking out the vsmdi file, and verify locally that it is no longer read-only (in its properties). Check it in again and verify that it is marked as read-only again.

Please let me know if any of these helps

Thanks,
David Gorena Elizondo
[MSFT] VSTS

Answer 7

I can report:

1. You are correct. I did a fresh get out of TFS SCC and zipped 'em all up for you, hence they are all read only.
   
2. Workspaces all fine. They are Active and nobody on my team has issues (or had). We use them extensively (home working, shelving, etc.)
   
3. I closed the solution, did a force get of all the files. Confirm that the vsmdi file is read only. Checked out the vsmdi (confirm that it is now writable). Tried to check it in and get a message "No changes to checkin /n/n All of the changes were either unmodified files or locks. The changes have been undone by the server". I confirm that it is now read only again.
   
4. I closed the solution, did a force get of all the files. Confirm that the vsmdi file is read only. Checked out the vsmdi (confirm that it is now writable). If I now run a test, I still get the the new vsmdi file with the incremented name added to the solution (ie. the same behaviour).
   
5. I closed the solution, did a force get of all the files. I now go into the file system and manually make the vsmdi file writable. If I now run a test, I still get same behaviour.

So I have some questions:

1. Why is the file read only by default from TFS SCC, yet you comment "...This is expected since Visual Studio uses the vsmdi file when running tests, and if it notices that it is read-only, then it will try to generate a new one...". This seems incongruous?
   
2. What happens when you manually make the file writable and run a test with my solution? Same behaviour as me?

Most interesting. I look forward to hearing from you and thank you again for your time and patience in this regard.

Paul.

 

Answer 8

So for your questions,

1. I won't go into implementation details, but when your solution is under source control in TFS, Visual Studio detects this and doesn't create a new .vsmdi file (this is obviously not what you're seeing). If your solution is not binded to source control, and the vsmdi file is read-only, then Visual Studio will create a new one

2. Using your solution, if I have it binded to source control, I won't have another vsmdi created (for both scenarios, having vsmdi file read-only or writeable). I just get the second vsmdi file when I unbind it from source control, make the vsmdi file read-only, and run the test.

Obviously there is something going on with your vsmdi file and the way source control is binding it. We have heard about your scenario before but unfortunately have never been able to actually see it to try to debug it. Anyway, for now what I want to try to achieve is a workaround to your problem, so lets try the following scenario:

1. Delete your vsmdi file both from your local solution and from TFS (make sure that file is completely gone)
2. Checkin your solution without your vsmdi file
3. Run one of your tests (a new vsmdi file will be created, check this one in)
4. Verify if this solves the problem

Thanks,
David Gorena Elizondo
[MSFT] VSTS

Answer 9

Thanks for your answers to 1&2.

Regarding the fix; Doh!... omfg. We should have tried this for sure... that is to say: Your fix seems to have worked a treat. Seems obvious now .

I wonder if someone of the team renamed the file or did something to it originally which caused SCC to manage it incorrectly.

Anyway, much obliged to you sir. This saves everyone a lot time having to undo checkout all the time (especially given our large solution). The whole team has a smile on their faces this morning thanks to you.

Paul.

Answer 10

I'm really glad to hear that everything is working fine now! :)
Anything else you need, let me know and I'll be more than happy to help.

Thanks,
David Gorena Elizondo
[MSFT] VSTS

Answer 11

Hi David,

 

We are experiencing the same problem using the ClearCase source control plug-in. I tried your suggested resolution and it didn't help. Unfortunately replacing ClearCase with TFS is not an option at this stage :(

 

I still don't understand why running tests should require the vsmdi file to be checked out? Nothing in the file is ever actually modified, and if a new vsmdi file is created (because the original is read-only) the new one is byte-for-byte identical to the original.

 

Surely VS should only require write access, and therefore a check-out, of the vsmdi file if it has actually been modified? IMHO the issue (and bug?) is that VS2005 unnecessarily requires write-access to the vsmdi file, even when the content of the file is not changed in any way.

 

Cheers,

 

Alan

Answer 12

 Hi Alan,

Running tests do not require the vsmdi file to be checked out. The issue that customers are seeing is that when trying to run tests, the solution gets checked out, and a new vsmdi file is generated; this is obviously not the correct behavior, and it is caused by binding issues between Visual Studio and source control. There is a workaround that I described before in this thread for the problem, but unfortunately, I have never tried the scenario with ClearCase. What I can recommend is deleting all the affected vsmdi files, both locally and remotely, and creating new ones that you check-in. If this does not work, I recommend looking for any support on the ClearCase side.

Thanks,
David Gorena Elizondo
[MSFT] VSTS

Answer 13

We are seeing this behavior as well.  Is MS tracking this issue as a bug?

Answer 14

Hello,

Yes we are tracking this bug and will fix it in our next version. For now, if you can give me any details on your scenario, I would greatly appreciate it. Things such as the SKUs you're using, how many people are using the vsmdi file, number of machines, etc.

Thanks,
David Gorena Elizondo
[MSFT] VSTS

Answer 15

We have a solution that has approximately 20 projects in it, including 4 test assembly projects.   There are about 10 developers that use the vsmdi file...each on their own machine.  Installed product info below...hope this helps

 

Microsoft Visual Studio 2005
Version 8.0.50727.762  (SP.050727-7600)
Microsoft .NET Framework
Version 2.0.50727

Installed Edition: Enterprise

Microsoft Visual Basic 2005   77642-113-3000004-41345
Microsoft Visual Basic 2005

Microsoft Visual C# 2005   77642-113-3000004-41345
Microsoft Visual C# 2005

Microsoft Visual C++ 2005   77642-113-3000004-41345
Microsoft Visual C++ 2005

Microsoft Visual J# 2005   77642-113-3000004-41345
Microsoft Visual J# 2005

Microsoft Visual Studio Tools for Office   77642-113-3000004-41345
Microsoft Visual Studio Tools for the Microsoft Office System

Microsoft Visual Web Developer 2005   77642-113-3000004-41345
Microsoft Visual Web Developer 2005

Microsoft Web Application Projects 2005   77642-113-3000004-41345
Microsoft Web Application Projects 2005
Version 8.0.50727.762

Visual Studio 2005 Team Edition for Developers   77642-113-3000004-41345
Microsoft Visual Studio 2005 Team Edition for Software Developers

Microsoft Visual Studio 2005 Team Edition for Software Developers - ENU Service Pack 1 (KB926601)  
This service pack is for Microsoft Visual Studio 2005 Team Edition for Software Developers - ENU.
If you later install a more recent service pack, this service pack will be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/926601

StarTeam® for Visual Studio® 2005   Version: 1.0 Build: 191
StarTeam® 2005 Release 2 Visual Studio® 2005 Integration, for Microsoft® Visual Studio® 2005 provides ALM support for Visual Studio. http://www.borland.com Copyright © 1998-2006 Borland Software Corporation. All rights reserved. This product may be covered by U.S. Patents pending.

Answer 16

Hi,

we are using Developer Edition here (~200 clients) and are also seeing multiple .vsmdi files (massive)!! We applied SP1 to our clients and deleted the .vsmdi files from localy and source control. And now they don't reappear! Can someone please confirm that there is a fix in SP1? Or are these just effects of somethin else?

 

Kind regards,

Markus

Answer 17

Hello Markus,

We have been tracking the problem and have had many fixes put together for SP1. The problem was a complex one, not easy to repro, and that happened when multiple users targeted the same vsmdi files at the same time. SP1 might have fixed it, and we would like to know from customers like you if you see this problem again.

Thanks,
David Gorena Elizondo
[MSFT] VSTS

Answer 18

Hi David,

sorry to say, but the vsmdi files reappeared again. Or better said the problem never disappeared. We have here about 30 Team Projects and all of them have a lot of vsmdi2, vsmdi3, vsmdi4 etc.

In my opinion this should be easy to reproduce? Will there be a fix available?

 

Kind regards,

 

Markus

Answer 19

Hi Markus,

 

We are definitely redesigning many of our features for our next version; unfortunately, we have not been able to reproduce the problem locally; we have had customers come to try to repro the problem with no luck as well. We know that the issue involves different machines, projects, and people working at the same time on the projects... but other than that, we have not been able to find steps that repro the problem.

 

I suggest that for now, you use the workaround shown at the very beginning of this thread.

 

Thanks,
David Gorena Elizondo
[MSFT] VSTS

Answer 20

Just as an fyi, SP1 did not solve this problem for us (as originally reported in previous post: 01-17-2007, 12:04 AM UTC

Answer 21

Hi,

 

I have just read this all this post & we have some additional information that might help.  We are having the same problem.

The reason a second & third ...  vsmdi is being created is as follows.

  1. Developer A opens solution & works on it possibly editing files.

2. TFS usualy creates a shared checkout but for some reason the vsmdi has an exclusive lock.  And appears in Source Control Explorer as "Lock, edit".

3. Developer B opens solution & does some work.  TFS tries to check out vsmdi but cannot because of the lock.  It then checks out the solution and creates a new vsmdi.

I have tried the post outlined in this document & it does not work.

 

Hope this helps with solving the problem.

 

Thanks, Mel

Answer 22

I am sorry for digging up this old thread but we are seeing the same problems here. We run a Team Foundation Server 2008 box and all our clients have Visual Studio Team System 2008 Development Edition. We have multiple .vsmdi files using the pattern <SolutionName>n.vsmdi. So I guess that this issue is still not fixed in the 2008 editions.

 

Answer 23

Sorry again for bumping this thread but this is becoming a serious issue. Like mentioned the posts above where talking about Visual Studio 2005 and we are still having the same issues in Visual Studio 2008. And I am talking about 8 different solutions having the same problem. I find it odd that this is hard to reproduce. Even hovering my mouse over the "Test" menu will create a new .vsmdi file. We would love to have a fix for this.

Answer 24

We are seeing the same thing with VS 2008 and TFS 2008.  It is very confusing and difficult for me as a lead developer to ask the devs to update the vsmdi with new unit tests when there are a half dozen of these files out there.  I had to open the solution file with notepad to clean this up and get it fixed.    The problem is very simple to recreate.

 

1.  Dev 1 - Runs unit test, checks out vsmdi

2.  Dev 2 - Runs unit tests, vsmdi is already checked out by another user, and so VS2008 checks out the solution and then adds a new vsmdi. 

 

I don't know all of the details of what is going on in the background, but it would be nice if the test runner would ignore this file unless it's open and I have checked the tests and selected "run checked unit tests".  It could use reflection to see what projects have unit tests and run those.

 

Thanks,

Mike

 

Answer 25

We're having the same problem but we're not using TFS.  We've seen the problem in VS 2005 Team Dev and VS 2008 Team Dev.  Since we're not using TFS, I'm pretty sure the locking issue mentioned above that causing the problem for us.

 

We have a large .sln with 216 projects.  The generation of each vsmdi locks up Visual Studio and pegs a CPU for 14 minutes so it's extremely painful when it decides to regenerate itself.  We never edit the vsmdi's and frankly wish they didn't exist.  If we remove the vsdmi and testrunconfig, the vsmdi's don't get generated anymore but VS disables the commands to run the tests.  If we just remove the testrunconfig, the tests are enabled but it generates a vsmdi.

 

Question 1: Is there any way to prevent Visual Studio from generating the vsmdi and still be able to run our unit tests?

Question 2: Is there a hot fix coming that optimizes the generation of the vsmdi?  Opening the Test View must do something similar because it takes about the same amount of time. (Luckily we don't need to use it in VS 2008 thanks to the Ctrl+R, T shortcuts.)

 

Thanks in advance!

Answer 26

Hello,
  It's still a problem in VS2008. Visual Studio Team System 2008 Development Edition (Version 9.0.21022.8 RTM) to be exact.

Any one have a work aorund?

----- Ed

Answer 27

AFAIK there is no workaround except for making sure that the devs don't check-in in the "new" .vsmdi file... This one is a very annoying issue.

 

Answer 28

We are also having this problem w/ VS2008. I'm not sure if it could be connected, but all of our solutions use SourceSafe source control. The multiple vsdmi files are created at seemingly random times (sometimes for test runs, sometimes not, sometimes at other seemingly random times, etc). However, it happens consistently throughout a development session and is quite annoying.

I see this as a pretty major problem, especially because there is apparently no work around.

Version information:

-------------------------------------------------------------------------------------------------------------------------------------

Microsoft Visual Studio 2008
Version 9.0.21022.8 RTM
Microsoft .NET Framework
Version 3.5

Installed Edition: Enterprise

Microsoft Visual Basic 2008   91904-270-2149874-60117
Microsoft Visual Basic 2008

Microsoft Visual C# 2008   91904-270-2149874-60117
Microsoft Visual C# 2008

Microsoft Visual C++ 2008   91904-270-2149874-60117
Microsoft Visual C++ 2008

Microsoft Visual Studio 2008 Team Explorer   91904-270-2149874-60117
Microsoft Visual Studio 2008 Team Explorer
Version 9.0.21022.8

Microsoft Visual Studio 2008 Tools for Office   91904-270-2149874-60117
Microsoft Visual Studio 2008 Tools for Office

Microsoft Visual Studio Team System 2008 Development Edition   91904-270-2149874-60117
Microsoft Visual Studio Team System 2008 Development Edition

Portions of International CorrectSpell™ spelling correction system © 1993 by Lernout & Hauspie Speech Products N.V.  All rights reserved.

The American Heritage® Dictionary of the English Language, Third Edition Copyright © 1992 Houghton Mifflin Company.  Electronic version licensed from Lernout & Hauspie Speech Products N.V.  All rights reserved.


Microsoft Visual Web Developer 2008   91904-270-2149874-60117
Microsoft Visual Web Developer 2008

Crystal Reports    AAJ60-G0MSA4K-68000CF
Crystal Reports Basic for Visual Studio 2008


Hotfix for Microsoft Visual Studio Team System 2008 Development Edition - ENU (KB944899)   KB944899
This hotfix is for Microsoft Visual Studio Team System 2008 Development Edition - ENU.
If you later install a more recent service pack, this hotfix will be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/944899.

Hotfix for Microsoft Visual Studio Team System 2008 Development Edition - ENU (KB945282)   KB945282
This hotfix is for Microsoft Visual Studio Team System 2008 Development Edition - ENU.
If you later install a more recent service pack, this hotfix will be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/945282.

Hotfix for Microsoft Visual Studio Team System 2008 Development Edition - ENU (KB946040)   KB946040
This hotfix is for Microsoft Visual Studio Team System 2008 Development Edition - ENU.
If you later install a more recent service pack, this hotfix will be uninstalled automatically.
For more information, visit http://support.microsoft.com/kb/946040.

Microsoft Web Deployment Projects 2008   00000
Microsoft Web Deployment Projects 2008
Version 9.0.21022

Typemock Isolator
For more information about Isolator, see the Typemock website at
http://www.Typemock.com
For customer support, use the forums on the site
Copyright (c) 2005 Typemock ltd.

-------------------------------------------------------------------------------------------------------------------------------------

Thanks,
Joe Crivello

Answer 29

Anyone got any updates on this?

We're experiencing exactly the same problems with vsmdi files repeatedly being checked out on our latest development project, using Visual Studio 2008 and VSS.

Answer 30

Not that anyone needed this comment, but, ...

 

I can confirm that this is a general problem in both vs2005 and vs2008 using both TFS and ClearCase. It is very annoying, but not too "serious". I can't image why this did not get fixed as it shows up all the time and *must* be simple to fix - at least it seems that way.

 

Now I will admit that I have not even checked the connect site! I think I'll go there right now.

 

- Bill

 

 

Answer 31

I'm still getting this problem in Visual Studio 2008 as well (Version 9.0.21022.8 RTM).

 

I tried the workaround mentioned earlier in this thread, and it did not work.  i.e. I deleted all of the .vsmdi files, checked in my solution, ran a unit test so it created a new .vsmdi file, and checked that in as well.  Next time I ran a unit test, VS asked me to check out my solution and then proceeded to create yet another .vsmdi file.

 

What did work for me was to just keep the .vsmdi checked out.  It definitely seems like VS needs write access to the file when performing a unit test.  If it cannot get write access, it will then proceed to create a new .vsmdi file (and ask to check out your solution to track the name of the new file).

 

I am surprised Microsoft could not reproduce this problem.  Seem like lots of users have been getting it.  Hopefully this can get fixed in SP1.

 

-Larry

 

Answer 32

I have not a workaround for the primary problem, but I have a solution for not loosing the settings from the former vsmdi file.

Problem

If such a new version of vsmdi file is automatically generated, then your settings get lost (e.g. the test lists will not be there in the new vsmdi file).

 

Solution

1. if you experience that a new vsmdi file is generated, open that file in the test list editor
2. press the "import" icon in the toolbar of the editor
3. select the former (now obsoleted) vsmdi file that contains the settings you want to restore --> the settings are now visible again in the editor
4. save all

This allows to at least restore the settings.

 

Andi

Answer 33

25 June 2008,

I can also verify this is a problem in VS2008 using both TFS and VSS.

 

A co-worker seems to have isloated the problem to it occuring ONLY when either the "Test List Editor" tab is open while starting VS2008 or the "Test View" is open on startup.  I checked this a little further and have observed that VS2008 will actually auto-generate a Test list based on all test methods defined in the solution. While that seems pretty cool, it has (2) problems:

 

  1) Wipes out any User Created Test Lists - like BVT's (as reported)

  2) Forces a Checkout of the solution and creates a new VSMDI (since the original is READONLY/CheckedIN)

 

I have not had much luck with the Work-Around. Even with a writeable VSMDI, the solution is still forced to be checked out and it also wipes out my user created Test Lists.

 

I noticed that the TechEd2008 Presenter of TLA309 was sure to NOT have "Test List Editor" OPENED while conducting the Unit Test Demo (hmmm - seems like MS does know about this problem after all).

 

Does anyone know if their is a HotFix or how to find out?

 

Skip Galt

Answer 34

We've had this problem for ages. I really don't know how MS can let this one go without fixing. The whole process seems flakey enough as is.  All I could recommend is for anyone who experiences this to login to the Connect site and rate the bug  with a big 5 stars. Hopefully this will trigger something and get it fixed...  (Sorry I dont have the link but if you search for 'vsmdi' in Connect it should be obvious).

Answer 35

Here is the list of the related Connect Issues I was able to find:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=197689
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=197688
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=350495
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=350583
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=353784

 

Some of them MS has already marked as Closed.

Answer 36

Nice one Skip. I've added a comment to your Connect issue to add a little more weight to the issue.

Answer 37

SkipGalt wrote:

Here is the list of the related Connect Issues I was able to find: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=197689 https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=197688 https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=350495 https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=350583 https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=353784   Some of them MS has already marked as Closed.

 

That is the bit that gets me.  How can they be marking this bug as closed, when it's quite clearly still there, and is being reported repeatedly.

 

Seems Microsoft are just ignoring the problem and hoping it will go away.

Answer 38

Sorry to bring up that nasty thing again, but this is really annoying. Microsoft charges quite some money for these tools and do not even care about issues that arise when using client and server / Visual Studio (Professional and higher) and Team Foundation Server.

 

Regards,

Rudi

Answer 39

Its somewhat embarrassing to have suggested to my team that VS had a better solution for unit testing then Nunit, only to find out that an issue that has been active for a few years has not been resolved, but instead has been denied as an issue.  I can assure you that the recreation of the VSMDI file has NOTHING to do with source control!! 

So I guess the solution is to go with NUnit?  Please tell me that I am wrong!!

---

Coder dude