Issue with Nuget package versions in .NET Core - c#

Net core application. I have created some class library project named Authorization and it has reference to
<PackageReference Include="Microsoft.Identity.Web" Version="1.10.0" />
Then I have another class library project and I have reference to
<PackageReference Include="Azure.Identity" Version="1.2.3" />
Both these class library applications I have pushed to azure artifact and I am using it in current application. when I try to build the solution Its giving me below error
RepositoryLayer.csproj :
error NU1605: Detected package downgrade: Azure.Identity from 1.3.0 to 1.2.3. Reference the package directly from the project to select a different version.
RepositoryLayer.csproj :
error NU1605: RepositoryLayer -> Consume 1.1.46955 -> HttpClients 1.1.46955 ->
Authorisation 1.1.46955 -> Microsoft.Identity.Web 1.10.0 -> Azure.Identity (>= 1.3.0)
RepositoryLayer.csproj :
error NU1605: RepositoryLayer -> Azure.Identity (>= 1.2.3)
already spent hours to identify this but could not able to understand the root cause. Can someone help me to identify this issue. Any help would be appreciated. Thanks

3 steps:
(1) Use latest version
https://www.nuget.org/packages/Azure.Identity (1.4.0)
https://www.nuget.org/packages/Microsoft.Identity.Web (1.12.0)
(You should use .NET 5 SDK 5.0.6 with Azure.Identity 1.4.0 and Microsoft.Identity.Web 1.12.0 for ensuring compatibible)
(2) Clean Nuget cache, then get nuget package again.
https://learn.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders#clearing-local-folders
You can/should delete all old thing inside the folder packages for clear all old stuff. I want make sure no corrupt files existing.
(3) Delete bin, obj, re-build project.
Let's share your result.

Related

Nuget package installed but cannot be imported

I am trying to add a nuget package "Azure.ResourceManager" to an existing project.
Here is the .csproj file:-
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="Azure.Identity" Version="1.6.0" />
<PackageReference Include="Azure.ResourceManager" Version="1.0.0" />
<PackageReference Include="Azure.ResourceManager.Resources" Version="1.0.0" />
....
</ItemGroup>
</Project>
I ran the nuget restore command on the solution, and I have checked that the package is installed through the Visual Studio Package Manager Console, using command
PM> Find-Package ResourceManager
Id Versions Descriptio
n
-- -------- ----------
Azure.ResourceManager {1.0.0} Azure m...
Azure.ResourceManager.Communication {1.0.0} Azure m...
Azure.ResourceManager.Deployment... {1.0.111} This pr...
Azure.ResourceManager.Deployment... {1.0.111} This pa...
However, when I try to import this package into a class, the type cannot be resolved.
I wondered if the package and project targeted different versions, so I checked.
Target frameworks supported by package
Target framework supported by project
In summary,
As far as I can tell, both project and package support .Net Core 3.1 as a target framework.
Package is installed into project, but cannot be imported into class
Another thing I noticed is that the type "ResourceManager" is being searched for in the "Microsoft.Azure" namespace instead of "Azure"
Looking for any pointers to resolve the issue.
I learnt that the issue was happening because of naming conflicts within the namespace that I was trying to add the import in. There seems to have been another namespace "Azure." within the one I was adding code to. Adding a glocal prefix helped resolve the issue.
using global::Azure.ResourceManager;
This seems like a bug. I just created a solution with a .NET core 3.1 project inside. I used the Nuget Manager ui and it worked fine. Have you tried installing it that way?

Ignore inaccessible sources w/ dotnet add package

