I hope the VSCode Jupyter plugin can support # load "xx. cs". This CS file can contain namespaces

[nczsl]

When using # load "... xx.cs or csx" to load a file; If this CS or CSX file uses a namespace, it is not supported

[jonsequitur]

#load will work with a .cs file but it can't contain namespaces. Namespaces are not supported in C# Script.

[nczsl]

#load will work with a .cs file but it can't contain namespaces. Namespaces are not supported in C# Script.

Even if you insist on not supporting it, but you can ignore it

[jonsequitur]

A simpler and more robust approach that I sometimes recommend is to build the project and reference the assembly using #r "/path/to/the.dll"

An extension that removes the namespaces before compiling would probably be feasible for very simple cases, but there would be a large number of cases where it wouldn't work as people might expect. A few examples off the top of my head:

• Types referenced in a different file might be in that same namespace, so type resolution would be tricky.
• Types referenced in a different source file would also need to be compiled...
• ...but if there are references in both directions, then the two files have be compiled at the same time, which #load doesn't support.
• Some using directives will be needed but others won't compile either because they were removed or because they're included in package or project references.
• Modifying using directives might change which types are referenced when types exist in multiple namespaces, or when types with the same name were declared or imported within the current interactive session.

[nczsl]

I choose to comment out the namespace; I won't use the scheme of "# r " xx \ xxx. dll \ "because it locks the directory where the DLL is located. Usually, I use C # scripts to debug while modifying, so this doesn't work

[jonsequitur]

A magic command that makes a shadow copy might be useful to prevent locking the .dll.

I choose to comment out the namespace;

An #if...#endif block could work as well.