CODEWITHSUNDEEP
visual-studiotfs
ElHaix
ElHaix

Reputation: 12986

Why does Visual Studio lose my library mappings after TFS check-in/out?

I've been building an application on one machine for some time and finally did a TFS check-in.

Spinning up another, a new workspace and doing a check-out, the solution no longer compiles, where references have been lost and errors/warnings like the following in various projects throughout the solution:

The type or namespace name 'OData' does not exist in the namespace 'System.Web.Http' (are you missing an assembly reference?)
Could not resolve this reference. Could not locate the assembly "EntityFramework".

Also

    Warning 1   The "EnsureBindingRedirects" task could not be loaded from the assembly C:\TFS-WorkRepository\Project\Project Solution - v001\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.Tasks.dll.
 Could not load file or assembly 'file:///C:\TFS-WorkRepository\Project\Project Solution -
 v001\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.Tasks.dll' 
or one of its dependencies. The system cannot find the file specified. Confirm 
that the <UsingTask> declaration is correct, that the assembly and all its 
dependencies are available, and that the task contains a public class that 
implements Microsoft.Build.Framework.ITask. Project.AdminWebsite

I have already enabled Nuget package restore on the solution and other imported libraries/DLL's in respective common/lib folders.

I'm guessing if I check-in the bin and obj folders for the solution projects, everything will work. However typically TFS is for code, not DLL's.

So, how can I get around this issue?

Thank you.

Upvotes: 3

Views: 828

Answers (1)

Rodders
Rodders

Reputation: 2435

I disagree with checking in the bin folder. There are much better ways to handle dependencies and would vary depending on the dependency! In this case, with your own code, you could either look at hosting your own NuGet server: https://docs.nuget.org/create/hosting-your-own-nuget-feeds you could then reference private and public assemblies in the same way.

or a simple (more inferior) approach would be to create a 'Dependencies' folder at the root of the solution, add that to source control along with your private assemblies and reference from there.

With regards to your package restore issue, I had a problem like this recently, try to delete the contents of your packages folder (from source too) but keep the repositories.config and re-run it.

Upvotes: 2

Related Questions