When I try to add a NuGet package via the dotnet cli I get an error that it can't access one of my custom NuGet sources. Is there a way to say "I don't care, restore from where you can"?
McMaster.Extensions.CommandLineUtils clearly it exists in NuGet.org and it finds it but then stops b/c it can't access a custom source 🤷‍♂️.
PS c:\Temp\blah-project> dotnet add package McMaster.Extensions.CommandLineUtils
info : Adding PackageReference for package 'McMaster.Extensions.CommandLineUtils' into project 'c:\Temp\blah-project\blah-project.csproj'.
info : Restoring packages for c:\Temp\blah-project\blah-project.csproj
info : GET https://api.nuget.org/v3-flatcontainer/mcmaster.extensions.commandlineutils/index.json
info : OK https://api.nuget.org/v3-flatcontainer/mcmaster.extensions.commandlineutils/index.json 147ms
error: Unable to load the service index for source https://myinstace.pkgs.visualstudio.com/_packaging/Blah/nuget/v3/index.json.
error: Response status code does not indicate success: 401 (Unauthorized).
The dotnet command has the option to specify --source. This allows you to only restore packages from a specific location, in this case you'd want to use
dotnet restore --source https://api.nuget.org/v3/index.json`
This should pull the packages down to your local NuGet store and solve the problem on your machine.
In order to add the package to your project you may need to manually add a <PackageReference> to your project like
<PackageReference Include="McMaster.Extensions.CommandLineUtils" Version="2.6.0" />
Then running the restore command above will get the package for you.
As a more-permanent fix, you should put a nuget.config file in the root of the project/repository where you specify the package sources for that specific project. There are settings that you can set to override your system's global nuget configuration/sources. See more information on nuget.config. You can create a starting nuget.config in your repo with dotnet new nugetconfig
while restoring packages, dotnet make a call to all the package sources to get the package and uses the one that responds first.
In your case, because of some authentication issue it is not able to access that source. That source can be disabled using the below command and then try to pull the package.
dotnet nuget disable source <NAME> [--configfile <FILE>]
You might be able use the --ignore-failed-sources option.
I'd recently encountered similar issues when having authentication problems on a private feed, this allowed me to install the packages (was actually a tool using dotnet tool install) and address my auth issue at a later date.
See https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-restore for more info and options.

"The project 'Web' must provide a value for Configuration" error after migrating to .NET Core 3

