Autorest: Method not found: 'Void Microsoft.Rest.ServiceClient`1..ctor(System.Net.Http.DelegatingHandler[])'.

[calvaradocl]

Hi,

I'm developing a WPF application that uses an autorest generated client to communicate with an API. It was working correctly until today (VS2017)

I'm getting the following error:
Method not found: 'Void Microsoft.Rest.ServiceClient`1..ctor(System.Net.Http.DelegatingHandler[])'.

I tried the following:

• Rebuild and Clean the Project
• Run autorest --reset and regenerate the client
• Restart visual studio
• Update to the lastest version of Microsoft.Rest.ClientRuntime (2.3.10)
• Search in my hard drive and erase all old versios of ClientRuntime

None of them worked, I'm just calling the constructor like this (ProjectAPI is the name of my API generated class):
ProjectAPI api = new ProjectAPI (new Uri("http://localhost"));

I searched in the repository but there are no issues related to this, anyone can help?

Thanks a lot.

[fearthecowboy]

Off the top of my head, what .NET framework version? (the Microsoft.Rest.ClientRuntime may only have certain profiles?)

does it build from the cmdline?

I've heard recent issues with VS2017 and some weird package-ref problems...

[calvaradocl]

The target platform is .NET Framework 4.6.1. and yes the client is being build from commandline with the following command:

AutoRest -CodeGenerator CSharp -Modeler Swagger -Input http://localhost:3000/swagger/v1/swagger.json -NameSpace Project.API.Client -OutputDirectory .\Project.API.Client

ClientRuntime was added from NuGet.

I find weird that it was being worked before and stopped working from nowhere.

[calvaradocl]

I'm attaching the stacktrace

   en Project.API.Client.ProjectAPI..ctor(DelegatingHandler[] handlers)
   en Project.API.Client.ProjectAPI..ctor(Uri baseUri, DelegatingHandler[] handlers) en C:\Users\darkfile\Source\repos\Project\Project.API.Client\ProjectAPI.cs:línea 77
   en Project.GUI.App.RegisterIoC() en C:\Users\darkfile\Source\repos\Project.GUI\App.xaml.cs:línea 108
   en Project.GUI.App.OnStartup(StartupEventArgs e) en C:\Users\darkfile\Source\repos\Project.GUI\App.xaml.cs:línea 37
   en System.Windows.Application.<.ctor>b__1_0(Object unused)
   en System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   en System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   en System.Windows.Threading.DispatcherOperation.InvokeImpl()
   en System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
   en MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(Object obj)
   en System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   en System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   en System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   en MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)
   en System.Windows.Threading.DispatcherOperation.Invoke()
   en System.Windows.Threading.Dispatcher.ProcessQueue()
   en System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   en MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   en MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   en System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   en System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   en System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
   en MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   en MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
   en System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   en System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
   en System.Windows.Application.RunDispatcher(Object ignore)
   en System.Windows.Application.RunInternal(Window window)
   en System.Windows.Application.Run(Window window)
   en System.Windows.Application.Run()
   en Project.GUI.App.Main()

[henning-krause]

I'm having the same issue with a similar stack trace.

[dimitertodorov]

Any news on this. I have a client I am trying to use from a Binary Powershell module.
Client compiles and tests fine. But using from Powershell throws:
Connect-GoCloudAccount : Method not found: 'Void Microsoft.Rest.ServiceClient`1.set_HttpClient(System.Net.Http.HttpClient)'.

[calvaradocl]

Currently I'm working with Microsoft.Rest.ServiceClient version 2.3.11 without issues.

[dimitertodorov]

Are you targeting 452? I think that might be my problem.

D
On Wed, May 30, 2018 at 15:56 calvaradocl [e-mail] wrote:

Currently I'm working with Microsoft.Rest.ServiceClient version 2.3.11
without issues.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Azure/autorest/issues/2857#issuecomment-393296808,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABKz0WOf7NUpWFhL6lYr8MMj58cGp-QVks5t3vl5gaJpZM4SP0o4
.

[ibsharma]

Hi, I am having similar issues. I tried using both 2.3.8 and 2.3.11 versions of Microsoft.Rest.ClientRuntime but I still get the same error. I'm targeting 4.6.1 as well and also used the latest AutoRest to generate my classes.
FYI: I can run this locally but when I deploy to my dev server and try running this, I get the above mentioned error.
Any idea how to debug this issue?

[fearthecowboy]

I'm not sure what's different between your local machine and your server.

you should isolate exactly what framework version and assemblies you're loading.

[jfelner]

We are experiencing this issue consuming an internal NuGet package we made using autorest to generate the client. It seems to work fine locally and on OnPrem servers, but throws this error in Azure App Service. NuGet was created using .Net47 with Microsoft.Rest.ClientRuntime v2.3.2 and the solution consuming the NuGet is also using 4.7. Does anyone have any ideas?

[mikanyg]

We have the same issue. Was migrating client generated libraries from .NET Framework 4.6.1 to .NET Standard 2.0 and updating to version 2.3.13 of Microsoft.Rest.ClientRuntime, and now the consuming services all get the above mentioned error. I fixed it in some projects by referencing the latest System.Net.Http nuget package (4.3.3) with proper assembly binding, but in one ASP.NET web app (.NET Framework 4.7) it does not work.

Help appriciated

[fearthecowboy]

@shahabhijeet Have you any idea why some people are having this problem?

[mikanyg]

I found that after adding the client package which was based on .NET Standard 2.0 the error in this issue occurs. If I then add proper assembly bindings using the Visual Studio Warning dialog then the Web App just hangs and never loads.

If I then forcefully downgrade Microsoft.Rest.ClientRuntime from version 2.3.13 to 2.3.12 then everything works as expected.

[fearthecowboy]

Ah, yeah , the hang is a different issue and should be fixed with the next version (2.3.14?) ... .13 had a missing .ConfigureAwait(false) which causes problems when called in an ASPNET process.

[mikanyg]

hmm, sounds like I need to go fix all my client packages to depend on 2.3.12 instead :-/

The magic sauce to remove the error mentioned in this issue would be the following assemblyBinding added to app.config or web.config:
<dependentAssembly><assemblyIdentity name="System.Net.Http" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" /><bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" /> </dependentAssembly>

I think System.Net.Http versioning has been a pain for both Microsoft and developers since it was shipped out of band.

[angeldinev]

Upgraded from 2.3.12 -> 2.3.13 in an ASP.NET MVC project targeting .NET4.7 I've experienced the same "hang" that @fearthecowboy mentioned above. Staying with 2.3.12 for now and hope they'll fix it with 2.3.14.

[fearthecowboy]

@angeldinev -- yeah, sorry about that. There is a missing .ConfigureAwait(false) in .13 that is fixed in .14 ....

[memoryfraction]

tried @mikanyg 's method, the method solved my issue. great

[memoryfraction]

@mikanyg Can I know why below method can fixthe bug?
assemblyBinding added to app.config or web.config:

<dependentAssembly><assemblyIdentity name="System.Net.Http" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" /><bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" /> </dependentAssembly>

[MiYanni]

Issue resolved. Closing.