In some Visual Studio 2015 projects that I have, there is a *.VC.db file in the project folder, named after the project: If the project name is FooBar, then the file is FooBar.VC.db.
This file looks like a database of some sort, but I'm not using any databases at all in the projects.
My best guess would be that it is operating similarly than the HelloWorld.sdf database, which is used by IntelliSense.
Is it the same just in "new", or is it doing something important and I shouldn't delete it?
This happens after you installed VS2015 Update 2. The projname.vc.db file is the new IntelliSense database, it replaces the old projname.sdf database. Not otherwise by deleting that .sdf file. You may also see a hidden projname.vc.vc.opendb file, a lock file to indicate that the dbase is in use. Crystal ball says that somebody is bound to have to delete this one by hand sooner or later.
This was already available before but was experimental. Now permanent. Promises are for a rough x2 speedup of IntelliSense. Biggest change appears to be switching to another dbase engine, now using SQLite instead of SQL Compact. Powerful open source confidence vote there :)
Don't delete the file just yet or next time you open the project IS is going to be catatonic for a while. Well, not as long as before :) You'd consider cleanup, if at all, when you're done with the project. Go ahead and delete the .sdf file, it will no longer be used.
Related
I often need to return to a previous milestone.
There is a vicious cycle: my error is revealed only during debugging, but I can't step back because the debugger has saved my project.
In simple projects I always used to make a copy of my cpp file (just keep ctrl and drug your file a bit).
But now projects has become more complicated (with header files).
I have tried to use save solution as. But it seems as if it is just renaming the sln file without making a copy of the whole project.
So, what shall I do? Copy the whole project as I did with the file?
The question seems a bit clumsy but it really troubles me: what elegant decision is there?
You can use software versioning systems like SVN or Git to undo the savings and return to previous point in your project, also there are some extensions for visual studio like ankhsvn and Gitextention that you can use.
If you are using vs 2010, you can disable saving on build event from Tools>Options>Projects and Solutions>Build and Run
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.
Anyone had any success getting SVN to merge Visual Studio project (.csproj) or solution (.sln) files that have been edited by two users? Example
User A checks out project
User B checks out same project
User A adds a file
User A commits changes
User B adds a file
User B commits changes
Seems to me that at step (6), svn, Tortoise, Ankh or whatever should detect a conflict and either merge the two project files automatically or, more likely, prompt User B to resolve the conflict. Currently, we're seeing changes made by User A obliterated when User B checks in, resulting in bad builds, deploys, etc missing features that had been added before the last checkin.
Since the project files are XML, why is this an issue? Am I missing something here? I've searched the archives here and googled to I can't google no more, but haven't come up with a good solution.
How do you think you trick SVN into performing step #6? It seems you misunderstood what goes wrong. SVN will never ever commit from a working copy that's not up to date, so step #6 won't work without user B previously updating and merging user A's changes. Honestly. Try it.
I guess what happens instead is this:
A checks out project.
B checks out same project.
A adds a file.
A commits changes.
B adds a file, but forgets to save the project/solution.
B tries to commit changes and gets a message he should update first.
B updates.
B switches back to VS. VS tells him the project/solution changed on disk and asks whether he wants to a) reload from disk and lose his changes b) override the version on disk.
B doesn't understand, doesn't try to understand, considers his changes valuable, and picks b), overriding the changes on disk.
B still doesn't try to understand and thus does not diff the version he has on disk with the last committed one and thus misses that he overrode A's changes.
B Checks in, overriding A's changes.
I've seen this happening once in a while, usually with a user B who does not really understand SVN's (or CVS', FTM) workflow.
So here's a few hints:
Don't update unless you have saved everything ("File"->"Save All"; for me, that's Ctrl+Shift+S). In case you have made that mistake and you're stuck, do override the changes on disk and then merge the lost changes manually. (It might also work to update the project/solution file back to version N-1, and then to HEAD again, in order to have SVN perform the merge.)
Don't commit without checking which files you changed and having a quick look at the diffs to see whether the changes are what you expect.
Commit early, commit often. The more developers work on the same code base, the more likely you get conflicts. The longer you change your working copy without updating, the more likely you get conflicts. Since the number of developers usually is out of your hands, the update frequency is the one thing you can use to reduce the probability of conflicts.
I second sbi's answer. One possible solution is to always update from within Visual Studio, at least if you use VisualSVN (I'm not sure how AnkhSVN copes with this situation).
VisualSVN will block visual studio during the update operation, and make sure any changed projects are automatically reloaded, so users can not ignore the external changes.
A rather radical but efficient solution is to use a tool to generate those solution files from a meta-definition and then putting only the meta-definition under source control, not Visual Studio project files (which are a nightmare to merge).
In my team we use MPC to do this. We have:
a bunch of .mpc files for project descriptions,
a .mwc file for workspace / solution description,
a small .cmd to generate Visual Studio files.
Since they are all hand-edited text files, we no longer have problems with Visual Studio mixing up everything.
The drawbacks are an extra-tool and the need to regenerate the solution files when files are added or removed but there are some additional benefits too:
project configurations are centralized: for instance, changing a compilation flag is done in a single place instead of on a per-project basis,
this can accomodate multiple build systems (we currently use Visual 2003 and 2005 but this also works with gcc and others).
From my experience, althgough setting up the tool can be a bit painful (but it all depends on the size and complexity of your project), this is clearly worth it.
Note that MPC isn't the only tool for this purpose. Others exist, such as CMake.
You can also try to reduce conflicts by ensuring that your project files don't list every individual file inside the project. This will avoid the project file from being changed in first place when a user adds a file.
You're free to use wildcards inside a project file: see MSDN
Example:
<ItemGroup>
<Compile Include="Src\**\*.cs" />
[...]
</ItemGroup>
It is sad that Visual Studio doesn't encourage this kind of project setup and instead opts for listing individual files.
This is very tedious and tiresome so you just have to plow through it. You will sometimes keep the local working copy since it has all of your custom projects added. However, in other cases you will want to merge in all new items from the Base solution so you end up with everything from both solution files. For readability it is best to place all base product additions before customization additions.
Do not worry that the first portion of the GUID is identical for projects, but it is the last portion that will be unique.
Fissh
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 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.