Thanks, that looks reasonable.

The folder concept is a bit complicated in scripting, because e.g. in nuget intellisense handling, package availability in OmniSharp is handled per folder. If I recall correctly, this was also a reason why caching behaves this way.

@seesharper do you have any objections to change this?

Interesting, I did not know about that.

I now tested my changes in combination with VSCode/OmniSharp.

Usability wise, everything seems to work normal including intellisense for nuget packages.

Technically wise, this PR only changes the location of the execution-cache.
The script project cache path (that folder named after the TargetFramework) was not changed and is therfore still directory based. VSCode/OmniSharp only seems to use this script project cache.

Temp-Folder content before this PR:

%tmp%\dotnet-script\D\execution-cache\script.dll
%tmp%\dotnet-script\D\net5.0\script.csproj
%tmp%\dotnet-script\D\net5.0\obj\
%tmp%\dotnet-script\D\net5.0\compilation\

Temp-Folder content after this PR:

%tmp%\dotnet-script\D\scriptA.csx\execution-cache\script.dll
%tmp%\dotnet-script\D\scriptB.csx\execution-cache\script.dll
%tmp%\dotnet-script\D\net5.0\script.csproj
%tmp%\dotnet-script\D\net5.0\obj\
%tmp%\dotnet-script\D\net5.0\compilation\

I have used a custom dotnet-script version including this change for the last 3 months. Debugging and writing (with autocomplete and so on) in VSCode works normal just like before.

@filipw can this get merged?

I rebased it. Thanks

@filipw Can you take a last look at this. I think it is good to go 👍

sorry for the delay - and thanks!

I would guess that this fixes my issue too #540, but I probably won't get time to check