Assembly version issue #648

intrasight · 2021-11-29T15:18:58Z

Hi,

Since Google implied that it's related to assembly resolution, I'm posting a link here to the issue that I reported

googleapis/google-api-dotnet-client#2009

My references:

#r "nuget: Google.Apis, 1.55.0"
#r "nuget: Google.Apis.Core, 1.55.0"
#r "nuget: Google.Apis.Auth, 1.55.0"
#r "nuget: Google.Apis.AnalyticsReporting.v4, 1.55.0"
#r "nuget: Newtonsoft.Json, 13.0.1"

I get error:

Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. Could not find or load a specific file. (0x80131621)

seesharper · 2021-11-29T15:52:33Z

Could you try executing the script with --isolated-load-context

intrasight · 2021-11-29T15:58:53Z

That did the trick. I just read this for context:

https://www.strathweb.com/2021/09/dotnet-script-1-2-is-out-with-assembly-isolation-feature/

I think adding that the readme would be a good idea.

georgiosd · 2022-02-20T17:35:17Z

Looks like I stumbled upon the same! #663

SamVanheer · 2022-03-06T15:07:41Z

I take it this is the same reason why referencing a NuGet package like NuGet.Versioning causes Object reference not set to an instance of an object errors? Dotnet-script loads this during script execution, probably when restoring packages.

When a script tries to pass a SemanticVersion object to another package that references NuGet.Versioning that error occurs. It looks like my local version is 6.0.2 whereas the package being referenced is version 6.1.0.

#637 mentions difficulties using isolated contexts, but doesn't specify what those difficulties are. Why isn't full isolation the default?

seesharper · 2022-09-27T19:21:56Z

Closed as resolved with --isolated-load-context

hrumhurum · 2023-10-11T13:07:40Z

#637 mentions difficulties using isolated contexts, but doesn't specify what those difficulties are. Why isn't full isolation the default?

Not all parts of .NET were ready for assembly isolation as of .NET 5.0 when this feature was first implemented. I don't remember the particulars, but there were omissions in assembly loading context during some reflection operations. This caused some packages to fail. Probably we should review the default setting for isolated load context after .NET 8.0 is released, as there is a great chance that outstanding issues in .NET had been already fixed.

seesharper

@hrumhurum I think Assembly.LoadFrom was one of the scenarios where interception did not work.

seesharper · 2023-11-13T23:14:20Z

@hrumhurum I have a branch here that runs all tests in isolated load context. It is just one failing test (ShouldHandlePackageWithNativeLibraries). It is a test that also loads native dll's
https://github.com/dotnet-script/dotnet-script/tree/default-isolation-context
Maybe you want to have a look at it. We consider making this the default in the next major version

hrumhurum · 2023-11-15T15:00:36Z

@seesharper I'll give it a shot. I'll post the results here.

seesharper · 2023-11-15T15:02:36Z

Thanks ❤️

hrumhurum · 2023-12-19T17:55:47Z

@seesharper When I try to run tests in https://github.com/dotnet-script/dotnet-script/tree/default-isolation-context branch, ShouldHandlePackageWithNativeLibraries test passes with ok result, no failure observed. Any hints?

seesharper closed this as completed Sep 27, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Assembly version issue #648

Assembly version issue #648

Assembly version issue #648

Assembly version issue #648

Comments