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
Related
I have a VSIX extension which I have migrated to a new solution (basically to remove older projects targeting older VS versions no longer supported by my company) and to simplify the codebase for ease of maintenance.
Within the IDE, it does not matter if I set the active configuration to Debug|x86 or Release|x86, it will build a VSIX artifact OK. All good so far.
If I use
MSBuuild /t:Build /p:Configuration=Release /p:Platform=x86 -restore -detailedSummary MyExtension.sln
it will build without any errors, but no VSIX is produced.
I have poured over the terminal output and there are no warnings/errors and the DLL output of projects in the solution are produced.
I did read the following:
Project not selected to build for this solution configuration
The option to click deploy from the above link is not available for my VSIX - all the deploy options are disabled.
I have searched S.O. for similar issues regarding a VSIX not being produced, but none seem apt.
How should I debug this? What is different about a command-line MSBuild from the in-IDE build? Hopefully somebody has had a similar experience and can let me know what was causal for them, so that I can give something a try.
Update 1:
It transpired that although I was targeting .NET Framework 4.6, some .csproj references copied over from the migrated project had entries for net472, despite NuGet packages themselves being selected for compatibility with .NET Framework 4.6.
I had to manually edit a few .csproj files. There were some reference issues in associated projects that then needed fixing.
The residual issue now is as follows:
The in-IDE build fails with a single error...
A PackageReference to Microsoft.Build.* without ExcludeAssets="runtime" exists in your project. This will cause MSBuild assemblies to be copied to your output directory, causing your application to load them at runtime. To use the copy of MSBuild registered by MSBuildLocator, set ExcludeAssets="runtime" on the MSBuild PackageReferences. To disable this check, set the property DisableMSBuildAssemblyCopyCheck=true in your project file (not recommended as you must distributed all of MSBuild + associated toolset). Package(s) referenced: Microsoft.Build.Framework
So I grepped my source code folder for <PackageReference Include="Microsoft.Build and only a single project was in the result list. When I checked this project file, the entry in question did have ExcludeAssets="runtime" so I am unsure why the error is reported. I have tried project cleans followed by rebuild, or deleting bin and obj folders before building, to no avail.
I guess my question now is whether <Package Include="Microsoft.Build are relevant, since these are not <ReferencePackage Include elements as mentioned in the error message.
Update 2:
I hang my head in shame. PBKAC regarding Update 1 error. I had sent a copy of the code to a build engineer who committed it to a branch in our VCS. I then cloned this branch to a different location, and copy+pasted my more recent changes over the top. However, the grep tool (AstroGrep) I was using was still pointing at the older location not in the VCS. The older location contained package references with ExcludeAssets="runtime" as required. However, the newer location did not. Once I noticed this, I corrected it by editing the faulty .csproj file and the error from Update 1 went away.
However, I still appear to have the original issue the question is about.
I am awaiting my company's security team to approve the use of MSBuildLog so that I can get more detail and hopefully find the cause.
One other commenter suggest moving to solution PackageReference build rather than using packages.config. There is a question as to why this is needed. I am aware this seems like it could create a significant amount of extra work due to: this for which there are workarounds, but the commenter mentioned a "need" to use NuGet this way, when I think it is optional. I wish to understand more before committing to such a change.
Unfortunately, this is one of those things where it's a case of user beware.
When using NuGet, it is possible for it to appear to have succeeded in updating a NuGet reference, but unless one checks the underlying packages.config meticulously, you may not be getting what you think.
As I am migrating a solution that used packages.config instead of <Project Reference .../> elements in .csproj files, I have been caught out by IDE default behaviour changes.
NuGet seems to update the .csproj using <PacakageReference.../> elements by default. But this does not amend the packages.config entries that may already exist. As such, I ended up with a mish-mash that MSBuild seemed confused about at build time. Rather than throw an error, it just did not build what was expected.
The old packages.config files had entries targeting .NET Framework of net472 in some cases. I was adding NuGet references to earlier versions for net46 since this is what I need to target now, and this resulted in the problem behaviour, since any unchanged net472 entries were no good for producing the build output.
Since the project needs to support VS2015 also, I need to rely on packages.config approach and not <PackageReference.../> approach, which was not updating older references in the expected way.
As such, I had to remove the NuGet <PacakgeReference.../> and re-introduce correct package versions in packages.config. Once these were all correct, the VSIX built OK.
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 can't run my unit tests.
I have the next error:
Your project does not reference ".NETFramework,Version=v4.6.2"
framework. Add a reference to ".NETFramework,Version=v4.6.2" in the
"TargetFrameworks" property of your project file and then re-run NuGet
restore.
In app.config:
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.2"/>
</startup>
In Project > Properties > Application > TargetFramework (.NET Framework 4.6.2)
How can I fix it?
Please make the next steps
Clean solution
Clean folder "packages"
Delete folder "bin"
Delete folder "obj"
I experienced similar issue, but with v4.7.2. Namely, I kept getting build log message like this:
error : Your project does not reference ".NETFramework,Version=v4.7.2" framework. Add a reference to ".NETFramework,Version=v4.7.2" in the "TargetFrameworks" property of your project file and then re-run NuGet restore.
Despite the fact that it looked similar, none of the above proposed steps worked for me. I kept seeing this message after each build. Nothing seemed to be able to help.
In fact, the problem was related to that, due to migration, I had to put two projects in one folder of code. One of them was targeted at .Net Core, another at .Net Framework, both referenced same .Net Standard libraries. Apparently, they share the same obj folder where Core projects put project.assets.json file. Actually, exactly this file interferres with the Framework project preventing its normal build. Seems even if you performed Migrate from packages.config to PackageReference... which was recommended as one of possible solution.
You can try to fix the issue by putting the following snippet into your Framework project file:
<Project>
...
<PropertyGroup>
<BaseOutputPath>$(MSBuildProjectDirectory)/out/$(MSBuildProjectName)/bin</BaseOutputPath>
<BaseIntermediateOutputPath>$(MSBuildProjectDirectory)/out/$(MSBuildProjectName)/obj</BaseIntermediateOutputPath>
</PropertyGroup>
...
</Project>
It immediately worked for me, it was only later when I attentively read why we need it and why it works. I unexpectedly found it in part 2 of Migrating a Sample WPF App to .NET Core 3 under Making sure the .NET Framework project still builds section. BaseOutputPath and BaseIntermediateOutputPath msbuild variables can be found there, not sure if they are documented well anywhere.
That happened to me when opening a VS2015 project in VS2017. Deleting the project.assets.json from the obj folder did the trick.
Anyway, the Framework from the message was missing in the file, I did not add it there though, went with deleting it.
git clean -xdf
That should do the trick. It worked for us also in Jenkins. (we simply replayed the failed build with a modified script that ran git clean first).
For some reason MSBuild / Visual Studio get confused when switching between branches that target different versions of .NET Framework, so I had to do git cleans regularly while switching between branches.
The file that was causing issue for me was obj/project.assets.json inside project folder. Deleting it and rebuilding the project worked.
I had deleted the obj folder and rerun the build after choosing the target framework required in the property window it worked for me.
I up-voted Larissa but I thought it might be helpful to know how I got into this. I added a .net standard project file to my build (we target lots of platforms) and it produced the debris found in the obj folder. When the android sanity build came around, it threw up on the obj folder. My solution was to clean that folder out as a pre-build step. This is a difficult problem because it was working just fine for years...needle meet haystack.
For my case, delete the .pkgrefgen/ folder under the project folder works, it contains a file project.assets.json that refer to old .net framework
I ran into the same thing with .net 4.71. In my case, I simply migrated from packages.config to "package references" per
Migrate from packages.config to PackageReference
... and it fixed my issue. For me, I was going to do this anyway, so if you're going this way already, I'd just skip the above and migrate to package references.
Renaming the project solved the error for me. The issue happened after I created .NET Core project, then I deleted it and created a .NET Standard one with the same name. Obj folder was not present at all. Deleting bin folder, packages, clean and rebuild solution and getting latest with override did not help.
I have not tried this, but this thread proposed workaround is to include into csproj tag:
<ResolveNuGetPackages>false</ResolveNuGetPackages>
I am using a very old .NET project, and it was working fine until it stopped all of a sudden. Upgrading Visual Studio fixed for me thou.
On VS2019 I had to follow the error message and edit the project.json file that was in the project directory.
was ".NETFramework,Version=v4.0": {} // whatever the copied project was set to
now ".NETFramework,Version=v4.7.2": {} // set to whatever the current build is set to
Problem: In VS2017. Missing reference to .netframework 4.5.2, even though it was referenced as the target framework.
My solution: Verified framework was installed and restarted machine. After a git clean and simply right clicking on the solution in the explore and 'Restore nuget packages' did the trick.
For whatever reason, I got this build error in VS2022.
The same build in VS2019 was successful.
I had the same issue in CI/CD process, when i had upgraded .net framework version from 4.6.1 to 4.7.2 which worked fine locally without any other modification.
However, the jenkins 'slave' node where the build was actually getting generated had some issue with nuget restore and it was not able to pick the latest build for some reason.
Logged into jenkins slave machine/node (basically the machine which jenkins uses to create the build/artifact), go to deployment path and then try deleting projects old builds along with .nugets folder and trigger CI/CD process again worked for me.
This error also occurs if you have removed an old SDK that provided nuget packages, but it is still referenced in your package sources list under Nuget manager/settings. Remove the nuget package source no longer in use to fix this. Otherwise, Visual studio on building will create the project.assets.json file with a reference to the old sdk and if the path is not there, you get the OP's error.
In my case, I had DevExpress 20.2 in my list which I removed to resolve this issue.
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.
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.