Having a problem with TFS and TFS CI in the following scenario (I have simplified it though it is essentially the same problem):
I have a trunk (set of csprojs in one VS solution)
I have a branch (taken from the trunk)
-- in this branch I have created a new file, say "MyRepository.cs"
I merged my branch back into the trunk
-- all seems well... (in pending changes the file is marked as "merge, branch")
I checkin my merged pending changes to trunk
This kicks off a gated checkin in TFS
This fails and I get a message from TFS CI:
"CSC: Source file 'Repositories\MyRepository.cs' could not be found"
"TF270015: 'MSBuild.exe' returned an unexpected exit code. Expected '0'; actual '1'."
When I checked in the MyRepository.cs file I obviously checked in the csproj file for the assembly that MyRepository.cs is contained in. This csproj has the line to include the new cs file, i.e.:
<Compile Include="Repositories\MyRepository.cs" />
So the problem is I dont understand why TFS is complaining that the .cs file is not there even though I am checking it in and it is included in the csproj file.
I'm suspecting that the fact that I did a merge from a branch back to trunk is causing the problem but I cant tell why. I am relatively new to TFS CI so any pointers of where to look now would be a great help.
UPDATE - have since discovered that the working directory for the source files that TFS CI uses is not pulling the MyRepository.cs file into it and is not pulling the latest (checkin set) version of the .csproj file (looks like its the old trunk version still). This seems very bizarre as error message (above) insinuates that its getting the .csproj but is not getting the MyRepository.cs file.
Turns out this was occuring because the account that the TFS build agent used did not have retrieve permissions on the branch (or any other permissions). So the files that I had updated and the new files that were merged from branch into trunk were not appearing in the trunk build. A little annoying that TFS did not complain about this explicitly and instead just went a head and used the old trunk files (or if it did complain I could not find it in the logs).
Summary: Giving the build agent account permissions on the branch fixed the problem.
Well, the error indicates that the csproj file does indeed have your change in it, because the compile is looking for the file. However, it also indicates that the actual cs file is either not part of the check in, or it is checked in to a spot different than where the csproj file is expecting it. One other possible solution (if you have verified the other two) is that somehow your builds workspace doesn't have a mapping that would include the Repositories folder.
Related
I have a project under source control using TFS and Azure DevOps.
It all works normally except for one thing: When I check in a file, I get this error message:
TF10122: The path '$/KnowledgeBuilder/V2/$tf/1/1f8c47a1-8066-42d7-b56c-c9960b0ee7ea.gz' contains a '$' at the beginning of a path component. Remove the '$' and try again.
The check-in does in fact succeed, but I get three of the above error messages each time. I can simply ignore this, but it is starting to get annoying.
It appears the folder in question is a TFS created and controlled folder. I tried deleting the folder, but that remove the Project from Source Control, so I restored them.
Is there a way to resolve this?
This occurs in VS22 on a Blazor Server Project. I have tried opening the Project in VS19, making a change, and then checking it in, and it works fine. So, it must be something specific to VS22.
Someone, sometime, at some point, added that $tf folder to version control. It should not be there, ever, under any circumstances -- that's the folder that TFVC uses to track local workspaces. That's why removing it messes up your workspace.
Make sure any pending changes are committed or shelved first.
Remove that folder from source control. Make sure the change is checked in. You might need to use a server workspace to do this so that the $tf folder isn't relevant.
Use tf get to force a re-sync of your local workspace. tf get /all /overwrite should do the trick. If it doesn't, then just delete and recreate the workspace.
Add $tf to your .tfignore file (although if memory serves, that shouldn't be strictly necessary -- I haven't worked with TFVC in a few years)
We're using Visual Studio 2015.
I have three branches, 'DEV' where new code is made, 'MAIN', where tested good code goes as the primary repository, and 'PRE' where edits are made to previously released code. (PRE changes can be merged into DEV easily since we should never be working on the same file in two places)
That said, I merged good code from PRE to MAIN with no issues. I checked in those changes. When I merged that code from MAIN to DEV, there was conflict in the .sln file, but this is nothing new. Some new projects exist in DEV that don't yet exist in MAIN or PRE, so there's always some shuffling. I used the merge tool and attempted to resolve the conflict.
I completed the merge, and checked in the changeset. Only after check in do I realize there was a problem in the merge of the .sln file and I cannot build the solution because the paths for the files got crossed/corrupted somehow.
The error I receive is 'Metadata file \path\folders\buildlocation\solution.dll could not be found'. This error is repeated for every project. EDIT: I solved the problem with the build. It was not a .sln problem, but an error in the shared library.
===========================
That said, I believe the question below is still valid, if someone should ever need it.
So here's the question: I know I can do a rollback on DEV to get back to the previous state, but this creates 'new' changes which need to be checked in, which will overwrite the previous change. However, once that's done, I will still need to attempt to re-merge the good changes from MAIN back into DEV. Since that changeset is already merged, it is no longer available as a merge candidate.
How can I A) Rollback checked in changes from a merge in DEV and then B) Re-merge those changes into DEV and attempt to do it correctly?
Somehow, my Visual Studio project got very much messed up. The source code was good, but things were messed up in some of the configuration files. After hours of fighting with it, I found an earlier changeset (changeset 20) that compiled and ran fine, albeit without the latest changes (I was up to changeset 25 by now).
I then performed the following steps:
I retrieved a copy of changeset 20 into a new temporary workspace.
I used WinMerge to manually merge the latest source code changes into the changeset 20 code that was in my temp workspace.
I branched my main branch (called MainBranch) in TFS to a new branch called TempBranch.
I manually copied my merged files (from step 2) from the temp workspace into the main workspace for TempBranch.
I checked the merged code into TempBranch.
My Heirarchy looks like this now:
So, now, TempBranch has all the latest "good" code, and none of the corrupt configuration files. MainBranch has the bad configuration files.
So now that TempBranch is exactly how I want it, and it's what I want to base all further development on, what should I do at this point, so that MainBranch is basically identical to TempBranch?
I'm worried that if I try to merge the branches, it will try to merge the bad config files in MainBranch with the good ones in TempBranch. I want to make sure that for all differences in the two branches, the TempBranch version "wins".
You can try to merge from TempBranch to MainBranch, and take source branch if there are conflicts.
If the history is not important in MainBranch, you can reparent the TempBranch, and choose No parent. Then there is no hierarchy between TempBranch and MainBranch, you can work on TempBranch.
I have a ASP MVC project committed to SVN (used Visual SVN).As the project grew up i kept adding files.Most of the time when i "Get" project everything is available in VS2012. But today when i get the complete solution from repository - some of previously added files(cs and cshtml and respective folders they are in) are not included in project solution in VS explorer but they are there in the Directory that i did get from svn-
My Project in SVN~
MyMVCProj
ModelFolder
ControllerFolder
ViewFolder
view1folder~hasfiles
Now i add a new folder to viewfolder with files within and commit
MyMVCProj
ModelFolder
ControllerFolder
ViewFolder
view1folder~hasfiles
view2folder~hasafile(<=This available in my disk after getting from svn not in VS2012)
what am i doing wrong? I do get project everyday by >Visual Studio2012>VISUALSVN>Get Solution from Subversion;this saves project to disk and opened in VS
I guess that project's file wasn't committed to the repository together with other changes. Here is how you can solve this:
Go to Visual Studio | VisualSVN | Show log and look for the revision committed by DEV2 which added view2folder/,
Take a closer look at changed paths. Most likely the revision added view2folder/ with its contents but the revision didn't change MyMVCProj.csproj file.
The *.csproj file contains information about the files included in that project. When items are added to the project, references to them get into *.csproj file. If the file is missing these references, then you don't see added items in Solution Explorer.
In Solution Explorer, click Show All Files, right click view2folder/ and choose Include in Project.
In VisualSVN's Pending Changes dialog you can see that project's file has been modified. Commit the change.
That's it.
I found solution after some workaround -
When two or more person working on a project this situation may occur. For me it happened because of following scenario:
Dev1 commits projects to SVN,
Dev2 GETs it and does something and even adds files/folders,
Dev1 just updates and starts working. Now the newly created files by Dev2 are not included in project; but they are available on local disk. These had to be manually added to project after update. (Look for related post).
Please Update here if my approach is wrong.
I'm trying to get latest of my project. When I do, TFS shows me that I have conflicts on every single file in that project. Every file has the same conflict: Conflict Type: Writable File - A writable file by same name exists locally.
The resolution it gives me is "Overwrite Local File or Folder" but I have to do this one by one.
Why does TFS thinks that I have conflicts (I haven't changed any files)?
The Visual Studio 2010 conflict resolution dialog supports multi-select.
If you select the first conflict, hold down Shift then select the last conflict, the "Overwrite Local File or Folder" resolution will be applied to all the selected conflicts.
You can also use the command-line tool tf resolve /auto:OverwriteLocal to resolve the conflicts.
Grant's answer is great for how to resolve multiple conflicts.
As for why you have those conflicts, generally speaking, your TFS client has detected that a file exists locally that is not managed by TFS, but you are trying to perform a get operation that would overwrite that file.
If you're following a normal development workflow (and not going and editing files outside of your editor), the most common source of writable conflicts is from shelvesets. If you were to pend an add on a file, then you were to undo that add (either explicitly or because you shelved the change and deselected the preserve pending changes button), the file is not deleted. (This is to prevent data loss - it's not uncommon that you would want to create a file but not have it checked in to source control.)
Now if you (or someone else) were to check in that shelveset (either through creating a build from that shelveset, or from gated check-in, or because your code reviewer checked in your shelveset directly), then when you do a get latest, your TFS client will detect that the file still exists locally and thus, you'll have a writable conflict.
This may not be particularly obvious in the case of gated check-in. How gated check-in actually works is when you try to check in your changes, your check-in is actually converted to a shelveset. The TFS build agent will then try to build your shelveset, and if the build succeeds, it will then check-in that shelveset on your behalf. If the build fails, the shelveset remains and you can unshelve to fix the build errors.
For this reason, it's important to run the build notification application when you're using gated check-in, which will allow you to "reconcile" your changes once they're submitted. Reconciling your check-in will simply do a get of the check-in that was submitted by the build server, but it will avoid conflicts since it understands the context of the changes that are on your local disk. (It will compare the contents on your local disk to the contents on the server.) If you do not choose to reconcile, you will, unfortunately, have writable conflicts on files that were added.
(Note that this scenario will not produce a conflict in the next version of TFS - if there are no content differences, TFS will not produce a conflict.)
You can do it for whole folder, multiple folders or entire project where conflict files exist.
You need to right click on that specific file/folder, go to Advanced, Select "Get Specific Version..."
You must have all Rights (Full control) to a specific local file or folder. Check it out. If it's not true you have to delete all local files, change Rights and then get latest files from server.