Multiple vsmdi files
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"?>
<edtdocversionbranch="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>
<descriptiontype="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>
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
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:
- Open Solution
- Use "Test View" window (don't group by or anything - plain and simple)
- Select any test, go right click / context menu -> Run.
- 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.
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
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.
Paul,
Is it possible that you send me your solution? I want to try to repro it in my machine
dgorenae@yahoo.com
Thanks,
David Gorena Elizondo
[MSFT] VSTS
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
I can report:
- 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.
- Workspaces all fine. They are Active and nobody on my team has issues (or had). We use them extensively (home working, shelving, etc.)
- 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.
- 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).
- 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:
- 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?
- 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.
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
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.
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
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
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
We are seeing this behavior as well. Is MS tracking this issue as a bug?
skt at 2007-9-4 >
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
