Is there a way to integrate Visual Studio with VSS without doing source control binding?
The problem I have is that my team is opposing to add source control binding to the solution and project files, since they claim it adds more problems (restrictions) for them.
On the other hand, I really like to perform most of the source control operations from Visual Studio.
Is there any way to have the solution file and all the project files the way they are (without added binding to VSS) and still have VSS and VS integration without forcing other team members to use that integration.
I don't see a way to do it per project.
You can however you do it for IDE (all projects loaded).
It is under Tools\Options\Source Control
and then set Binding to None.
I see it in VS 2005 and 2008. I gave it a try in a project I wanted to convert from VS2005 to 2008 and appeared to work (I did not want to check in/out files for conversion).
The answer to your question is "no." Bindings and VS integration are one & the same with SourceSafe. I'm not even sure what it would mean for a solution to be integrated but not bound, or vice versa. What exactly are your teammates looking for?
You can adjust bindings per-project in the File -> Source Control -> Change Source Control dialog. You can also adjust them per-user (effectively; not a supported configuration) by excluding the *scc files from source control. However, you are likely to encounter problems down the road if you try to manage these files yourself instead of using the Add Solution To SCC wizard. More info:
http://alinconstantin.dtdns.net/WebDocs/Scc/_Bindings.htm
http://alinconstantin.dtdns.net/WebDocs/Scc/_WebEnlist.htm
The binding is stored in the .vssscc, .vspscc and MSSCCPRJ.SCC files.
If you don't add these files to Visual Source Safe every developer can configure his bindings like he wants.
Since we use Perforce, I'm not 100% sure if this works with VSS.
Related
I got the latest version of a Visual Studio solution on TFS. But when I try to open the solution in Visual Studio I get the following message:
Source Control
The solution you have opened is under source control but not currently configured for integrated source control in Visual Studio. Would you like to bind this solution to source control now?
Asking my colleague, I found out that he's been checking in the changes through Visual Studio without any problem.
Here's my question: Considering the fact that I can still check in my changes via IDE, what is the use of binding a Visual Studio solution or project to TFS (or more generally source control)? Except that "lock"/"red tick" icon appearing beside them in Solution Explorer.
Adding Solutions and Projects to Source Control: When you add a solution to source control, the solution becomes part of a dynamic versioning archive created and maintained by the source control provider. Each time someone checks in a new version of the solution, that version becomes part of the archive and is available to other source control users.
According to the warning message, It seems that you are opening from source control a solution that was incorrectly added to source control (it's missing some bindings strings that should have been in the sln or project files). You should click the button yes and Bind the projects correctly to their server location, then OK the dialog. The server file will be checked out and modified locally. You should checkin the changes after that.
I have a dev team that is split in mentality of using visual studio source control bindings. Half would like the integration and half would not. Is there a way to add a solution only binding setup so each team could use a different solution based on their preferences?
There is no painless solution to this problem. The reason being that Microsoft made the monumentally bad decision to embed source control information into .NET solution and project files.
Let's say Dick wants to use the SCC plugin and Jane doesn't. Dick adds a project to version control via the plugin and information like this will be written to the solution file:
GlobalSection(SourceCodeControl) = preSolution
SccNumberOfProjects = 2
SccLocalPath0 = .
SccProjectUniqueName1 = someApp\\someApp.csproj
SccLocalPath1 = someApp
EndGlobalSection
and some garbage like this will be added to the project(s) files:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
In addition, some files will be strewn about the project folder tree (MSSCCPRJ.SCC files in the solution and project folders, a *.vssscc in the solution folder, and *.vspscc files in the project folders).
The extra files are not a problem as long as Dick doesn't check them into source control (although the plugin is always going to want to check in those .vssscc and .vspscc files). However, the source control information that gets written to the solution and project files will always be an annoyance for Jane. Whenever she opens the solution, she will be nagged by this message:
and then this one:
Should she choose the option to "Permanently remove source control association bindings", the source control information will be removed from the solution and project files and she will be happy again. However, Dick's SCC plugin won't work anymore and he'll probably rebind the projects to source control and an office riot will ensue.
To sum it up, you can share .NET project between those who use the SCC plugin and those who don't, but one or more parties are going to have to endure some annoyances because Microsoft decided to add source control information to .NET project files (such a bad decision, this wasn't a problem in Visual Studio 6).
I'm not absolutely sure if I got you right. I assume that half of your team wants to use the Visual Studio plugin to access Perforce and the other half doesn't.
This is possible. You have to make sure to never check in the MSSCCPRJ.SCC file created by the plugin. This is the local bindings information and will not work on everybody's workstation.
On the other hand side, the *.vssscc files can and should go into Perforce.
Using the plugin has one big advantage, though: The plugin knows which files to check in and which to omit. Especially when adding new projects, it's a common mistake to forget to check in the newly created files when using the Perforce visual client instead of the plugin.
You have to make sure to never check in the MSSCCPRJ.SCC file created
by the plugin.
I removed *.scc files but Visual Studio prevent me use others Source Controls Plugin's except saved into solution and project files.
I've searched MSDN and this site (as well as a pile of web searches) and not found anything obvious ... I do see a similar question here about using an existing source control folder -- and the note that TFS apparently stores some project settings there (and thus needs one whether you use it or not).
We're using a non-TFS source control tool -- and I don't want newcomers "accidentally" storing source versions in TFS. So, I'd like to disable the creation of a TFS 2010 source control "tree" when I create a new Team Project in VS 2010.
There may be other solutions to this problem, though, and I'm open to suggestion. For example, if TFS really does need to store some internal data -- how about a way to simply prevent any source code checkins (that is, let TFS use the source control project as needed, but prevent users from adding files)?
TFS has extensive permissions settings.
You should be able restrict check in / access to source tree by permission.
I'm involved in many projects and each project has their own source control provider. Is there a way to configure Visual Studio 2010 to automatically select the right source control on a per project basis? Or is the Tools - Options - Source Control plug in per user level?
Let me clarify what is happening. I have a project using Vault. When I open it VS sets the Source Control to Vault. I then close the project (solution) and open another solution that uses Mercurial (VisualHG) I check the Source Control plugin and Vault is still selected. Why? Is it possible to automatically select the right source control?
In order to automatically load a proper source control provider the solution file must contain Scc bindings.
I don't know if VisualHG supports them or not.
But you can try HgSccPackage - another mercurial plugin for MS Visual Studio 2008/2010 which supports Scc bindings.
You can get it here: http://www.newsupaplex.pp.ru/hgscc_news_eng.html
If you want to add Scc bindings to an existing controlled solution, use Mercurial -> Change SCC bindings menu from the IDE. (This menu will be available when the HgSccPackage is active and you have loaded a controlled solution).
For new projects HgSccPackage automatically adds Scc bindings. It is configurable via options though, for thouse who don't like this behavior.
You might want to take a look at this question. It appears the answer is no, you have to select the correct provider for the project before working with the project, because only one source control provider can be active at a time.
There's an additional VS plugin called Scc Auto Switcher that can help automatically switch between SCM systems used by different projects, although the docs don't specifically mention Vault.
Visual Studio 2008, to be more specific. We're testing out moving to Perforce for source control, so I'd like to install the P4SCC plugin to monkey around with. However, I'd also like to continue using SourceSafe's IDE capabilities for projects that haven't been moved over yet. Can the two co-exist peacefully, or is it one or the other for a specific install of VS?
Yes, Visual Studio supports multiple providers. The entire VS architecture is plugin based, and SCC providers are just another kind of plugin (usually implemented as a "package," in VS terminology).
You can only have one SCC provider active at a time. So you cannot have different projects bound to different providers within the same solution.
The active SCC provider can be switched by:
Going to Tools -> Options -> Source Control (present as of VS 2005) -or-
Using a tool like SccSwitcher to modify the registry directly (needed on VS 2003 and earlier)
Opening a solution that already has SCC bindings written into it
You cannot change the provider from within the Bind dialog (File -> Source Control -> Change SCC). All you can do there is bind/unbind, or in the case of a few odd providers like SourceSafe, edit the server path.
To change the provider of an existing solution you would use the Bind dialog to remove the existing bindings, change the active provider from Tools -> Options (or SCCSwitcher if needed), then launch the Add Solution To Source Control wizard from Solution Explorer.
Visual Studio can handle multiple source control plugins/systems, but you'll need to be sure that your projects are bound to the correct provider (File->Source Control->Change Source Control).
I use:
SCC Switcher
to help me with this. It's handy as it gives you a traybar icon for switching.
I would also recommend TraySource its the same as SCC Switcher
I reguarly have to switch between Perforce and Source Safe and found this to be ideal for it