I've migrated an ASP.NET Core 2.2 project to Core 3.0 and am getting the error:
The project [Project location] must provide a value for Configuration.
There's not really a lot to go on with that error message, does anyone know how to resolve this error?
This looks like it could be similar to this issue on the dotnet cli github repo.
The issue turned out to be that I was still referencing Microsoft.AspNetCore.Razor.Design Version="2.2.0" in the .proj file's package references. Deleting that reference (which isn't needed at all as Razor.Design is now part of AspNetCore library) fixed the issue.
Once I'd done that, I then got hundreds of errors about nullable objects being a new feature not compatible with razor. That was because I had <LangVersion>Latest</LangVersion> in my .proj file. Removing that line fixed that issue and got the project running again.
(In some cases you might need to clean and rebuild and/or restart VS too, according to comments on the github thread)
If that doesn't solve it, it's possible that one the NuGet packages used by your project is the cause. Try removing the dependencies to see if that clears the issue, and then re-add them one at a time to work out which NuGet package is the cause.
There is an MS document title "Migrate from ASP.NET Core 2.2 to 3.0". Under "Update the project file", it states,
"A large number of NuGet packages aren't produced for ASP.NET Core
3.0. Such package references should be removed from your project file"
The two given as an example are:
Microsoft.AspNetCore.App
Microsoft.AspNetCore.Razor.Design
Below that, you can expand to see all the packages that are no longer being produced:
Microsoft.AspNetCore
Microsoft.AspNetCore.All
Microsoft.AspNetCore.App
Microsoft.AspNetCore.Antiforgery
Microsoft.AspNetCore.Authentication
Microsoft.AspNetCore.Authentication.Abstractions
Microsoft.AspNetCore.Authentication.Cookies
Microsoft.AspNetCore.Authentication.Core
Microsoft.AspNetCore.Authentication.OAuth
Microsoft.AspNetCore.Authorization.Policy
Microsoft.AspNetCore.CookiePolicy
Microsoft.AspNetCore.Cors
Microsoft.AspNetCore.Diagnostics
Microsoft.AspNetCore.Diagnostics.HealthChecks
Microsoft.AspNetCore.HostFiltering
Microsoft.AspNetCore.Hosting
Microsoft.AspNetCore.Hosting.Abstractions
Microsoft.AspNetCore.Hosting.Server.Abstractions
Microsoft.AspNetCore.Http
Microsoft.AspNetCore.Http.Abstractions
Microsoft.AspNetCore.Http.Connections
Microsoft.AspNetCore.Http.Extensions
Microsoft.AspNetCore.HttpOverrides
Microsoft.AspNetCore.HttpsPolicy
Microsoft.AspNetCore.Identity
Microsoft.AspNetCore.Localization
Microsoft.AspNetCore.Localization.Routing
Microsoft.AspNetCore.Mvc
Microsoft.AspNetCore.Mvc.Abstractions
Microsoft.AspNetCore.Mvc.Analyzers
Microsoft.AspNetCore.Mvc.ApiExplorer
Microsoft.AspNetCore.Mvc.Api.Analyzers
Microsoft.AspNetCore.Mvc.Core
Microsoft.AspNetCore.Mvc.Cors
Microsoft.AspNetCore.Mvc.DataAnnotations
Microsoft.AspNetCore.Mvc.Formatters.Json
Microsoft.AspNetCore.Mvc.Formatters.Xml
Microsoft.AspNetCore.Mvc.Localization
Microsoft.AspNetCore.Mvc.Razor
Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
Microsoft.AspNetCore.Mvc.RazorPages
Microsoft.AspNetCore.Mvc.TagHelpers
Microsoft.AspNetCore.Mvc.ViewFeatures
Microsoft.AspNetCore.Razor
Microsoft.AspNetCore.Razor.Runtime
Microsoft.AspNetCore.Razor.Design
Microsoft.AspNetCore.ResponseCaching
Microsoft.AspNetCore.ResponseCaching.Abstractions
Microsoft.AspNetCore.ResponseCompression
Microsoft.AspNetCore.Rewrite
Microsoft.AspNetCore.Routing
Microsoft.AspNetCore.Routing.Abstractions
Microsoft.AspNetCore.Server.HttpSys
Microsoft.AspNetCore.Server.IIS
Microsoft.AspNetCore.Server.IISIntegration
Microsoft.AspNetCore.Server.Kestrel
Microsoft.AspNetCore.Server.Kestrel.Core
Microsoft.AspNetCore.Server.Kestrel.Https
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions
Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets
Microsoft.AspNetCore.Session
Microsoft.AspNetCore.SignalR
Microsoft.AspNetCore.SignalR.Core
Microsoft.AspNetCore.StaticFiles
Microsoft.AspNetCore.WebSockets
Microsoft.AspNetCore.WebUtilities
Microsoft.Net.Http.Headers
I've had the same issue and it was solved by removing the following references:
"Microsoft.AspNetCore.Mvc" Version="2.2.0"
"Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="2.2.0"
This is kind of weird.
For me, the problem was because of 'Microsoft.AspNetCore.Mvc' package.
I uninstalled it and installed 'Microsoft.AspNetCore.Mvc.Core'.
I need to add that, I had installed 'Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation' too.

Developing NuGet packages without pushing to NuGet server

I have 2 solutions in VS.
The first one is for packages.
Packages.sln
- PackageA
- PackageB
- Package..
Each packages has <GeneratePackageOnBuild>true</GeneratePackageOnBuild> to generate Package.nupkg.
And solution with services where I'm going to use that packages
Services.sln
- ServiceA
- ServiceB
- Service..
The question is how can I during development change package and use it in service?
I've tried this:
Create Local NuGet source in some folder "artifacts"
Each package has it in .csproj
:
<Target Name="PostBuild" AfterTargets="GenerateNuspec" Condition="$(Configuration) == 'Debug' ">
<Exec Command="nuget.exe push bin\Debug\*.nupkg -Source "Local Package source"" />
</Target>
Then I need to change version of package, let's say <VersionPrefix>1.0.1</VersionPrefix>
Then in service change to <PackageReference Include="PackageA" Version="1.0.*" />
So, make change in package, build, remove package from nugget cache, rebuild service, test, if ok then commit and CI will push it to nuget server. There are many steps to test package. Please suggest what workflow should I use when I develop packages and want to test it before pushing to Nuget server.

ServiceStack 3.9.* to 4.*

