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.
Related
So I am working on a solution with a lot of projects with multiple developers using SVN. There are some projects that are specific for me that I want loaded but for others they might not be relevant.
So my question is, where does Visual Studio store information about a project begin loaded and what is the proper way to commit project/solution settings with out ruining it for others?
An example could be that I just added a new project to the solution and I want to commit these changes, but I don't want to commit whether or not a project is loaded/reloaded (Since other developers have to reload them again).
EDIT: I found the answer here When I unload projects in visual studio, where does VS save this setting?
When you add projects to a solution, they will get loaded when the solution opens.
If using source control, if such a solution is updated and contains new projects, they will get loaded.
One way of dealing with this is to create multiple solutions - solutions that only have relevant projects. These solutions can be part of source control, but don't have to, though if you don't add them to source control you risk having projects in source control that only you have a solution reference to.
We need to create a new project in Visual Source safe. This project is actually a newer version of an existing project. Following is what we want.
All files of existing project are copied to new project.
Files in both projects are not shared. (Changing a file in one project should not affect the same file in other project)
All Visual Studio solutions and projects are bound to new project in source safe.
Whats is the best and easiest way of doing this?
You should use the share and branch option...
MSDN help (works with folders as well as files)
This will break the link between the two copies meaning that you can change files in one project without affecting the other one.
Here's my specific scenario: Using VS2010, Pex and TFS2008, generated moles files are getting automatically added to source-control (TFS).
Pex adds a "project_name.moles" file to your test project and then autogenerates 3 files at build time: project_name.Designer.cs, project_name.Moles.dll, and project_name.Moles.xml. I want to keep the *.moles files in TFS (it's source code) but I don't want the 3 generated files to be in TFS (they are still part of the project, but they are generated when first built on a new system).
There are two reasons I need this behavior:
1. It's not a good idea to store generated code in source-control (let's not debate the merits of that here).
2. Specially, the DLL file is BAD because every time someone builds, all moles files are regenerated and thus all files are checked-out and DLL files are checked-out EXCLUSIVELY (non-mergable) and so other people can no longer build on their local box.
The Pex/Moles team are working on this but the solution is still likely several months away.
Is there a csproj property that can be assigned to these project files so that they are in the project but not managed by version control? I don't mind hand-editing the csproj file.
Moles will not be adding any files to the project in the next version (v0.94). It will use MSBuild to generate the assemblies on demand.
I think it depends more on the version control tool than Visual Studio, as usually you can set up some kind of filters in your version control configuration in order to exclude some files/paths.
E.g. if you use Mercurial/Hg, you can (and should) edit your repository .hgignore file and specify e.g. to exclude all *.moles files and the whole sub-tree MolesAssemblies\*. I guess other version control systems have similar options.
We are finally getting a source control system in place at work and I've been in charge of setting it up. I've read that it's usually good practice to not include binaries in source control so I haven't. However, we have two all-purpose utility projects (each in their own solution) that generate utility .dll's which are included in almost all of our other projects (all each in their own separate solutions). We add references to the utility dll from our projects.
I would like to have our solutions set up in such a way that if the reference dll isn't built, the solution will build the dll for itself, much in the same way a make file checks for its dependencies and builds them when they're out of date or missing.
I'm new to build processes with VS so try to keep the answers simple. Any links to general build process overview tutorials would be great too. Googleing for VS references returns a bunch of how-to add references links which is not exactly what I want.
Answer: (3 step process) Add a project reference, not a binary reference by right clicking on the solution, and adding an existing project. Then under the project tab, select project dependencies and modify the project so that one project depends on another. Finally, delete any old reference to the binary and re-add the reference using the project tab in the Add references dialog box.
Where I work we typically have project references rather than binary references (as we used to a while ago). When you include a project reference, the dll will build along with the rest of your app.
The only time we go back to binary references is when we are in between Visual Studio releases (e.g. 1 project is in 2010 and everything else is in 2008. The 2010 project will have to use a binary reference for a couple of months until everyone else catches up... Project incompatibility seems to be a Visual Studio limitation that shouldn't exist).
EDIT
To add a project reference right click the solution and click Add and finally "Existing Project." Make sure that the utility projects are also under source control, and make sure that the workspaces are set up correctly or other people will not be able to open up the projects correctly!
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.