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
Related
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.
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.
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.
A collegue is trying to install a nuget package into a simple default c# web application. It fails almost instantly.
Is there an argument I can provide to Install-Package <some nuget package> in the Visual Studio Package Manager Console to get some verbose information to help debug why the installation fails?
Error Message:
An error occurred while retrieving package metadata for '' from source 'MyGet'.
Info:
Visual Studio: V2015
NuGet extension: 3.4.4.1321
Nuget package source: MyGet
Sample NuGet.config file found in the root directory of the solution:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="MyGet" value="https://www.myget.org/F/<our package>/api/v2" />
</packageSources>
</configuration>
For myself, I can install the package fine. In fact, we have 5 packages in this MyGet public repo and I just installed 2 of the packages, just then .. when I test this out (again) before I created this SO question.
Anyone have a suggestion, please?
UPDATE
As stated above, this is using the PACKAGE MANAGER CONSOLE, not the CLI.
Using the -verbosity detailed in the PMC this is what happens..
PM> install-package xunit -verbosity detailed
Install-Package : A parameter cannot be found that matches parameter name 'verbosity'.
At line:1 char:23
+ install-package xunit -verbosity detailed
+ ~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Install-Package], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
You could try adding the -Verbose parameter to your PowerShell command.
install-package xunit -verbose
You can also try looking at the $error object to see if that has more information, such as an exception callstack.
$error.Exception.StackTrace
The above may or may not give you more information.
Looks like you are running into http://blog.myget.org/post/2016/02/21/Two-of-my-packages-are-treated-as-one-Help!.aspx. There is a 0.7.0-dev and a 0.7-dev version of the package on the feed, which NuGet treats as the same version.
The solution is to remove one of these two packages.
You can use the -Verbose switch in the PowerShell-enabled Package Manager Console to get more details.
To rule out client-connectivity issues to MyGet, can you try diagnosing client connectivity to the feed?
https://www.myget.org/F/<feedIdentifier>/api/v2
Try using Fiddler to retrieve a specific package from the feed on that user's machine using URL format:
https://www.myget.org/F/<feedIdentifier>/api/v2/package/<packageId>/<packageVersion>
If it is a private feed, you'll need to authenticate your request, e.g. using the pre-authenticated v2 endpoint:
https://www.myget.org/F/<feedId>/auth/<apiKey>/api/v2/package/<packageId>/<packageVersion>
Clearing the NuGet client's HTTP cache may also prove useful if something is corrupt in the cache. You can clear it using the NuGet commandline command:
nuget.exe locals http-cache -clear
If the package is already in local cache, then the NuGet client will resolve it from local cache instead. It may be that the package in local cache is corrupt, in which case you can use the following NuGet commandline command:
nuget.exe locals all -clear
Finally, it may also be worth looking at the nuget.config hierarchy. The most-local nuget.config will inherit config settings from higher up the chain (e.g. machine-wide settings), one of which is the <disabledPackageSources> element. To ensure this one is not acting up here, add the following to your most-local nuget.config and retry:
<disabledPackageSources>
<clear />
</disabledPackageSources>
If none of the above helps you in resolving the issue, feel free to use the nuget commandline (nuget.exe) with -verbosity detailed as it may provide more details, such as the actual HTTP requests being made.
Also, make sure you use the latest versions of the NuGet client tools (available here)
We have a private nuget repository for sharing internal components. For now, we are just using a network share.
I am running into some problems though:
Everything works fine if I use the Package Manager Dialog box -- I can search for my packages, install them, and build.
However, if I use the Package Manager Console command: install-package My.Package (where My.Package is the exact string in the <id> tag of the nuspec file, I get an error indicating the nuget could not find the package.
If I include the version number in install-package: install-package My.Package.1.0.0, then it works from the console.
BUT, our build server fails to download our packages with the same error I get from install-package. (our build server uses package restore)
I have compared my nuspec files with some publicly available packages that work find. The only difference I can find is that our nuget packages are on a network share, but public ones are on a web server.
Is there a behavior difference if you use a network share?
I figured out what the problem was -- it was mostly user error.
I went through my nuget config, and I found this:
<activePackageSource>
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
</activePackageSource>
That setting tells nuget to only search nuget.org, and not our private feed. Had to change it to this:
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
I'm still not sure why it worked before (sometimes) if you included the version number (maybe it had to do with whether the package was already locally cached?? It seems as though it should not have worked at all until I made this change. This fixed it though.