I have a Visual Studio Solution (multiple projects) which was able to build on another computer in the past, that can't build after being pulled with Git on a new computer. The IDE (VS2017), platform target (Any CPU), .Net Framework (.Net 4.6.1), ... and everything else should be the same, yet it gives a few "The type or namespace name 'nameOfTypeOrNamespace' does not exist in the namespace" errors. There're also a few "Metadata file 'pathToFile.dll" could not be found" errors. Example screenshot:
Most of the missing assembly's are self-written but there are a few which are thrid party, as seen in the solution explorer. I also don't seem to have a reference folder in the solution anymore:
I know there's already a few questions involving missing namespaces, but none seem to match my particular case. I've already checked references and namespaces but can't seem to find the problem (no typo's eithersince it worked before). It's probably really hard for someone to find the problem without the project, which I can't share, so my question:
How should one best search for the solution?
I've also checked my .gitignore file and verified that it shouldn't have caused this issue.
Update as said in the comment section: I'm using Nuget but the Restore Nuget Packages option does not work out.
I currently solved this issue by doing the following:
Remove packages from the .gitignore-file
Open a cmd and type the following Git commando's (be sure to commit all your changes first since you might lose them by executing following commands):
a. git rm -r --cached . (clears the cache so that Git can detect changes)
b. git add . (adds all changed files)
c. git commit -m "Fixing the packages issue" (commit the changes)
Keep in mind that this is only a quick fix or a hack and that this doesn't actually solve the issue.
#Wouter's solution is working but as he said it's not optimal way and cause huge amount of source control storage occupied as well as increase download and upload size in push and pull(Checkin and Checkout in TFS).
To restore packages if 'Restore Nuget Packages' not works, use this solution:
From Tools menu in Visual studio, chose NuGet Package Manager--> Package Manager Console
and run this command:
Update-Package –reinstall
I hope It works.
Related
I am working on a C# program that utilizes EntityFramework, I've cloned the program from git repo, but now it is having that dreadful Metadata file 'EntityFramework.dll' could not be found error. I have searched and tried countless suggestions for this kind of problem, but none worked. I've already checked that the reference to EntityFramework.dll in the .csproj files are correct and it is definitely there under the packages\EntityFramework.6.2.0\lib\net45\ folder. So I am not sure what else to try.
Ok, I've resolved this problem. Here is what happened. Apparently, when cloning into local directory, one of the folder on the path has a space in its name (like My DSS), and this nuget issue seems to indicate the inability of nuget to find package with space in path. So, once I changed that folder's name to MyDSS, it compiled successfully.
please have a look on the bin folder ,sometimes the dlls do not exist there .
This typically happens when teams check in files that should not be checked in (such as the .suo file) or have "optimized" their builds to exclude rarely changed projects. (unticking projects in the configuration manager.)
Another common cause for missing references is when devs reference a dependency from a /bin folder instead of the packages folder, but it sounds like you've confirmed that isn't the case.
Other questions such as Metadata file '.dll' could not be found list a number of things to check, so your problem will surely be one of these. Try building each project individually, working from projects that have no project dependencies upwards to the main application project(s). Ensure they're running the same .Net versions, check the solution NuGet packages for dependencies with "multiple versions" and consolidate these so that the solution is using a single version of each dependency. (generally good for cleaning up) Also look at .config files for version re-directs that sometimes get zombified in source control.
In Visual Studio, on top, click on Build -> Configuration Manager. Make sure that the build checkbox next to your project is checked. In case it already is, uncheck it and then make it checked again. Clean your Solution and Build it again after this.
I was having trouble with a dependency downgrade error (as it turned out, due to a bad git conflict resolution I had two references for the same package in the csproj file with different versions - anyway, not the issue).
One of the things I tried while attempting to discover this was deleting the package cache from %userprofile%\.nuget\packages - I deleted the entire packages folder.
I then discovered there were duplicate package references in the csproj file and thought "ok, I'll just remove the duplicate and do a dotnet restore Blah.sln and all will well. Nope. I kept getting a build error:
metadata file microsoft.codeanalysis.analyzers.dll could not be found
After a lot of Googling, it turns out that to solve this issue I needed to open the solution in VS2017 and run a rebuild command. Doing this restored the required packages and I was then able to build successfully in VS2019
This issue led me to the answer, although isn't specific to the issue I was having necessarily
Due to some git project changes, when I try to build, I get an error:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\MSTest.TestAdapter.1.1.11\build\net45\MSTest.TestAdapter.props.
The references to the project contain four missing references, two of which Microsoft.VisualStudio.TestPlatform.TestFramework, and Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions which seem to be related.
The other two, in case it proves to be relevant are System, and System.Core, but they aren't causing any problems... which is weird, cause I'm definately using them.
That missing file, the one from the error message, is absolutely there.
I've tried to uninstall and reinstall both packages, but nothing seems to help.
Open the projects .csproj file with your favourite text editor and delete any references to
MSTest.TestAdapter.props.
Edit: This is safe to do so, all that happened is that you have removed the DLL but for one reason or another your project file still references it as a dependency.
I would modify #JoshuaDuxbury's answer to say: you need to clean out obsolete references to MSTest.TestAdapter.props.
In my case, I had just updated the MSTest.TestAdapter NuGet fronm 1.3.2 to 2.0.0, but apparently when I did that, Visual Studio didn't clean up my .csproj file perfectly.
So, I had to delete the superflous MSTest.TestAdapter.props highlighted in two places:
Near the top of the project file:
...and again at the bottom of the file:
Once I did that, my CI pipeline was able to build everything correctly again.
Some of you with sharp eyes may notice something funny w/the 1.3.2 of MSTest.TestAdapter shown above: it seems the path to the packages folder is off! But that would be a topic for a different thread (or maybe an alternate explanation to why your build pipeline is unhappy.. maybe just fix your path to packages).
My issue didn't occur on my development box but on the Azure Build Pipeline. I removed the offending props files as per the other answers but to no avail. Ultimately I had to add the Nuget restore step to my the Azure build pipeline and move it to the proper slot before the building:
I have no idea how I've done it but I've had the same error and I thought the files were here but they actually weren't... so anyone who has this issue double check the paths.
In my case the Packages folder was at the same level as the project file however it was looking for files in the parent directory. Nuget restore and Update-Package -reinstall
were not fixing anything.
Windows 8.1 Enterprise x64, Visual Studio 2015, MVC 5, EF 6, VS Online using git
I'm a relatively new developer with Visual Studio (about nine months), and ever since I started I've had an incredibly difficult time with references and NuGet packages. All of my references were working correctly on Friday when I shut my computer down for the weekend. I didn't touch the computer at all the entire weekend, now I've booted up today and I have a ton of reference errors:
(There are 6,262 errors total but I obviously can't screenshot the entire thing.)
Like I said, this sort of problem occurs very often, and it's incredibly frustrating. Things I've tried:
Ensure all references throwing the errors actually are referenced
Un/reinstall the packages throwing the errors in NuGet
Completely delete the contents of the packages folder and let NuGet restore them (all reinstalled, views have the same errors as before)
Ensure every single reference is set to Copy Local
Close the solution, delete all bin and obj folders, reboot computer, clean, rebuild
Ensured all necessary references are in the relevant web.config (either inside Views or at the root)
Check for NuGet option to restore missing packages (did not appear, all packages are in my local packages folder)
Other things on SO that I'm sure I've forgotten to list here
I'm at my wits' end with these packages and references. It's a different fix every time, and this time I can't figure it out. Am I missing some obvious fix, something I overlooked? Is there a way to somehow take a backup when this is working and restore it whenever things break? Any ideas whatsoever, whether helping with the current problem or for fixing the underlying problem, would be very much appreciated.
Additional note
The problem is NOT only with views--controllers are also throwing errors. Specifically:
The type or namespace name 'Controller' could not be found (are you missing a using directive or an assembly reference?)
(It literally says Controller, that's not something I changed for privacy or whatnot.)
These are thrown despite the fact that I have using statements for all of the necessary namespaces. The using statements themselves work properly, but the error is thrown in the code. The automatic fix suggested is to manually reference everything: for example, var sb = new StringBuilder(); wants me to change the line to var sb = new System.Text.StringBuilder();. Testing that fix does not correct the problem, the same error is thrown but on System instead of StringBuilder.
Additional requested information
I use git with VS Team Services (but packages are ignored with .gitignore).
I and one other person work on this, but the other person hasn't touched it at all (not even pulling from the remote repo) in several weeks.
References in the .csproj file are in the format ..\..\..\packages\ (correct for the location relative to the .csproj file).
Targeting .NET 4.6 (always have been, that's not new)
All references resolve, no exclamation marks in the references list.
New Projects
There is one single thing you need to do in order for packages to work correctly with git:
When you create a repository, make sure you add a .gitignore tailored for Visual Studio development. You can search google for such a file or take it from here.
This will make sure you don't commit anything that will cause problems later.
This should solve a lot of the problems that usually happen when you check in packages to a code repository. You can add/remove packages and upgrade packages and also be able to clone the repository to a new machine and packages will be restored automatically.
Existing Projects
This is good for new projects. If you already have a project with a great big mess, then it is very hard to fix it since Visual Studio keeps package versions in several places - packages.config and app.config (and web.config where relevant).
Option 1 - Fix the current project
You can remove all packages (remove all the references from all projects and delete the package contents).
Make sure that the packages no longer appear in any file (e.g. packages.config or app.config). Now add the .gitignore and then start adding the packages back.
Option 2 - Create a new project
If it doesn't work, start a new project, add the .gitignore, transfer all the code (only your code) and install the packages.
I'm not quite familiar with how Git works in VS, but I recall one time recently when using TFS that unbinding the solution from source control, fixing all packages, cleaning and re-building before binding it again solved a bunch of issues regarding NuGet references.
I apologize if Git works way different within VS.
I'm trying to figure out what the best way to handle this scenario is.
Let's say I have a library that's referenced by multiple different non-related solutions, let's call it WebServiceInterface.dll. This library has a dependency on JSON.NET.
Before NuGet
The JSON.NET binary was referenced via a SVN external in the WebServiceInterface project. Other solutions which had a dependency on WebServiceInterface referenced the project (also as an SVN external) and as a result pulled both the project, and it's dependencies.
With NuGet
I haven't figured out how to force the JSON.NET reference to be stored under the WebServiceInterface project (as opposed to the RandomSolution\packages location). I found reference # nu-get to project-level and solution-level pacakges, but I can't seem to find out how to specify this when I add a dependency via nu-get.
The goal here is that when someone checks out WebServiceInterface and adds it to a new solution that it builds (instead of having broken references to JSON.NET which point to the packages directory under whatever the last solution was that checked in).
When I went to find out if Chris B had created a NuGet issue for this, I couldn't find one. EDIT: He did, see his comment below. But I did find a semi-documented feature of NuGet that I used to solve this problem: Allow specifying the folder where packages are installed
Let me break this question into 2 issues:
getting NuGet to allow for multiple solutions to use the same packages location
getting the NuGet packages to automagically fetch from source control when you include a project that has NuGet packages
Problem 1:
By default NuGet stores packages in a packages folder in the solution's folder. To change that location, create a nuget.config file in the solution's root folder with the following contents:
<settings>
<repositoryPath>..\..\..\Utilities\Library\nuget.packages</repositoryPath>
</settings>
<repositoryPath> is relative to your solution; so obviously make it whatever you want. Make each solution have it's own relative path to the same packages folder.
As far as NuGet's flow, from that point, the paths in repositories.config are relative to the folder containing repositories.config, not the solution, so now all projects/packages are managed independent of the solution location.
This allows multiple solutions to use the same packages in source control, and if those solutions use the same projects (that use NuGet packages), those solutions/projects will all be kept in sync no matter which solution updates the package.
Problem 1 completely solved.
Problem 2:
Let me address this from 2 perspectives. This applies to Visual Studio and TFS -- I'll leave SVN for someone else to address.
First: if you have no source code on your drive and do a get of a solution (not a project), I prefer to make it so that you get everything that solution needs to build. There shouldn't be any missing references to go manually grab. That much we can do by adding the package files as solution items. Yes, in each solution. A bit of work, yes, but when it's done the package files will fetch/update from source control automagically.
Second: In a new solution, when you include an existing source control project that has NuGet packages, you have to manually fetch the packages from source control and add them as solution items. At least anyone else getting your solution in the future will automagically get everything they need to successfully build. At least with VS/TFS, this is just the way it is, AFAIK. If projB depends on projA, and you add projB to a new solution, VS/TFS won't automatically grab projA from TFS. You have to do that manually. So then the same goes for dll references (like NuGet packages).
Summary of my solution:
Only one copy of packages in source control for all solutions
Any solution can update packages and all the other solutions will be kept in sync*
* Once one solution updates packages to new paths or file names, they will appear as missing references to the other solutions and you'll have to manually clean that up. But at least you know right where the packages are in source control "(as opposed to the RandomSolution\packages location)."
The packages are always stored at the solution level, so if you install a package into multiple projects, they came from the same place. I don't believe you can configure it so that each project has its own packages folder.
I'm not sure there's a nice way to do what you're trying. You could maybe have a build step on the project that fetches the package, but I don't know how well that will suit you.
I'd recommend posting in the NuGet Issue Tracker to get a discussion going. The people working on it seem pretty active, so it might be something they can add support for in a future version :-)