You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:17Console.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;
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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
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;
Beta Was this translation helpful? Give feedback.
All reactions