I usually don't commit unnecessary files, such as .user and .suo files, to the repository.
I'm unsure about whether .testsettings and .vsdmi files are regenerated by Visual Studio if absent.
Yes, you should commit those files as they contain Visual Studio unit testing and code coverage settings for the project.
I found a contrary opinion while researching this. To be honest I'm a bit torn as the fellow in the link makes a good bit of sense.
EDIT: Updated link to archive.org version, as the original post seems to be dead.
I tested here and I found out that while those files aren't regenerated while running tests, they aren't missed.
The only error I ran into with their absention was that when I try to open them it shows an error message box.
I think I will commit them to source control from now on.
Absolutely.
They contain test execution settings, test lists etc. As such, they are an integral part of your project, just like e.g. App.config.
Thomas
Related
I have some tests that were marked as [Ignore], but now, I want to run them again, so I remove the [Ignore] attribute, but Visual Studio still treats them as ignored.
What can I do to clear the cache to not ignore the tests anymore?
Update:
It looks like this data is stored in the vsmdi file:
<TestLink ... name="MethodName" ... enabled="false" />
So deleting the vsdmi file, or otherwise causing it to be regenerated is necessary.
But, visual studio caches it, so restarting visual studio seems to fix the problem (sometimes at least).
We have this issue where I work as well.
You can manually change the .vsmdi file or delete it. If you open the test view again (after deleting it) it will generate a new file.
Also, the same kind of issue can occured with which test settings you have selected. It will 'cache' that as well.
Have you tried Clean Solution (in the build menu)? Also I would try deleting the bin/obj folders from the test-project. If that doesn't work I'd look for other (binary) files that might be a cache of some sort or related to test-projects and just delete them. I can't imagine it to be hard to locate such files and just delete them (make sure you have a backup, just in case).
EDIT Apparently it's the .vsmdi file.
EDIT2 Apparently not :P
If I would've encountered such a problem I might even have done a filesearch looking for specific method-names that have been [ignored]. Make sure you use a tool that looks "inside" every file, windows file-search ignores a crapton of files.
Even while this topic is quite old, I'd like to add my solution to this problem, for anyone who's having the same problem...
I recenlty had this problem also, and found the solution in the .vsmdi file.
Under 'Test Settings', 'Unit Test' a had a folder referred in 'Root folder for the assemblies to be loaded:' and the checkbox 'Use the Load Context for assemblies in the test directory' was checked.
I unchecked the checkbox, and after that, my tests did run succesfully! (I knew the files referred in 'Root folder....' where old assemblies.
You can also remove the files from folder in 'Root folder...' to make sure your old assemblies are removed.
I was using Visual Studio 2012 and did not have a .vsdmi file but ran into the issue. I was able to solve this by deleting the .suo (hidden file next the .sln file) file and restarting the Visual Studio. I know it says without restarting but the provided solution didn't work for me so I am providing an alternative in case someone else runs into the same error.
I have a problem which has received plenty of attention which, despite much googling, I have been unable to resolve. I have a Test Project attached to my Visual Studio 2010 MVC 2 Application. When I attempt to run my tests, I get:
"no tests were run because no tests are loaded or the selected tests are disabled."
Following this, I followed the instructions in these posts, to no avail:
MSTest: No tests are run because no tests are loaded or the selected tests are disabled = my GUIDs are right, and the assembly IS being built - I can see the file in explorer.
MSTest Not Finding New Tests = reopening the solution & rebuilding didn't result in any change
http://richallen.blogspot.com/2008/05/ms-test-re-enabling-ignored-tests.html = the tests do not even appear in the test list browser under "loaded tests"
Furthermore, the output console reports:
"Could not load file or assembly 'file://\shared\shared\IT\Development\TPS\TPS.Tests\bin\Debug\TPS.Tests.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)"
I have confirmed the build settings on the Test Project are the same as those for the main project (Any CPU targeted).
Therefore, is it a problem accessing the resource over network share? Otherwise, does anyone have a suggestion?
If you want to continue using a network share to host assemblies in .NET 4, you can change a Visual Studio configuration option to grant those assemblies full trust. You need to edit C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config and add the following line:
<loadFromRemoteSources enabled="true"/>
To the configuration/runtime element. This is described in (slightly) more detail at http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx. I would not recommend making this change without understanding the security implications of doing so, some of which are outlined in that MSDN article.
In general, though, I agree with the previous answer. Hosting Visual Studio projects on a network share is going to create a large number of problems for very little benefit.
Having your source code on a share is plain wrong (period) and will lead to all sorts of 'gremlins'.
Do yourself a favour, use Source Code Control and have a local copy of the source code. You will waste a lot less time, and as a bonus you will be able to track who changed what.
If you go with TFS, the Visual Studio TFS Branching Guide 2010 is a valuable resource.
If you use SubVersion, then the Red Bean Book is excellent.
I was running all local but still had the problem. I found that what caused it was removing an xml tag during manual editing.
add:
CodedUITest() inside of tag brackets
on the line immediately above your class where all your test methods are.
add:
TestMethod() inside of tag brackets
on the line immediately above your test methods you want to run.
build project and run.
I tried the following steps while encountering this problem and luckily the issue got resolved...
Close the solution and open the empty VS editor and Check out the testrunconfig file
Open the solution and under CodeCOverage column, uncheck and check the dll's available( these dll's would be having a warning symbol)
Rebuild the solution and now run the test cases.
Hope this resolves the issue... :)
I struggled with this for days, and didn't find the answer (for my situation) anywhere, so though I'd jot down my experience...
So I had the same problem, doing what I thought was local testing on a test project created locally.. (I'm a novice...) but returning the same error mentioned above : /
Anyway it seems that VS2010 had by default placed my project dir within the library folder, which was classified as network, subsequently all files within were 'unavailable offline'.
By moving my project dir to c:// my project files became index-able. (much to my relief!)
I have a VS2005 solution which contains a variety of projects (C++ DLLs, C++ static libraries, C# assemblies, C++ windows executables) that are combined in various ways to produce several executables. For some reason, every time I open the solution, VS2005 wants to check out one of the projects for editing. The project is not modified in any way, it's just checked out. If I configure VS2005 to prompt before checking out, I can cancel the auto-checkout during load with no ill effect that I can see. It may or may not be relevant, but the project it keeps checking out is cppunit version 1.12.0 (the static lib version). How can I stop this annoying behavior?
Other potentially relevant (or not) details:
Source control is Team Foundation Server (not Visual SourceSafe)
no .suo or .ncb files are checked in
the .vcproj and .vspscc files are being checked out
When I close the solution or shut down Visual Studio, I'm asked whether I want to save changes to the project. Answering yes results in no changes to the file (Kdiff3 compares my local file to the server version and reports"files are binary equal")
Attempting to check in the "modified" files results in a Visual Studio message saying "No Changes to Check In. All of the changes were either unmodified files or locks. The changes have been undone by the server"
As Charles and Graeme have hinted at, Visual Studio constantly make changes to user option files and such on the backed even if you don't make changes to the project directly.
I'm not sure what information is being stored but I do know that it happens. Common remedies is to not include the *.suo files. I also don't stored anything in the bin or obj folders in sauce control as this can have a similar effect as your talking about (if you build). (Checks out the project upon a build. Thought this does take an action to happen).
Overall it is unavoidable. It is just how VS2005, 2008 work.
Does this answer your question?
Regards,
Frank
There are two reasons I've encountered that cause this behavior.
The first is old source control bindings. If you have a project that used to be managed by another source control tool, it might have leftover bindings in the project file. Open the project file, and change the following settings from something like this:
SccProjectName="$/Team/Platform/Projects/MyProject"
SccAuxPath="http://teamFoundationServer.example.com:8080"
SccLocalPath="."
SccProvider="{88888888-4444-4444-4444-BBBBBBBBBBBB}"
to this:
SccProjectName="SAK"
SccAuxPath="SAK"
SccLocalPath="SAK"
SccProvider="SAK"
Different project types are defined in different ways. The above example is from a .vcproj, C# projects are in XML, VB looks like something else, but the meanings are the same. Simply set all four values to the constant string "SAK" and Visual Studio will automatically handle source control. See Alin Constantin's blog for details.
I haven't yet discovered the root of the other reason, but the project that is giving me trouble is also CppUnit 1.12.0! I'll keep digging and post my findings.
John
Have you put a .suo or .ncb file into source control perhaps?
Have you tried closing VS2005 after it checks out cppunit and then seeing if any changes were made?
I often encountered something like this with Web App solutions where the project file wasn't actually saved until you closed studio down and reopened it.
Just to clarify, I'm assuming that you mean Visual SourceSafe2005 is causing the problem, not Visual Studio. (FYI, Visual SourceSafe is usually abbreviated VSS.)
I've experienced this issue with VSS before. I think the limitation is really fundamental to Visual SourceSafe: it's just not that good of a product and I would move to something else if it's a decision you can influence.
If you can move to something else, I recommend Subversion for a small or medium-sized project. It's free, and does not use the pessimistic locking mechanism that Visual SourceSafe uses by default. There's an excellent Visual Studio add-on called VisualSVN that will give you the same functionality in the IDE (seeing what files have changed, etc.) that you get out of the box with VSS.
If you cannot change source control systems, I believe Visual SourceSafe has a mode called "non-exclusive checkouts" or something like that that uses the optimistic locking that Subversion and other source control systems use. Try setting that option at least for the files that are obviously not being changed and see if that resolves the issue.
I get this a lot when one of the projects in the the solution has source control information with path information that is not the same in source control as on your workstation. When VS opens the project it will automatically attempt to check out the project in question and
To fix it, you're best off having everyone who uses the project remove their local copies and do "get latest version..." to grab what is in your source control database.
you can also check the .sln file and look in the GlobalScxtion(SourceCodeControl) area for each project's information and see if the relative path is not how you have the projects stored on your workstation - though manually changing this file vs. doing a "Get Latest Version..." is much more likely to cause problems for the other developers who use the solution as well.
Your cppunit project is probably automatically creating one or more additional files when the project first loads, and then adding those files to the project. Or else one of the project's properties is being changed or incremented on load.
If you go ahead and check the project in, does it check itself out again next time you load it? Or does checking it in fix the problem for awhile?
Very often this sort of behavior is caused by VS trying to update source control bindings.
Graeme is correct, VS will not save project or solution files until you close VS.
I would let VS check the files out, then close VS, then diff them.
Visual Studio seems to be modifying a list of .vsmdi files in my .sln every time sometimes when I run a unit test. This is annoying because my source control client thinks the .sln file needs to be checked in even though I don't want to check it in. Is there any way to keep Visual Studio from munging the .sln file after a test run?
Edit: Found a Microsoft Connect issue discussing this, which sucks because things just sort of disappear from there after a little while and its a terrible bug tracker
I don't believe a solution exists. A good Connect case, that does a better job of documenting the issue and a repro case, is this one. At the very bottom of the page a commenter proposes a workaround, which I've reproduced here. I haven't actually tested this workaround for myself yet, I guess I've gotten numb to discarding the changes caused by this bug :(
From the connect case:
I have been able to repro this problem
by having developer A run tests with
the vsdmi file while developer B check
it out and adds unit tests to the
vsdmi. This typically will cause a new
one to be generated.
The workaround that has worked for me
is to create vsdmi files per dev for
unit testing activities that are not
checked in to SCC and create special
vsdmis for build testing and automated
regression.
Yuck, but it works.
Edit: Oops, was confused about the "list of vsmdi files" thing. Suggestion wouldn't have worked.
That is a question for the ages...I always check if the solution has been checked out for whatever reason before I commit changes.
I just wonder what the best approach is to have multiple users work on a Project in Visual Studio 2005 Professional.
We got a Solution with multiple Class Libraries, but when everyone opens the solution, we keep getting the "X was modified, Reload/Discard?" prompt all the time. Just opening one project is an obvious alternative, but I find it harder to use as you can't just see some of the other classes in other projects that way.
Are there any Guidelines for Team Development with VS2005 Pro?
Edit: Thanks. The current environment is a bit limited in the sense there is only 1 PC with RDP Connection, but that will change in the future. Marking the first answer as Accepted, but they are all good :)
What you need is source control.
You should definitely not open the same files over the network on multiple machines. For one thing, Visual Studio has safeguards in place to prevent you from modifying certain files during a build, but it has none of that that will prevent others from modifying the same files over the network.
By setting up source control, each developer will have a separate copy of the files locally on his or her developer machine, and periodically communicate with the source control system to check in/commit changes. After that, other developers can ask for the latest updates when they're ready to retrieve them.
Use source control to keep a central repository of all your code. Then each user checks out their own copy of the source code and works locally. Then submits only the code that changed.
https://en.wikipedia.org/wiki/Version_control
A number of people have recommended using source control and I totally agree. However you also need do the following.
Exclude your personal options files from the repository (eg your .suo files)
Exclude your App.config files from the repository. - Not entirely but you need to have a Template.App.config. You commit that instead, and only copy your App.config into the Template.App.config when you make structural changes. That was each user has their own individual config for testing.
There are probably some other files worth excluding (obj directories and so forth) but thats all I can think of right now.
Peter
This might sound snide, but if you're opening up the solution from a shared location then you're doing something wrong. If that's the case then you should start using source control (something like Subversion) and have everyone check out a copy of the project to work on.
However if you're already using source control, then it might be a symptom of having the wrong things checked in. I find that you only need the sln, and the vcproj under source control.
Otherwise I don't know...
You should definitely, definitely be working with source control!
This will help stop the collisions that are occurring. Also, if you are making changes to the shared projects this often that it is a problem, then also ensure that all code is tested before getting checked in (otherwise they may bust someone else's build), but make sure they check in often (or time gained from not dealing with prompts will be lost in merging conflicts) :)