I am trying to change ServiceStack in my service from 3.9.43 to 4.0.9.
I had to change several things in my code and mostly followed the release notes for this.
There were a couple of weird things for me, like not finding anything to replace ServiceStack.WebHost.Endpoints or AppHostHttpListenerLongRunningBase but I could check those things after and was able to make my code to compile.
The problem is that when I run my code I get this exception in the very begining and it just kills the service:
Method 'ExecuteMessage' in type 'ServiceStack.Host.ServiceController' from assembly 'ServiceStack, Version=4.0.9.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
I get this when hitting the base:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ServiceStack;
using ServiceStack.Text;
//using ServiceStack.WebHost.Endpoints;
using ServiceStack.Web;
namespace ThisService {
public class AppHost : AppHostHttpListenerPoolBase { //AppHostHttpListenerLongRunningBase {
public AppHost(int wthreadMax)
: base("This Service " + VcsInfo.ChangesetId, wthreadMax, typeof(ThisService).Assembly) {
}
...
I am referencing in my project:
ServiceStack (4.0.9.0);
ServiceStack.Client;
ServiceStack.Common;
ServiceStack.Interfaces;
ServiceStack.Text
I am sure I am doing something wrong changing to version 4.* and am lost with what is trying to call the Execute Message since I think removed everything from the previous version. Any suggestion to where I should be looking to?
By the way, this a simple service: get json -> math + stuff -> return json.
I want to find out if a bug I found the version 3.9.43 still happens in version 4.0.9 (can't find anything specific about that bug but I believe one fix there is related) to see if I should actually re-factor my code for this version.
Update in v4.10
This should now be resolved in ServiceStack v4.10 where now all NuGet packages specify a minimum version for all dependencies matching the current version. This will force NuGet to pull down the latest packages instead of the oldest matching ones.
NuGet seems to have the weird behavior that it will pull in the lowest dependencies when you install a package, so if you install the latest version of ServiceStack, e.g:
PM> Install-Package ServiceStack -Version 4.0.9
It will pull in the lowest matching dependenices, e.g:
<package id="ServiceStack.Client" version="4.0.3" targetFramework="net45" />
<package id="ServiceStack.Common" version="4.0.3" targetFramework="net45" />
<package id="ServiceStack.Interfaces" version="4.0.3" targetFramework="net45" />
<package id="ServiceStack.Text" version="4.0.3" targetFramework="net45" />
Which is an unexpected surprise. Unfortunately ServiceStack assumes that it's always working with the latest dependencies with the same version it was built with.
So after installing ServiceStack you will need to update all your packages which will bring them in-line with the latest versions, which you can easily do in the Updates tab in the NuGet UI, or in the NuGet Package Console Manager with:
PM> Update-Package
Manually remove any assembly redirects
Installing the previous v4.02 of ServiceStack (now removed) created new assembly redirects for ServiceStack.Interfaces in the Web.config which you should also manually remove if they exist. These now shouldn't be created for new projects.
I had the same problem as well. Therefore I tried installing an older v4 version from Nuget and managed to make it work.
Using Scott's example I can get this to work correctly if I install 4.0.4:
install-package servicestack -Version 4.0.4
If I use version 4.0.5 then it runs but the example web page reports
Method not found: 'Void ServiceStack.Web.IResponse.set_Dto(System.Object)
If I use version 4.0.6 or above then I get the error reported by RGPT.
So, for now it may be a case of using the 4.0.4 version until someone with more knowledge than me replies with a better answer. I've only just starting using ServiceStack today so I don't know much yet ;)
Update: I don't have high enough ServiceStack reputation to post a comment so felt best to edit my original post. The answer below by mythz had the key bit of information. Immediately update your nuget packages after installing and then check the web/config / app.config to see if any dependentAssembly bindingRedirects are hanging around - if so then remove them and away you go :)
I've had a similar problem as well. I followed the upgrade path, first via the Beta channel before upgrading to the offical channel. What I soon realised was that the Beta libraries had version numbers greater than the official channel.
NuGet will check for a more up-to-date version locally first, before pulling in the libraries remotely. Of course, it will pull in ServiceStack v4.0.x from the official channel, but all the dependencies will come from the already downloaded Beta (i.e. locally).
What I did to resolve it:
Uninstall all ServiceStack dependencies from the Solution via NuGet
Deleted the Solution's Nuget '/packages' folder, and to re-import it using NuGet package restore
Re-added the ServiceStack references via NuGet, and checked the 'packages.config' for correct versions

Categories