I have freshly install and update VS Community version 16.10.0 in a freshly installed Windows 10.
Now I have created a small console app and added a unit test project both in .Net Core 3.1 LTS. After that nothing else is done. What I see is that nuget packages for test project is not properly installed although when you check in the nuget package manager, all the package are installed, all of those are installed.
Then I open an old application but the issue is same. Unit test packages are showing with error and same for EF core.
I tried to tweak/build etc. but non fixed the issue.
The issue was due to missing nuget source link in Package Source under NuGet Package Manager.
As soon as I added the package source everything stated to work.
https://api.nuget.org/v3/index.json
The above source link suppose to already be added by default in Package Source but for some unknown reason it was missing. So whatever packages needed such as EFCore and MS Test framework etc. could not be downloaded, hence the problem was.
Related
I am getting an "unable to find package Microsoft.NETCore.App.Runtime.browser-wasm" error when trying to Build an AspNetCore 5.0.0 Blazor Wasm app using VS Community 2019 v16.8.3. I haven't tried to Build this app since early December, but it worked then. I get the same error when I try to Build older backup copies of the app too.
I have in recent days created a new AspNetCore 3.2.1 Blazor Wasm app using the same VS. It Builds and runs successfully.
A search for this error indicates this package is not meant for direct consumption and I can't find anything else that's helpful.
Any idea how to get out of this?
The solution #rdmptn wrote as a comment worked for me. After upgrading VS I needed to add nuget.org to my list of Package Sources in the NuGet Package Manager options then rebuild the solution.
This must be a bug of the NuGet Package Manager I'm using (version 4.6.0). I used the option DependencyVersion highest but it always picks the lowest version for dependencies.
Like this (I'm trying to install Serilog.AspNetCore with dependencies of 2.2.0 - the latest but 2.0.0 is always picked).
install-package Serilog.AspNetCore -DependencyVersion highest
One dependency it picks is Microsoft.AspNetCore.Http.Abstractions 2.0.0 but I expected it to pick Microsoft.AspNetCore.Http.Abstractions 2.2.0.
It's important because in my project the version 2.2.0 is required, Serilog should adapt that requirement by installing with that correct version of dependencies. But here I could not do anything to help it understand what I want.
Also the Install and Update options are not shown in the UI of NuGet Package Manager (the DependencyVersion could be selected there as well when using UI to install packages). So this appears to be some bug at least in the specific version of Nuget package manager I'm using.
What could I do to solve this issue? Can I try fixing the installed nuget manager (there is not any update in the Updates window). Thanks!
UPDATE
I've just tried a traditional .NET project, it works. But the problem raised when my projects target .NET Core (ASP.NET Core)? Looks like it does not support that feature for .NET Core projects?
The DependencyVersion switch is something used to control the behavior when NuGet looks for patch versions. It seems to be introduced after NuGet 2.8, but one point we should know is this option only supports packages.config format.
There are two package management formats:Projects.config and PackageReference.
1.For traditional .net project:It can use Packages.config or PackageReference to manage its nuget packages.But by default it uses packages.config.
2.For .net core projects(which uses new SDK-format project file):It uses new PackageReference format as its Package Management format.
More details about it see: Project Type Support
And someone had post this feature request in github, see the issue here.Hope it helps.
Update:
I expected it to pick Microsoft.AspNetCore.Http.Abstractions 2.2.0
Trying deleting the bin and obj folder first,
Then go Tools menu=>Nuget Package Manager=>Package Manager Settings=>Clear All Nuget Caches.(Sometimes it will delete the packages folder in C:\Users\lancel\.nuget\packages, we need to manually create a new packages folder)
Then install the Microsoft.AspNetCore.Http.Abstractions 2.2.0 package separately before installing the Serilog.AspNetCore package. Builds the application and you can check the output .dll by setting the CopyLocalLockFileAssemblies. In my machine it references 2.2.0 version of Microsoft.AspNetCore.Http.Abstractions.dll successfully. Hope it helps:)
I created a new .NET core Web App and I am trying to add packages Microsoft.EntityframeworkCore and Microsoft.AspNetCore and I am getting the error:
package restore failed rolling back packages
I have tried clearing the NuGet Caches reinstalling VS 2017 and the problem persists, note the project is brand new.
Please make sure your VS 2017 already upgraded to 15.3.5, you can re-run the VS 2017 installer as administrator and if there has the ‘Update’ button, click it to update. Then check you also installed the latest .NET Core 2.0 SDK and then create a new ASP.NET core web application, choose ‘ASP.NET Core 2.0’ as below to create:
Then you can successfully install those 2 packages through Manage Nuget Packages like the following:
I am using Visual Studio 2015 (Pre), Framework 4.5.2
I have the folowing project structure
StorageProject
nuget package Microsoft.WidowsAzure.Storage is installed
This Nuget package has (among others) dependencies on Microsoft.Data.OData, wich is also installed
AnotherProject
Has a refernce on StorageProject
Does not have any nuget package or other refernces (except default references on the framework)
Here is the list of the packages installed in StorageProject
WindowsAzure.Storage 4.3.0
Microsoft.WindowsAzure.ConfigurationManager 3.1.0
System.Spatial 4.3.0
Microsoft.Data.Edm 5.6.4
Microsoft.Data.OData 5.6.4
Microsoft.Data.Services.Client 5.6.4
These are all dependencies of WindowsAzure.Storage, latest versions.
There is no other version of these packages installed anywhere on the solution.
I will focus on Microsoft.Data.OData, but the same problem occurs with Microsoft.Data.Edm and Microsoft.Data.Services.Client 5.6.4
When building StorageProject, the correct version of these dll (5.6.4) ends up in the bin folder of the project.
But when building AnotherProject, the bin folder contains version 5.6.2 of the dll.
Now I passed all day trying to figure out where these dlls come from.
There is a version 5.0.0.0 in the GAC, wich I cannot uninstall. (gacutil yields it is used by something).
I did a file search on C:\ to find that the only place where this version of the dll is (beside the bin folder of my project) is in C:\Program Files (x86)\Microsoft WCF Data Services\5.6.2. If I delete (move) this folder, my project builds "normally" and everything is fine. In fact, in this case OData is not in the bin folder at all. And as far as I am concerned, that's ok this way.
Now the real question(s) :
Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
Can I uninstall it? I don't see it in Windows' control panel.
•Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
This could be due to the fact that the storage client does not depend on a specific version of the Data Service Client. Since Specific Version is set to false, the GAC will be searched first during compilation, any version will be considered "acceptable", and no other version will be exported.
•Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
It could be installed due to a variety of reasons. The Azure SDK contains this as well. So if you ever installed the Azure SDK, it could have come with that.
•Can I uninstall it? I don't see it in Windows' control panel.
Looks like this is only possible by uninstalling the MSI package that installed the assembly via Add/Remove programs. For that, you would have to again figure out which installation brought this assembly with it and check whether that is needed or not.
I recently upgraded to TeamCity 9, at first everything was okay. Then, for some unknown reason, I was unable to get a full list of available packages via the NuGet GUI. At first it appeared that all the portable class libraries where missing, then all of them went missing.
What I've tried:
I've removed all old artifacts from TeamCity,
I've deleted and reset TeamCity's cache
I've restarted TeamCity and its NuGet v1 service
I've rebuilt some basic class libries (PCL) with no dependencies.
I've cleared NuGet cache in my Visual Studio options.
I've ran VS as admin.
When I click on my TeamCity Feed in the package manager, it immediately returns no results with a very brief flash of "retrieving result".
Okay so the very odd thing is I can manually list (and install) my packages via the console:
PM> Get-Package -ListAvailable
Id Version Description/Release Notes
-- ------- -------------------------
RobGeoLtd.Core 1.0.2 Core Framework Portable Class Library
RobGeoLtd.Measurement 0.1.36 Defines units of measurement and conversion methods between them
PM> Install-Package RobGeoLtd.Core
Installing 'RobGeoLtd.Core 1.0.2'.
Successfully installed 'RobGeoLtd.Core 1.0.2'.
Adding 'RobGeoLtd.Core 1.0.2' to Logger.
Successfully added 'RobGeoLtd.Core 1.0.2' to Logger.
PM>
So yeah, I'm at a loss. NuGet bug? I'm all up-to-date as far as I can tell. :/
For anyone experiencing a similar issue:
I also tried all of the above. It turned out that my built packages were targeting .NET 4.5.2 and my project was targeting .NET 4.5.
It would appear to be a TeamCity issue. I reverted to a back up of the CI server running 8.1.4 and the old feed items have returned. I will attempt the upgrade again.
Update: Yup, its defiantly the upgrade from 8.1.4 to 9.0.3 that caused it. Will file a bug. https://youtrack.jetbrains.com/issue/TW-40589