I'm working on an app with several projects in the solution. Project-1 builds fine and Project-2 references it within the same solution. When I open the references to Project-2, I see the Project-1 reference. I can go to the path specified and I see the Project-1 dll there.
When I try to build Project-2, I get the error
The package Project-1 could not be found in C:\Users\[it me]\.nuget\packages.
Run a NuGet package restore to download the package.
Both projects are set to the same architecture (x64), not "Any CPU". Why is Project-2 looking for Project-1 in the nuget packages folder instead of the path specified?
The problem, as it turned out, was a versioning problem. Project-1 had a lower target version than Project-2 (which was targeted for the Windows 10 Anniversary Build 14393). I installed Visual Studio 2015 Update 3, which includes the 14393 APIs, and that resolved the problem.
Related
I have C# application (.NET Framework 4.6.2) with WebApi projects which references System.Runtime.InteropServices.RuntimeInformation (v4.3.0) library through nuget package. See
Nuget package reference screen Package was auto-installed as a dependency of 'Microsoft.CodeAnalysis.Razor.2.2.0, Microsoft.DotNet.PlatformAbstractions.2.1.0'
This application was working fine (Builds from my localhost are ok) until I tried to do automatic builds from my teamcity server (different machine). For some reason builds of my app which are provided by teamcity will not start. I get error Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0...'
So I started to investigate and I found out this:
Builds from my localhost (bin/debug) contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.26011.1, Date modified=10.8.2021) --this build works fine
Teamcity build contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016) --this build is not working
Nuget package which was downloaded (..\packages\System.Runtime.InteropServices.RuntimeInformation.4.3.0) on both machines (localhost and teamcity server) contains System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016)
And now I am stuck and literally dont know how to investigate it further. Questions I am asking myself:
How is it possible that my localhost builds contains this reference lib with file version 4.6.26011.1 when in my \packages\ folder this .dll contains file version 4.6.24705.1? Does msbuild maybe take this reference from different location? But from where? I swear I searched my computer and I did not found this library in version 4.6.26011.1 (which is apparently copied to bin/debug by msbuild).
Is there a way to monitor msbuild process and see from where it copies this .dll reference to my bin/debug/ folder on my localhost machine?
How to fix my references so the app runs fine?
21.6.2022 Edit:
Thanks to #mu88 comment I have managed to find out that this library is copied from this location: "C:\Program Files\JetBrains\JetBrains Rider 2021.2.2\tools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net462\lib\System.Runtime.InteropServices.RuntimeInformation.dll" to my bin\debug. I have zero ideas why msbuild is using this path for this lib. (This is only library which is copied from this path)
--Additional info: I am using some AspNetCore references (e.g Kestrel, ..) so I am targeting .Net Standard 2.0. Could this relate? I am asking because my investigation lead to this issue: ms-build-extensions-file-corrupt-my-bin-web-api-folder. In this issue I have found other links to people having similiar problems like this. I just dont understand the solution there :(
So I managed to solve my problem. I had to install .NET SDK to Visual Studio Build Tools 2019 via Visual Studio Installer. Which done "some" magic and it created *MSBuild\Microsoft\Microsoft.NET.Build.Extensions* folder to my msbuild and now during the build process some System libraries are "overidden" and copied from this new location.
So even if I use nuget to download System lib then this package is not used during the build.
I did not manage to find any more info about the build process :( It would be nice if someone could explain this to me. I created a separate question for this here: What is Microsoft.NET.Build.Extensions and how does it work?.
I have a multi-project solution with Prism Nuget packages installed in several projects. I then attempted to add a Prism Mef extensions package to one of the projects using the Nuget Package Manager UI (I have already added it to one of the other projects).
The first time I attempted to add the package, it failed to install one of the dependencies, no specific error reason, just "failed". So, I installed it a second time, all seemed to be fine, no errors reported, but a few of the references did not resolve.
So, I uninstalled the package and all dependencies and installed it again. Again all appeared fine, but more references do not resolve.
I have tried uninstalling and installing the package more times but get the same result every time now.
I have had this problem many times and I know its not specific to the Prism package as I've had it with loads of different packages.
I think its just a major bug with Nuget, but I'm hoping somebody will know an easy way to fix it. I think I usually have better success with the Nuget console, but I find it more effort to use.
I've done some searching online and not really found a good explanation of the cause of the problem or a way to resolve it.
Somebody at work completely refuses to have anything to do with Nuget as he has so many of these issues, but I am determined to make it work!
Within the Package Manager Console run the following command:
Update-Package -reinstall
This will reinstall each nuget package within that project which should resolve any missing references.
If you know you're missing a specific reference:
Update-Package -reinstall <Package-Name>
I just closed Visual Studio and reopened it and references are resolved...!
You need to follow this procedure.
1. Update-Package -reinstall
2. Restart visual studio.
You may want to check the .NET version of the package vs. your project.
I had an instance where my project was .NET 4.6.1, and the package I was attempting to install was using version 4.6.2. After updating my project to the same .NET version, the reference showed up.
I recently encountered this error on visual studio 2012, solution for me was to delete .nupkg file from nuget cache. Nuget cache location can be found from nuget settings > general > browse.
Note: I did not clear cache, I just deleted a specific file from cache directory and reinstalled the nuget package.
Delete all the <assemblyBinding> references from your .config file, then run this command from the Nuget Package Manager:
Get-Project -All | Add-BindingRedirect
This is how I fixed it.
I was working on a legacy .NET framework project (using <Reference Include... rather than PackageReference). The .dlls were referenced with a relative path that wasn't being resolved.
Fixed by changing to absolute paths, building, then changing back to the original relative paths.
For example:
<Reference Include="My.Package">
<HintPath>..\..\packages\My.Package.dll</HintPath>
</Reference>
Changed to:
<Reference Include="My.Package">
<HintPath>C:\Users\will\Documents\MySolution\packages\My.Package.dll</HintPath>
</Reference>
Then built and changed back to the relative path and the build still worked.
In our case, on one machine VS was holding onto an old version of a dependency, so references to newly added methods in the dependency were not resolving (even when package manager was reporting the latest version installed). The solution was to restart visual after uninstalling the dependency, then install again.
I'm helping a colleague who cannot get a Visual Studio WPF project to build in our TFS 2015 build server. I've pulled (get latest) the latest version of his code into my VS 2019 instance. I can't get it to build on my dev box. When I try to build the solution on my dev box I get errors like thing:
The tag 'ModernDialog' does not exist in XML namespace 'http://firstfloorsoftware.com/ModernUI'.
The tag 'Interaction.Triggers' does not exist in XML namespace 'http://schemas.microsoft.com/expression/2010/interactivity'.
When my colleague checks in changes into TFS, it fails with errors like this:
Unable to find version '5.2.0' of package 'MvvmLightLibs'.
Unable to find version '1.0.9' of package 'ModernUI.WPF'.
I started by trying to update the NuGet packages he had in the project, but that hasn't worked well. Even restoring back to the latest version doesn't build on my machine.
My colleague's approach is to rip all NuGet packages out of the Visual Studio solution, then look around to find the DLLs, then put them into the project and reference them in the project. It does build on his system but doesn't on the TFS build server.
So, I've been looking around for probable causes. I came across this Microsoft document Migrate from packages.config to PackageReference. I'm not familiar with either packages.config or PackageReference, but I get the feeling that PackageReference is the "preferred" way of including NuGet packages.
This raises problems. Currently our TFS build server's highest version of Visual Studio is VS 2015. According to the referenced article, VS 2015 uses packages.config files. Anything newer than VS 2015 uses Packages (PackageReference I presume).
I've compared the failing WPF solution with another one I've worked on which builds fine on the build server. The solution that builds, I'll call it SolutionA, has a packages folder at the root of the solution, but it also has packages.config files in each project in the solution. The solution that fails to build, I'll call it SolutionB, has the packages folder at its root, and one packages.config file in the unit test project. (I think the unit project builds fine.)
Even though we're working with newer versions of Visual Studio, I suspect that the problem the build server is having is due to the build server having an older version of Visual Studio. We have a limited number of licenses for Visual Studio, so I can't put a newer version of Visual Studio on the build server. So, how do I get those packages.config files into each projects?
First, your solution actually uses packages.config nuget management format. And this format makes every project has a file called packages.config which lists all the nuget packages and their versions. That is the feature of packages.config nuget management format. So you should also make sure that you have commit that file into TFS.
Second, that migrate packages.config into PackageReference is not an easy work and it should be done with VS IDE. Mostly, you have to make a big change to every csproj file of the project. Actually, PackageReference is flexible and lightweight, it does not have the packages.config file and packages folder which stores all the nuget packages. Just embed them directly in proj file. And so far, PackageReference is the mainstream.
Your problem is that you did not do a nuget restore operation on TFS build to make the missing nuget packages under the packages folder so that build process will find those nuget packages and make them work.
You should add a nuget restore xxx\sln command line or task.
Please check one,two,three.
I have a project that i cannot compile. When i try to do so I get the following error:
The 'Microsoft.Bcl.Build 1.0.14' package requires NuGet client version '2.8.1' or above, but the current NuGet version is '2.7.41115.310'.
Normally this would be simple. After searching I found this guide:
http://www.daimto.com/package-requires-nuget-client-version-x/
That explains how I can upgrade my Nuget client version. However, when i follow those steps, I find that I am already using the latest version of Nuget: 2.8.5
For some reason however, Visual Studio 2013 Ultimate is using an older version, and I don't understand why.
My install of Visual Studio Ultimate 2013 is a fresh install, after unninstalling Visual Studio for Web Express 2012. The previous version was giving me a considerable amount of problems and so I deleted it and moved on to 2013. I wonder if some cofig files were passed through, but I cant be sure.
How can I fix this problem?
From Tools → Extensions and Updates → Installed, uninstall “NuGet Package Manager” and install it again.
So, after searching around I found no answers, so I decided to look into the project folders. It happens that I have the main version of NuGet.exe, 2.8.5 in main folder, but the project was nowhere near that main folder.
This way, when I downloaded the project it simply used the NuGet version pulled from TFS (or so I assume), and that was the problem - that verison was Nuget.exe 2.7.4.
After replacing the "Nuget.exe" files (found in /.nuget folder of the project) the project finally compiled and everythign started working again.
You can also try update Nuget Package Manager directly from Tools > Extensions and Updates
In my case, a pending update of Visual Studio fixed the nuget version.
The update was the "Update 5" for VisualStudio 2013.
The update was listed under the menu Tools → Extensions and Updates, on the tab Updates.
I was getting this error from a recently cloned branch, but (in contrast to the above solution) found that my Nuget version in the project directory was the same as that in my solution directory.
I solved this by right clicking on the solution and Managing Nuget Packages for the solution. The Nuget dialog that popped up said that packages were missing and asked me to restore them. Once downloaded, the project built successfully.
I had the same issue when trying to install System.Net.Http and it said the nuget version needed to be version 3.0 or above. I tried few things but in the end, used Tools and Manage Nuget Packages and did a search and tried to install it from there when it said exactly the same thing - wrong version of nuget, but it popped up with an upgrade Nuget button too!
Hope this helps someone
Simply reinstall nuget in visual studio
I am writing a Windows Phone app, at the beggining using VS 2010 Express for windows phone. Then I installed VS 2012 and i made a desktop app which consumed JSON/REST service using RestSharp. Due to lack of support for plugins in Express version, i got full VS 2010 Ultimate and installed Nuget. When I create a win phone library project, and i add a RestSharp package, it shows in References, but i cannot access any of it's classes (and using RestSharp is underlined in red color). Also, when i Remove it and add again from Add Reference i get an Incompatible reference error window:
RestSharp.WindowsPhone, Version=103.2.0.0, Culture=neutral, PublicKeyToken=null" is incompatible with
Windows Phone 7.1
In order to add it yourself you should to change the project's terget to a compatible framework first.
It also appears if i change the target to WP 7.0.
Has anyone solved similar problem?
In my case this was because there was a packages.config file in the project folder but not in the solution. This was why I could not add the reference again properly. Delete this file from the physical disk, and re-run your Install-Package command. It should add this correctly now.
Are you using source control?
The it might be possible that you have not yet set the solution to enable package restore (NuGet documentation).
Right click on the Solution node in Solution Explorer and select
Enable NuGet Package Restore.
After that Solution Explorer will contain a few items more and there will be a new folder packages that was automatically added to your solution folder. You will need this folder to add to your version control because it will contain your installed NuGet packages.
That's it.
If you want to know more, here's more details on what it (automatically) does for you:
It added a solution folder named .nuget containing NuGet.exe and a
NuGet.targets MsBuild file. It also changed every project in the
solution to import the NuGet.targets MsBuild task.
With this in place, any time a project is compiled, the build task
will look at each project's packages.config file and for each package
in that file, ensure that the corresponding package exists within the
packages folder. For any missing package, the build task will download
and unpack the package.
In the restore scenario, NuGet will grab the exact version when
restoring a package. It will not perform any upgrades.
Additionally, if you have the latest NuGet version installed, will now find a new option unter Tools -> Options... -> Package Manager -> General -> Allow NuGet to download missing packages during build that I would also suggest to use.
The name says it all. If the solution is configured to use a certain NuGet package but the package is not yet installed on your development machine, NuGet will download it automatically for you when you do your next build.