Skip to content

Cannot access a disposed object: IServiceProvider when outputting to json #4263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
RoelofSpijker opened this issue Feb 11, 2025 · 2 comments · May be fixed by #4358
Open

Cannot access a disposed object: IServiceProvider when outputting to json #4263

RoelofSpijker opened this issue Feb 11, 2025 · 2 comments · May be fixed by #4358

Comments

@RoelofSpijker
Copy link

RoelofSpijker commented Feb 11, 2025

Version

4.104.0 (is the version in the path where func.exe is located)
Azure Functions Core Tools
Core Tools Version: 4.0.6821 Commit hash: N/A +c09a2033faa7ecf51b3773308283af0ca9a99f83 (64-bit)
Function Runtime Version: 4.1036.1.23224

Description

When running func.exe host start --dotnet-isolated-debug --enable-json-output --json-output-file c:\somePath\some-file-json.pid it fails with the following error (with CLI_DEBUG=1):

System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'IServiceProvider'.
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ThrowHelper.ThrowObjectDisposedException()
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.GetService(ServiceIdentifier serviceIdentifier, ServiceProviderEngineScope serviceProviderEngineScope)
   at Microsoft.Extensions.DependencyInjection.ServiceProvider.GetService(Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
   at Azure.Functions.Cli.Actions.HostActions.StartHostAction.RunAsync() in D:\a\_work\1\s\src\Azure.Functions.Cli\Actions\HostActions\StartHostAction.cs:line 437
   at Azure.Functions.Cli.ConsoleApp.RunAsync[T](String[] args, IContainer container) in D:\a\_work\1\s\src\Azure.Functions.Cli\ConsoleApp.cs:line 63

When the file specified exists, it works without issues. It is only when this file does not yet exist that this error occurs.
When not running in debug, so with --dotnet-isolated instead, this works without issues even if the file does not exist.

This is problematic, as the IDE I use (Rider) uses this flag to obtain the PID of the function host worker process, in order to attach the debugger. From what I can tell, the filename is generated semi-randomly by Rider, so I also don't have a workaround of ensuring this file already exists.

Steps to reproduce

  • Have an isolated worker azure function project.
  • Run func.exe host start --dotnet-isolated-debug --enable-json-output --json-output-file c:\somePath\some-file-json.pid when that output file does not exist
@rafaelldi
Copy link

Hello folks! On the Rider side, we create a temporary file, then run this command func.exe host start --pause-on-error --port 7231 --enable-json-output --json-output-file C:\Users\jetbrains\AppData\Local\Temp\Rider-AzureFunctions-IsolatedWorker-json.pid --dotnet-isolated-debug and try to read the process id from that file to attach the debugger. Sometimes the core tools don't write anything to the file. Maybe you know of a proper way to investigate this? Are there any log files to check it? Thank you in advance!

@RoelofSpijker
Copy link
Author

Some additional experimentation shows that the configured working directory seems to impact the issue. By default the working directory is <projectPath>/bin/Debug/net8.0 and in that case the issue occurs and the PID is never written to the file. However, if I change the working directory to just <projectPath> then the PID does get written to the file.
I've also tried to reproduce this issue in a fresh solution, but I am unable to. So there is some combination of factors that causes this to occur. What I've checked with the reproduction solution:

  • Same settings.local.json
  • Same host.json
  • Similar functions (same triggers)
  • Same .NET version (8.0), same workers SDK version, same extensions versions, same toolkit version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants