#r Unable to respond in real-time to changes in the dependent assembly

[nczsl]

If the # r command is used to reference two different compiled versions of a DLL in vscode jiupyter, it seems that only one version works. I also tried dynamically setting the version number in csproj to have a different version number for each generation, or manually changing the value of the path string referenced by # r, but none of these worked. Only restarting the VSCode adapter will take effect.

I think this greatly reduces the significance and value of VSCode Jupyter. Obviously, this is a problem that has been repeatedly mentioned for many years; But it seems that it has not been resolved yet, and I don't know the reason behind it; At first, I confirmed this issue by stating that referencing local DLLs in # r would cause locking of related folders (locations). Later, I copied these DLLs to a temporary location during generation, and each time they were generated, they were copied to a newly generated temporary folder. However, the problem has not been resolved yet. It always either doesn't work or locks the folder, and has to be restarted. I think this experience is very bad, it's very imperfect. The reference documents I am currently using below

// This is common. csx, which is loaded by other csx files, and then those csx files are loaded by ipynb;
#r "E:\netenv\tool\lab\Synario.BizModel\dist\005\Synario.BizModel.2.dll"
#r "E:\netenv\tool\lab\Synario.BizModel\dist\005\Synario.CodeModel.2.dll"
#r "E:\netenv\tool\lab\Synario.BizModel\dist\005\Synario.Util.2.dll"


// auto generate common.csx file
// create on 12/17/2024 23:50:17
Console.WriteLine("this is common.csx file at create by No 005 time");

I originally thought that vscode jupyter would recognize the new assembly version based on the number changes on the # r path, but it doesn't. I changed the name of the DLL, such as adding ". 2" at the end, but it still doesn't work. Adding a dynamic version number in csproj also doesn't work; Only by restarting VSCode Jupyter can it be done;

[jonsequitur]

I'm not entirely sure how to repro the issue. #r does lock the DLL but restarting the kernel consistently unlocks it for me and I can rebuild it.

If you're looking for a behavior more like hot reload, that's not available in .NET Interactive at this time.