Not sure which is the best forum for this question.
I'm trying to find a way to prevent certain files (.vsmdi and .testrunconfig to be exact) from being stored in source control. I want the solution (.sln) and projects, etc. to be in source control, but I don't want the vsmdi and testrunconfig files checked in and out everytime someone makes a change on their local machine. Here's the user scenario that's causing me problems:
- user A gets latest version of a test project in the Solution.
- user A goes to test manager and runs a test.
- the vsmdi file is automatically checked out because the run ID (GUID) changes.
- user B gets latest version of the same test project.
- user B goes to run a test and gets an error because the vsmdi is checked out exclusively to user A.
A simliar situation occurs if one user makes a change to the testrunconfig to add a deployment item. Is there anyway through the source control explorer to remove these two files from source control without removing them from the solution Basically, I just want the solution to always use the local copy instead of trying to check in and out a copy from source control.
Rob
removing autogenerated solution files from source control
JessicaM
Yeah, I've noticed this rather annoying behavior with the vsmdi file as well. At the same time, of course I want my vsmdi file source controlled because it's a shared resource that needs to be safely versioned.
I wasn't aware that it was changing the run ID... or what that's even used for to be honest. I wonder why they need to do that in the vsmdi itself. Solutions and projects have secondary files for client specifiic settings (e.g. suo and .user).
Anyway, just wanted to "me too" this post and now I guess I'll have to wait for a response. Although I wonder if this wouldn't have been better off posted into the TFVC forum.
Later,
Drew
chisanga
yeah, I would prefer to have it source controlled as well, but this is becoming a real headache. So I was thinking about explictly checking a copy into source control somewhere else and removing the default VSMDI in the solution directory from source control so it could modify it locally whenever it needed to, but the changes wouldn't be reflected in my source controlled copy.
Rob
Gillissie
Hi guys,
We are aware of this problem, there is a bug opened for it, but unfortunately we have not been able to get a machine into that state in order to be able to debug into the issue. This problem happens when the machine and/or vsmdi file are in a certain state, that we are investigating. For now, the workaround that I suggest is:
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
For more info, take a look at this thread:
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=499083&SiteID=1
Thanks,
David Gorena Elizondo
[MSFT] VSTS