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.
Related
On the current project I am working on, there is, at the moment, a large churn of code, which means updating from source control can mean at times many csproj file changes. As we all know, VS2010 doesn't have a "Reload all" button, but you must reload each project and confirm each reload.
Is there a method where either the project is auto-reloaded or the IDE can detect this and ask for a solution reload?
Finally found a solution:
http://lostechies.com/jimmybogard/2011/01/27/reloading-all-projects-with-vscommands/
Quoting from the site:
Quite often I’ll find myself working
in situations where multiple projects
have changed, and Visual Studio asks
to reload them, one at a time. This
happens when I’m working a lot with
source control, and doing things like
switching branches, performing merges,
or just integrating upstream changes.
I have to click “Reload” a million
times for each project that changed on
disk, and it’s quite annoying. On top
of that, VS forgets which files I have
open, so every file that I was working
on gets closed.
I may be the last VS user to find out
about this, but a free lite version of
the VSCommands plugin is available on
the Visual Studio Gallery that does
just what I need – reload all changed
projects at once, preserving which
files I had open:
It's a pain, but the best option I've found is to Close the solution before Getting the latest source code.
If there are more than two changed projects, it is faster to manually unload&reload the entire solution than it is to Get and wait for it to unload&reload the affected projects only - reloading projects is achingly slow (even disregarding having to click the OK button for every project that changed).
(In my mind the real question is: Why does it ask that question at all??? If you Get the latest source code, there is absolutely no sane reason why you would want to only use part of it. It's like a petrol station attendant saying "You've bought some fuel. Would you like me to now actually put it in your car, or shall I just pour it out on the ground?")
Well, that doesn't work if your references paths changed in the csproj file and your using something like the sysinternals junction tool to change a symlink. E.g. tool switches D:\Projects symlink from D:\Baselines\1.0\Prjects to D:\Baselines\2.0\Projects , and because someone changed the folder structure between 1.0 and 2.0, your .csproj file suddenly points the dll path from ....\References\some.dll to ....\References\3rd-Party\some.dll . I know that is a special case, but happens (e.g. in my company).
There is an alternative solution though, one which I highly recommend as it has other benefits, too: the not-so-well-known VS 2010 Extension Solution Load Manager. It defers loading of Projects to the background, or until manually loaded, improving solution load time a lot for large solution files. It has this "reload solution" button in it's menu (unfortunatlely there seems to be no shortcut) which then reloads all solutions from scratch, skipping/backgroundloading the solutions you set. A Microsoft guy commented on his blog that they wanted to include something similar into VS 2010, but the feature didn't quite make it.
Sure, it may take longer then "just" one click and updating 100 documents, but it solved my problem of (relative) reference path changes, and gives a nice speed boost every time I open an at least medium sized solution.
Edit as of Oct 2013
VS2012 includes this functionality by default. At least the async loading stuff. The "don't load at all" functionality is unfortunately only possible by using manual "unload project" in VS2012. But as pr-project memory consumption did go down with VS2012, it's not that big of a deal anymore.
If you have checked the option "detect when file is changed outside the environment" in the "Documents" section of options, projects and files are reloaded when changed. It works for me when switching branches in git.
Every time I open a particular solution, the VSS bindings are lost and I have to rebind. Can anyone tell me why this happens and/or how to prevent it (short of never closing the solution, or having to do a "Get Latest Version")? This doesn't happen for every project/solution, only this one.
As always, thanks for the help.
P.S. I know the product sucks, but I have to use it.
It's gonna be hard to find the root cause of the problem but it's probably related to corruption of binding informations stored in your folder.
One possible solution would be to delete the content of your project folder (you can try first by only removing VSS related files) and then re-open it from source control (in VS) to let VS recreate binding informations.
This will surely work if only you in your team are experimenting this problem... othewise... don't know.
If the problem still occure after that, I don't see other solution than re-installing your VS :-(
Hope that help !
which version of VSS are you using?
In older versions of Visual SourceSafe (before 6.0c), after adding a solution of Visual Studio to its source control, the binding information was stored directly in the .sln and .proj files.
Since VSS 6.0c, all binding information is kept locally in files named MSSCCPRJ.SCC on the developer's machine.
after deciding where the binding info is stored, you can pinpoint the cause easier. before and after closing VS, open the .sln/ file with notebook and check whether it includes code similar to
GlobalSection(SourceCodeControl) = preSolution
...
EndGlobalSection
It may be because something might be intefering with the local copy of VSS solution on your machine.
The local directory set for your solution contains two additional files besides your project files:
one is MSSCCPRJ.SCC and the other is TheSolutionName.VSSSCC.
In windows, their icons are in the form two arrows pointing in opposite directions.
I had accidentally deleted them (thinking they were junk) and then lost all bindings to the VSS solution. Please check if something similar is happening on your machine.
Another reason could be - using multiple versions of VSS on same machine.
The problem with renaming files is that if you want to take advantage of Visual Studio refactoring, you really need to do it from inside Visual Studio.
But most (not all*) version control system also want to be the ones doing the renaming.
One solution is to use integrated source control, but this is not always available, and in some cases is pretty clunky.
I'd personally be more comfortable using source control separately, outside of Visual Studio, but I'm not sure how to manage this question of file renames.
So, for those of you that use Visual Studio, which source control do you use? Do you use a VS integration (which one?) and otherwise, how do you resolve this renaming problem?
(* git is smart enough to work it out for itself)
I use SVN (TortiseSVN as the client) and use the Repair Move command from the commit dialog heavily. This allows me to rename the files within VS and resolve the rename when I'm ready to commit to keep version history.
As far as using the VS integration, like you, I find all VS integration clunky and do not use it.
mercurial usually prefers to do the renaming via hg rename however it can also detect renames from an outside source by using hg addremove -s 100 (or less than 100 if you want to match a rename with alterations) so clearly you can let VS do the rename and get mercurial to catchup with addremove.
We use SVN (TortoiseSVN to be exact), and i am always bothered with the renaming problem. The simplest solution i've found is to remove the files from the project, rename them via TSVN and add them back to the project. You have to manually update includes for renamed header files, but this is relatively easy using find&replace.
We use Team Foundation Server, and it works with no problems. I've also found that moving to using a fully integrated client has improved my workflow, as I don't need to flip between applications just to do trivial tasks.
We develop "Plastic SCM" and the Visual Studio Package supports move operations. But I see your point, I'm getting more and more comfortable with the idea of not having plugins/packages and then have the version control working behind the scenes and simply detecting what happened without having to be "plugged in" into the IDE. In fact we're working on it for next release...
Besides the above advice, for Visual Studio 2008 I found that after making all global changes to any file being renamed from within VS, including right clicking the file and renaming it, as well as a global search and replace for all strings, replacing the old file name with the new file name, you must, if the file is the initial startup file, right click and select it as "set as default page". Otherwise you'll may well get the "The resource cannot be found." error on runtime.
This is driving me crazy and has resulted in lost work (not much, at least).
Normally, when I edit a file in Visual Studio, it's supposed to automatically check that file out in source safe. On multi-project solutions (e.g., web app with class libraries), sometimes none of the files in one project would automatically get checked out, though exiting & reloading visual studio may fix that problem temporarily. Furthermore, project files are never automatically checked out. Whenever I add/remove code files, I have to remember to explicitly check out the project file as well (otherwise we'll have issues with code files not showing up in the solution explorer, or trying to load non-existing files).
We're using VS-2008 and VSS 2005. Do you have any idea how I might fix this? There are no more visual-studio updates/fixes on Microsoft Update.
You need to ensure the files are read-only, or VS won't be able to tell that they are version controlled (or, at least that's what it uses to determine it). You can tell VSS to set itself up so getting the latest version places the files RW on disk.
There may be other problems here, but that's what comes to mind first. My advice (that I took myself) is to migrate to SVN or an alternative. Losing work is unacceptable.
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) :)