I have a branch in TFS, after making my changes I checked in and merged with my main branch. I can now see the folders and files on the server in source control. However, all of my new files and changes to certain files are not available in my solution. Any folders added are shown in the solution but not the file inside these folders. I could probably check in the main branch but wanted to build of course because nobody wants a checked-in solution that breaks the build.
Error Message:
Error
TF10187:Could not open document
(Path)
The system cannot find the file specified
Anybody have a suggestion, thanks!
Related
I'm trying to add existing solution to source control in TFS 2012.
While trying to checkin(add) whole solution I get bunch of errors saying that it Could not find file like .config .gif .datasource .xsd.
Solution is quite big - over 100 projects, removing or undoing changes for all those files from source control will be messy. Moreover I'm not sure if removing them from source control wont break whole solution.
Is there any way to avoid that kind of problem?
The error you have is mainly caused when you're trying to check in files which is no longer exist on the machine.
To remove these changes from the list, you can either delete the nonexistent files from solution explorer, or go to Source Control Explorer -> select these missing files -> Undo Pending Changes. Or you can just left these files in the Excluded Changes list to not checking them.
I need share to share certain files between different projects. Thus I have a file structure like so:
D:\shared\
D:\shared\files-shared-by-all-projects-here
D:\project1\
D:\project1\project1-specific-files-here
D:\project1\shared <- directory junction to D:\shared
D:\project2\
D:\project2\project2-specific-files-here
D:\project2\shared <- directory junction to D:\shared
I have setup GIT repos in D:\project1 and D:\project2 My problem is that GIT seems to only track files in non-junctioned (i.e. real directories).
I use Visual Studio 2015 for both projects, and it's Team Explorer would behave very strangely when project has files from "junctioned" directories:
Upon adding a file residing in a directory junction to a project, Team Explorer would only show its parent directory (junction) in the list of changes to commit, not the file itself.
Upon committing all changes (i.e. files have been added), Solution Explorer shows all files as being tracked and checked-in (including those that reside in junctions and were not shown in the list of pending changes after they have been added:
Editing a file which is shown as checked-in and resides in a junction directory will make it appear to be checked-out:
Returning to Team Explorer now, the checked-out file is shown in the list of modified files:
However trying to commit it fails with a message: "An error occurred. Detailed message: No changes; nothing to commit."
Returning to Solution Explorer the changed file for which commit failed is nonetheless shown as checked-in:
Explicitly adding files that reside in the shared directory (i.e. referencing it via D:\project2\shared\some-shared-file) from outside of Visual Studio using Tortoise GIT for example does not work: add fails with a message that it is both a file and a directory.
The above was done with a new test project where frame directory residing in project's root is really a junction.
In my actual projects however the situation is slightly different... If I browse the repo using Tortoise GIT for example it would actually show the shared files residing in junctions as being tracked and checked-in and part of the repo. However as soon as I open the project in Visual Studio, it would show though same files in Solution Explorer and Team Explorer Changes as "pending delete". So is this a VS quirck?
So the bottom line is I just want to know how can I make files residing in directory junctions to be viewed as part of the project on par with regular files, so that they are properly checked out and checked back in and form part of project's (repo's) history?
At present, this is not supported. This is due to a difference in interpretation between junction handling between Git for Windows and libgit2, which is the Git library that is used by Visual Studio and (parts of) TortoiseGit.
It has been decided that both implementations should treat junction points as if they are Unix mount points, however neither implementation actually does that at present.
At present, Git for Windows treats them as if they were normal directories (and so it may delete your junction and replace it with a new directory). libgit2 treats this like a symbolic link, and as a result, Visual Studio refuses to deal with it at all.
Since Microsoft will need to update Visual Studio to fix this, please file a bug at Microsoft Connect and encourage people to vote for it in the hopes that it will get fixed in VS 2015.
I'm working on a project where I'm writing a library. I have a file, lets call it... tester.cs which I use for testing the library. Now, I'm only supposed to check in the library but i accidentally also checked in tester.cs. Is there any way I can delete it from the remote server without deleting it locally? and also ultimately removing it from source control? Thank you in advance.
If you want to delete files on the TFS server and leave them locally. There's the obvious brute-force solution of copying the files to a temporary location, fixing source control, then adding them back in to your project.
And also here is a similar question for your reference: How to delete a file from TFS repository without deleting local file
It depends really on what you mean by 'delete'. TFVC has the concept of delete which flags a file as deleted in the Project Collection database (and removes it from your workspace etc.). And you have the concept op 'destroy' which means the file will be removed from the Project Collection databases, and action that is unrecoverable except by restoring a backup of TFS. But this will leave your local file in place and erase all traces of the file in source control.
However, if you added it to your project in VS (.proj file) then there will be a reference to the file in there as well for compilation etc. This will cause issues when other users perform a Get-Latest of your solution.
Also if you are using a local workspace you can use .tfignore files to prevent such files from being added into the local workspace in the first place. See this page, near the bottom there is some information about the .tfignore file and how they work.
I think it's as simple as making a local copy of a file, deleting it in TFS and moving the local copy back to the original location. Visual Studio does not allow you to do that in a C# project or Source Control Explorer.
I'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.
If I add a new file to a project under TFS source control, it will check out the project file and the corresponding .vspscc file for that project file.
The project file itself changes (to include the new file), but the .vspscc file doesn't change at all. Why bother checking it out? Is there a way to disable it from being checked out and if there is, should I?
It gets checked out because under certain conditions it will be modified..and thus they checked it out as a matter of default. I wouldn't worry about it..it's not hurting anything, and if you disable it, it might bite you badly in the future in a bizarre way.
According to this post of Ben Ryan:
Team Foundation uses these to store lists of files that have been excluded from source control. We leveraged some of the existing SCC integration layer in Visual Studio to integrate Team Foundation, and these files were one of the carryovers. I'll have to check into what the logic was in breaking out these SCC settings into separate files as opposed to putting them in the solution and project files' SCC sections.
This file is a holdover from past VSS/TFS implementations, like Paulo Santos posted.
On the solution level, I have found no functional use for these files. In 10 years of using TFS, I have never seen that file altered. You can delete these .VSSCC files, as I commonly do for my closed source solutions.
But if you delete the solution-level .vsscc file, you will get a non-destructive error message on the first time open of the solution file...only after a new branch is created. All subsequent solution opening will not show the error message again.
My TFS setup standards have the solution file alone in the root folder, all projects are under sub-folders. Since those .vsscc files double the number of files in my root, I always delete them.
On a project level, I leave those files, as my team never opens project files directly, only solution .SLN files.
For my team, I prefer programmer ease of opening solutions over that one-time error message.