TFS Project Load does not restore DLL references

Charles Sugden
Charles Sugden used Ask the Experts™

I am fairly new to the TFS environment and have tried to load an existing project saved to TFS into my local machine for development.

1. I identified the library and performed a get-latest
2. Entereed NUGET and did a RESTORE-ALL

Afterwards I found that no dll references whatever were restored.
How can I accomplish this on a regular basis?
From my readings it seems that there is no straightforward solution other tha creating a local folder and moving the DLLs into and re-referencing to that folder.

The problem with all of that is that this project was not built from an empty project andf has a lot of boilerplate DLLs (ASP.NET project) that are not used such as ANTLER. So the DLL list is quite long.

Thanks in advance

Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
One thing you might try, I've noticed with TFS control, VS sometimes botches the references.  Standard practice, TFS won't upload .dll files into source control (which is what you want), but SOME of the packages it will.
So you end up with FOLDERS for the nuget packages, so rebuilding thinks the full package is there, but the dlls are empty.

If you open a file explorer to your project, and go to the "packages" folder, try deleting everything in there, and then doing a rebuild.
That might get restore to actually kick in and bring the files back.


My packages folder qas empty upon 'get-latest'. The packages.config did have files in it.

After the RESTORE, all packages were restored except Microsoft.codedom.providers.dotnetcompilerplatform2.0 as noted by the 'builder' Also the references to ALL of the Microsoft dlls has yellow triangles. Interestingly though, I  removed one of my own DLLs and rereferenced it from a local folder I kept for it in my project and it still appeared with a yellow triangle....

We are transitioning to GITLAB (ie GIT) but I tyhink I will still have the same problem there.
Just by a fluke, I need to use a different system for a bit and had exactly the same problem you're describing.
In this case, the original project was actually POINTING to the wrong location.

If you right click the project -> Unload, and then right click -> Edit, to bring up the raw xml of the project file.
Look for ALL items with <Reference> and <HintPath>, and double check the packages folder.

In this case, the PROJECT itself was referencing just <HintPath>packages\xxx</HintPath>
But in the solution, the target packages folder was underneath the project level.
So hint path SHOULD have been:

After doing a text replace all on that file, all the references were back and project built and ran properly again.
C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.


The references within the project do seem correct.
I tried removing ALL of the references and adding one of them back into the project but nothing was placed in the bin folder and the added project still shown as a yellow triangle.


My further research leads me to believe that wither NUGET or the .NET setup prevents accurate restoration of the bin folder.

1. I created a brand new ASP.NET project/web forms project
  (I chose this type because it creates a lot of unnecessary dlls that no one really uses
2. I tested the correct execution and build .
3. I deleted the contents of the packages folder and I deleted the contents of the bin folder

4. I open the solution and ran NUGET Restore.

5. All NUGET packages were restored but no bin folder contents existed.

Is NUGET supposed to create entries within the BIN folder or NOT?
If NOT, then bin folder contents should be included in the source control.
I have not tried this with GIT just yet

Any ideas?
The BIN folder should never be placed into source control, and should come down blank.
Any NUGET restores and adding references will put objects into the packages folder, or the "obj" folder as refs.
The BIN folder will only get populated on build / compile, when the compiler copies all the referenced DLLs it needs into there and builds the project files.

Any chance you can upload the source code somewhere?  Would like to help out but will be a lot easier if I can actually get my hands on the project.


Sure thing.
I had deleted it but I recreated the standard project that I used. How can I share the entire project?

.NET 2019 - Standard project boilerplate
ASP.NET Web Forms Project
Due to the size and nature of files, I doubt you can upload here, but you can just use a free online file share like wetransfer

There's a few like that which don't require registration and let you share files pretty easily.


Who should I email this to?


I looks, acts and builds perfectly fine for me.
Which leads me to suspect you might not have .net 4.7 installed on your machine?
That would certainly cause the dll errors.


!!???!!  I checked and I have 4.7. Here is the registry entryscreenshot of registry key
Well this is really starting to bother me.... yes certainly looks like you have it on there.
Was a little concerned that the reg value said 4.7.03 (the project is 4.7.2), but the release code shown is for 4.7.2.

Just for the sake of elimination, can you go to the project properties, and drop it to 4.6 and see if that pulls the references back in?
Stumped as to why it would work perfectly fine on my system but not on yours unless there was a version issue.


Things are getting stranger and stranger.
I have been getting some inconsistent behavior from .NET 2019 right now.
I will try an earlier framework and an earlier version of .NET today, more later on that.

When I initially create the project the BIN folder has X number of items in it (see attachment)
After a BUILD the number of items in the BIN is X+? (see attachment). Seems odd that it wouldn't tell me anything about that in the output window.

Sometimes the NUGET restore is working and sometimes it is not.

The yellow triangles seem to mean that the PATH property is not defined.
Sometime a BUILD clears that up and sometimes it doesn't.

Sometimes I can delete files from both folders, load the SLN and the references show nothing bad (no yellow triangles). This is odd also because the files don't exist and I guess no reference checking is done at load time.

I will attempt to get the sequence of failure or success hopefully today.BIN when project is loadedBIN after a buidYellow TrianglesPath not defined
Although I have had some success in duplicating the problem with a generic project, I have found that the project that I am working on has been migrated from 2015 to 2017 to 2019. The project file references didn't match up with my generic test project references so I can conclude that it may be the conversion to the new project format that may have corrupted it in some way.

I have spent entirely too much time on this and I believe I have found a work around by rebuilding the project from scratch in VS2019.
I have loaded it into TFS and restored it successfully.

Thank you for your help.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial