Fix #18441

[majocha]

This fix is maybe better than my previous attempt (#18443).

The problem is the same as #16118. It still happens when one session is multi-emit and the other uses legacy AssemblyBuilder.

This solution is basically same as original solution #16139: don't do simple name binding even for single-emit.

The risk is that I don't know why there was a need of resolving "FSI-ASSEMBLY" by simple same in the first place.
The code for it was there forever but it doesn't look like it is used anymore. The tests pass without it.

@KevinRansom, please take a look if it makes sense.

[github-actions]

❗ Release notes required

@majocha,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/9.0.300.md	No release notes found or release notes format is not correct

[KevinRansom]

This looks more like a bcl test case than one interesting to us.

[majocha]

Yep, I'll remove it.

[KevinRansom]

@majocha ---
A better question, is, "Do we still need "--multi-emit-", I can't think of any scenario, where it is necessary any longer. Now that multi-emit works well, without limits on submissions, my inclination is to rip it out. It would be nice to start eliminating parallel scenarios.

The magic resolver is the beating heart of FSI's #r feature, so I would only ever tweak it, and be terrified while doing it. The main issue with tweaking it are that it supports, desktop framework assembly resolution and coreclr assembly resolution. That the tests work is not that great a validation, we don't do a ton of FSI testing, and what we do, doesn't do a lot of assembly resolution. So I would avoid making changes to it if I could.

The trouble with saying what I just did, is I will then search for "the solution" you should ask @vzarytovskii how easy I am to nerd snipe. Needless to say I am easy, he and Tomas used to do it to me all of the time.

The problem you identified is that when multiemit + and - are mixed in process, there is not a good way of distinguishing between the "in memory "Builder" version of the assembly, which is what the Simple name resolution is for, and the multi-emit versioned version which is what the fullname is for.

I think the fix is to change the name of the generated assembly for one of the scenarios something more like this: https://github.com/dotnet/fsharp/pull/18465/files

I haven't done a lot of testing on it, but I think this is the right fix. Although we need to have a discussion, about whether we even need multiemit- any longer. I can easily see us choosing to drop it in NET10.

Thanks for looking at this

Kevin

[majocha]

Awesome, that looks like a safe fix. Thanks Kevin!

[KevinRansom]

Awesome, that looks like a safe fix. Thanks Kevin!

Thanks mate,
I wouldn't mind having a discussion about whether we need multiemit-. Because I would like to remove it.

Kevin