Paulo Janotti

Hi @gramidt, @jpkrohling, @alolita and @tigrannajaryan here is a [doc](https://docs.google.com/document/d/1jUfWCUgvXaWelZ81Ot2yprFWHyjdjMxvm75IdhCyaY8/edit?usp=sharing) with a design based on some prototyping. I would love to get some quick feedback so we can make this...

Only strong named assemblies can be loaded in the domain-neutral mode. After the [strong name fix](#1153) we would still need to add the assembly consider loading it in the domain-neutral...

To answer my own question on the previous comment with a relatively obvious answer that I didn't think of last Friday: we *must* use domain-neutral when instrumenting an assembly that...

Confirming that is actually flakyness: alpine, macos, and windows passed on retry on PR #1234

It seems that the issue is related to the ReJIT happening asynchronous. In a failed pass of the test we have: ``` [2022-09-22T02:47:31.803708579Z] [3580|3580] [debug] Enqueue for ReJIT [ModuleId=140150729282504, MethodDef=06000001,...

I simple modification to request the ReJIT in a synchronous fashion (directly on the thread handling ModuleLoadedFinsih) fixes the issue. However, I guess that this will have some perf impact,...

Yeah, I don't want to give the option to "perhaps a little fast" but some non-deterministic observability results. It seems that we have to offer a single and consistent way...

@muhaook could you please share the full logs for this? It seems that we failed to inject the managed code on the non-shared app-domain I'm not sure why.

@muhaook thanks for the logs. I think the root of the problem is: ```terminal [2022-08-21T15:54:05.429461400Z] [33532|36148] [info] AssemblyLoadFinished: OpenTelemetry.AutoInstrumentation.dll was not loaded domain-neutral ``` We still have to understand why...

Hi @muhaook, this was fixed, see #1134 and respective PR #1234. In order for the instrumentation assembly (`OpenTelemetry.AutoInstrumentation.dll`) to be loaded as domain neutral you need to registry it in...