I am working with a project (shared by a small team via SourceSafe source control) with four .config files in it:
App.config is the configuration file that is eventually used when the program is executed.
The other three files are essentially templates that I can quickly copy & paste into App.config.
App.Integration.config and App.Release.config are valid for all team members. For instance, it refers to integration or production database servers on the network.
App.Debug.config is a template with settings that are valid only for my machine, e.g. because it refers to my local copy of a development database.
Background: Why am I managing multiple configuration files manually? ASP.NET web projects automatically support multiple configuration files, but other project types don't. I also know that this could be automated by adding a custom MSBuild task to the project file; however, this might break or confuse later build steps, such as ClickOnce deployment.
Obviously, I do not want to check in "my" local version of App.Debug.config into SourceSafe, which is why I told Source Safe to ignore that file. For the same reason, I have SourceSafe ignore App.config, because that file is often going to be edited, e.g. when switching from the local configuration file to the integration environment's version. If everyone checked in their versions of these files, they would be seen by all other developers.
However, if I understand correctly, this leads to SourceSafe no longer keeping a copy of these files at all, so if someone checks out a fresh copy of the project, these two files will be missing.
Is there a way to have an "initial" copy of e.g. App.config in my SourceSafe repository, but at the same time prevent Visual Studio from checking out the file when it is locally edited by a developer?
Background: Why am I using SourceSafe at all? It's not my decision, and I can do nothing about it in the short term.
You can use the pin feature to keep a copy but not allow checkout.
In solution explorer, locate your file (e.g. App.config), right click on it to call menu "Show History...", select a version of your file and then click button "Pin".
Related
I have two copies of Visual Studio 2017 open and each window is working with a separate solution. Both solutions are checked into Team Foundation Server source control in separate folders. For example, \Projects\Project1 and \Projects\Project2. There are no files common between these two projects.
When I add a new file into \Projects\Project1 using Windows Explorer, it appears as an entry in both copies of Visual Studio under "excluded changes". If I add the file through Visual Studio, it appears to get added as a file that's referenced by that solution (or project) and appears in the included changes for that project.
How do I configure Visual Studio to not add arbitrary files that exist outside of the solution folder into the detected files list?
In Visual Studio, under Excluded Changes, there is a View Options link with a Show Solution Changes option as well as a filter. However, neither of these options stops the inclusion of files that belong to other projects. It is as if the root of the detected code has been set to the parent folder of both solutions.
Since you are using a local workspace, first please go through below mechanism of detecting files:
While edits in a local workspace can be pended implicitly just by
editing the file, adds and deletes still must be explicitly pended.
However, TFS version control’s workspace scanner also detects new
files which are ‘candidates’ for addition, and missing files and
folders which are candidates for deletion. The Team Explorer’s Pending
Changes Page has a link which shows the number of detected adds and
deletes, and provides a link to the Promote Candidate Changes dialog
which can be used to pend ‘real’ adds or deletes on these items.
This is called “promoting” the candidate adds and/or deletes – because
they become real pending changes.
Source Link: Server workspaces vs. local workspaces
In your case, since you are adding files using Windows Explorer, TFS will add the files in excluded changes, you need to manually promote the files as real add in pending changes list. However, TFS could not judge the exclude list should belong to which Visual Studio. That's why it appears as an entry in both copies of Visual Studio under "excluded changes".
How do I configure Visual Studio to not add arbitrary files that exist
outside of the solution folder into the detected files list?
There is no way to do this for local workspace, unless you are using server workspace, but there are also many limitations.
Another workaround is configuring multiple projects which have multiple TFS workspaces. You could have several branches for different projects under the main or dev branch, and create a different workspace for each branch. Each branch is a 'project' in itself.
It is as if the root of the detected code has been set to the parent
folder of both solutions.
Correct. It sounds as though you have a single TFVC workspace mapped to a single root folder. If you have a single workspace mapped to a root folder, all changes in that folder will be reflected in the team explorer.
The solution: Use multiple workspaces, one for each project. If you're not familiar with the concept of workspaces in TFVC, there is extensive documentation available on the subject.
I have an issue. We are upgrading to VS 2012 at work. When we open a VS 2010 project Visual Studio converts the project. This is fine, because VS 2010 can still use the project (yay microsoft). However, there is a \Backup folder created in the solution directory. Is this being created as part of the migration? Is there any way to control it?
The reason I ask is that the process that makes this folder copies web.config files into the folder. If you then try to build the solution (these are MVC projects), we get a "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS." error. The cause is that there is a web.config file in a subfolder instead of the root folder. We did not make and do not want this change, and cannot figure out how to control it. Deleting the Backup\Web.config file fixes the error. Renaming it from web.config to web.config.bak fixes the problem.
I don't really want to have to personally open and convert every single project, and don't want random people bumping into this problem. Any idea how to either stop VS from creating the Backup folder, or how to make it create them in the my documents studio folder etc? I can't find any setting to control this and can't find any good info.
By chance, are you using the MvcBuildViews property to pre-compile your views at build time? If so, this is why you're encountering this (since it does the pre-compile in the same directory, it doesn't filter out any of the files below the project directory).
Note that you will also encounter this issue if you use the Publish feature for this project. Publish copies the web.config under your intermediate build output directory (by default, obj/) before and after applying web.config transforms.
The good news is that in VS2012, or in VS2010 with the latest Azure SDK installed, pre-compile is now supported for Web Application Projects (including MVC). These settings are currently in the project properties, under the Package/Publish Web tab.
(this doesn't directly address your question about the Backup folder, but it was too long for a comment.)
There is no way to control it that I found. We had to go ahead and run through and convert every project to 2012 and delete the backup folders to prevent any other team from running into it.
I have a website project that is consuming user controls from another shared project. I am using a build event to copy the *.ascx files over from the source user control project.
I don't want the ascx files to be checked into TFS source control from the consuming project, only the source project. Is there a way to keep TFS from trying to check in files from a specific folder other then cloaking?
My issue with cloaking is that it's a client side function, which means every developer who takes down the project would have to manually cloak the folder or folders in question themselves. I'd like to be able to setup the solution in such a way as a developer could take the project down from source control without having to manually configure it to accommodate my separate project for shared user controls.
There is an article here: http://devio.wordpress.com/2009/11/05/shared-aspx-and-ascx-files-in-visual-studio-and-tfs/ that seems to address this issue but I think they're setup is different then mine in that I am using a website project and not a web application project. Being that I have no .csproj file there's no way to include or exclude files from my project.
Check out the TFS Power Tools (if you haven't already) http://visualstudiogallery.msdn.microsoft.com/en-us/c255a1e4-04ba-4f68-8f4e-cd473d6b971f, under Team Members > General Settings, you can setup a Worspace Template to cloak as needed.
Not played with it myself, but looks to be the functionality that you need.
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.
(I know I am using Visual Source Safe, I do not have a choice because it comes with the MSDN Subscription license and my company does not want to buy a third party source control solution....)
I have a VS 2005 solution with 3 C# class library projects, 2 ASP.NET web site projects and one ASP.NET web service project that is stored in a Visual Source Safe database. Some of the projects reference a common library DLLs that handle common taskes.
When a new person sets ups the solution on their workstation and build it for the first time, it checks out the common library DLLs in the bin folder of the ASP.NET web site and web service projects. When another developer that is currently working on the project tries to build, they receive a "file excludely checked out by other user" message.
VS 2005 does not display the check mark next to the DLL that is causing the headache.
Is there a way to prevent this from happenning?
Why do you have the bin folder checked into SourceSafe? On projects I've worked on, the third party dlls were checked into a separate folder (maybe called ExternalLibraries or ThirdParty) at the same level as the solution file. The compile process would be set up to copy the dlls into the bin folder. This could be handled with .refresh files, or with a pre- or post-build step. This way, VisualStudio/SourceSafe won't see the files as having been updated, and won't try to check them out.
If the compile is already pulling the files in due to them being dependencies, I'd suggest removing the bin folder from VSS. This is not the same as an "Exclude folder from project" which hides the folder from VS05 when compiling (and gives you the compile error you mentioned.)
If the third party dlls aren't going to change, another option is to make those files read-only in VSS. This way, no users will be able to check out the files. (To mark the files read-only, you will need to change the permissions from the VSS management tool; the developer's tool doesn't have that feature.)
As for why it happens, I don't believe VSS checks the binary version numbers - it is only concerned with modify file date. If a new developer pulls all the code out, all files (including binaries) will have the current date as the modify date. This may be causing the unnecessary checkouts.
Regarding your later comments - I'm not sure why VS05 wouldn't see the files as under source control but the VSS UI does. I suspect it has to do with the .vss files (and similar) that are in that folder. In this case, VS05 is incorrect.
Not sure if this is the problem or the best fix, but if you update every developer's machine so that they have the same latest versions of the common DLLs installed, this shouldn't keep happening. I think VSS checks out the DLLs in the \bin folder if the version referenced by the project file doesn't match the version installed on the developer's machine.
#Pedro:
In the VS 2005 IDE inteface, it does not indicated that the \bin folder is in VSS. When I look at the project in the VSS UI, it shows that is checked out to the user who did the latest build on their workstation.
If I use the "Exclude folder from project" option, it will cause the compiler to throw "reference not found" errors.
In my solution structure, the class library project creates a reference to the third party DLLs using the "Add Reference" command. Then I set a project reference to the class librarys in my ASP,NET web site and web service projects (using the web site project template). Because the class library has a dependency on the third party DLLs, they are copyed in the \bin folder.
How do I set a file to read-only through the VSS UI?