I'm desperate to fight against this problem: when I enable nuget on a solution and it grabs missing packages from web, it constantly tries to check-in them to TFS, although I definitely don't want it
There's a lot of advices on the web regarding this problem, but none has helped so far. I've done the setup according to this: http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages, tried to "cloak them" as it is recommended here: http://www.xavierdecoster.com/post/2011/10/17/tell-tfs-not-to-add-nuget-packages-to-source-control - all in vain. I'm stuck. Probably I lack some critical understanding of how does TFS client work with NuGet and VS 2010.
Any help is appreciated. Thanks!
The only way I know is a little bit manual but can be automated at some point.
The big issue is the packages folders being overcrept. You can undo the packages in Visual Studio, the files won't be deleted. There is also a CLI for that:
C:\project\Main\packages> tf undo /recursive *
Do not use this command when you have pending changes on the repositories.config file.
You just need a little .bat file to check for pending changes (repositories.config file) and do the cleaning.
I've given up an any NuGet / Solution based approach to this problem.
I simply setup my workspace so that the packages are cloaked.
For example setting up your workspace like this means Packages is ignored by Source control:
Status Server Path Local Path
Active $/TFS/ C:\Code
Cloaked $/TFS/Packages
Even cloaking the packages folder as DaveShaw suggests can still cause problems, especially when adding packages to large solutions. Best way I've found so far is to create another Visual Studio configuration...
devenv /RootSuffix NoTFS
and then delete the TFS provider for that configuration
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0NoTFS_Config\SourceControlProviders\{4CA58AB2-18FA-4F8D-95D4-32DDF27D184C}
I'd suggest exporting that part of the registry before deleting and make sure you delete it from the NoTFS configuration.
After that you can run Visual Studio when you want without with TFS by starting it with the RootSuffix parameter above.
Related
I have a VERY large project which just went through an upgrade process. The upgrade is a process external to Visual Studio. As a result, files that are deleted by the upgrade process do not get properly detected by TFS so TFS pukes on checkin saying that it can't find the file.
The problem is that there are several hundred files that need to be excluded to resolve the issue. I could do this for days before I'm done. I'm pretty sure my boss would prefer it not take several days.
Is there a quick way to find and automate the exclusion of these files so I can just be done with it?
You have two options...
Use a Local Workspace - if you go into the settings of your Workspace you can change it from Server to Local. This will allow the changes to be detected automatically. You may need to copy everything out and then back in if you have already made the changes...
Reconcile the difference - You can use the TFS 2013 Power Tools and the "tfpt online /adds /deletes /diff /noprompt /recursive directory-name" command...How to have TFS 2010 detect changes done to files outside of Visual Studio?
Nuget seems to stubbornly ignore the flag inside .nuget/nuget.config file. It's important to note that no actual packages are being added to the source control, just the annoying repositories.config.
I can confirm that our settings are correct, and if I remove the flag from the .nuget folder, then also packages start being added.
The only reference to my problem I could find here - https://github.com/Haacked/NuGet/pull/2. But it seems that this pull request is made in a clone repository.
For reference we are using VS 2013 with TFS 2013 with latest updates. We use server workspaces and I couldn't make .tfignore file work probably due to that.
Has anyone experienced that problem and if so, how did you overcome with it?
we use a .tfignore file for this. Here's a blog on how to do it:
http://blog.appliedis.com/2014/11/06/excluding-files-from-team-foundation-version-control-using-tfignore-files/
Me and 2 colleagues are using TFS and VS 2013 on a shared project. Me and my Colleague "Bill" are able to edit files and check them in whenever we like. But colleague "Bob" cannot do this. They appear as "locked" in his solution unless he goes into TFS and specifically checks out the file. Me and Bill dont need to do this, we can simply edit the files and if we both try and check in the same file it notifies us of merges. Bob has the same TFS permissions as us, and as far as I can see the same visual studio settings.
Any ideas on what might be causing this?
This sounds like a workspace issue.
Bob needs to change his workspace from a server workspace to a local workspace. If he's using VS2010 or earlier, he will not have that option -- local workspaces are only supported in VS2012 or later.
Here's an MSDN link on how to configure local workspaces:
http://blogs.msdn.com/b/visualstudioalm/archive/2012/10/05/set-local-workspaces-as-default-when-upgrading-to-tfs-2012.aspx
I have a visual studio 2010 project under mercurial. I use mercurial either via command line or TortoiseHG. I want to work on a new feature, so I clone the repo. But now I am confused, am I supposed to import an entire new project into VS2010 just to work on this feature? I tried importing the VS Solution that was cloned, but got lots of build errors from dependencies cannot be found errors, which I assume is because I am trying to load this cloned Solution just like the original Solution and some paths are wrong (no idea where though).
How are you supposed to use mercurial and VS2010?
Cloning produces an exact copy of the original repository.
The clone should work exactly the same way as the original repository, so you open your cloned solution exactly the same way as the original one.
If you get build errors in the cloned solution but not in the original one, there are probably some dependencies (=3rd party assemblies that your application needs to work properly) which exist in the original solution, but weren't committed to the repository.
So, when you clone the repository, the referenced files are missing in the clone...so the clone won't work.
Source control works the best way if you check in the complete solution, including all dependencies:
Make a "Libs" folder somewhere in your solution, put all your dependencies inside, reference those files from your solution and commit the whole "Libs" folder to the repository.
If you do it this way, you can clone the repository from a different machine and open the solution, without worrying about any dependencies...it just works.
It sounds like your root problem is that you're adding references using full paths rather than relative paths. You'll need to rectify that before branching is going to be easy for you. I usually make a "References" folder that is on the same folder level as the .sln file, but one level up from the individual projects, then branch the whole thing.
Example Folder Structure
MySolution
MySolution.sln
References
MyProject1
MyProject2
As for VS integration, I use TortoiseHG combined with VisualHG, it works great.
There is also Mercurial Toolbar
Other tools
This may or may not be related, but I've had to load hotfix KB2286556 in order to get rid of the "Unable to update project dependencies" error from VS2010 when building a fresh checkout of our code. It seems this only happens to setup and deployment projects when compilation is invoked from the command line (such as in our build system), but when it happens it's a very frustrating issue to find the solution for.
Also, VisualHg is a good way to track and invoke versioning from within Visual Studio.
While VisualHG still proves to be a wonderful tool after so many years, I would also suggest HgSccPackage as a very viable alternative for all Visual Studio versions (up to VS2015).
PROS: Stand-alone package (TortoiseHg is not required).
CONS: Doesn't have all the handy features of TortoiseHg such as Git support (which I find incredibly handy to handle GitHub-hosted projects) and Mercurial Keyring.
Both of them are freeware and can be installed through the Visual Studio GUI (Tools > Extensions and Updates...).
For a more extensive comparison between them you can also read this post on my blog.
We have a large solution with many projects. Some of the projects were outsourced, and the vendor used TFS. When they commited into our SVN repo, some of the bindings are still hanging around.
When I open the sln, VS2008 says "The source control provider associated with the solution cannot be found, do you want to remove them". I hit yes, save and exit, and then next time it does it all again :)
So - anyone know how I cam get rid of any TFS bindings from the sln once and for all? Do I need to manually search the csproj files for any "scc" references and remove?
Thanks!
Some PDA deployment projects(.vddproj) had some bindings hanging around.
Just removed them manually :)
The way to remove the bindings is to search the csproj files and remove it. There is a similar question on this topic already: See: How to remove TFS source control bindings for a solution from the command line
Here's a PowerShell script to remove the source control binding info. It was ported from some C# and only tested on VS 2010 solutions. The original code was written for VS 2005 and 2008 so you could probably add the relevant stuff back in.
Here you can find a tool (including source code) to remove both SCC footprint from the solution and project files and the .vssscc and .vspscc files. In addition, it removes the output and other configurable directories.
Hth
Stefan