Bug?

GregGorman

I have this C# code:
void Main()
{
string extractPath = @C:\Test;
CleanExtractPath(extractPath);
}

public void CleanExtractPath(string path)
{
if (Directory.Exists(path))
{
var recursive = true;
Directory.Delete(path, recursive);
}
Directory.CreateDirectory(path);
Directory.SetCurrentDirectory(path);
}

On first run with Premium v5.26.01 this works.
On successive runs it fails on Directory.Delete.

If I cancel all threads with Ctrl-Shift-F5, it will again run.

Is it just something I'm doing wrong or is it a bug with LinqPad?

nescafe

This is by-design. As you set the current directory to the newly created directory, it will be 'locked' and cannot be deleted.

An equivalent in a command line window would be:

C:\>md Test

C:\>rd Test

C:\>md Test

C:\>cd Test

C:\Test>rd C:\Test
The process cannot access the file because it is being used by another process.

JoeAlbahari

Also, when you change the current directory, the change will persist for next time you run the query. But when you press Ctrl+Shift+F5, it kills the query process, so it's like running it for the first time again.

GregGorman

Brilliant! Thank you.

jsytniak

Is there a way to include a method call within the LINQPad namespace for issuing the Ctl+Shift+F5 command from code? Perhaps this already exists and I just haven't located it yet?

My use case is that I have started to include some LINQPad.Controls elements into scripts for collecting user input parameters. This is probably a nit but I find this introduces a context where the UI elements are in a thread that remains active... which is fine... and I can see use cases that would call for this... but would be good to have the option to cancel that UI thread if so desired.

JoeAlbahari

Can you elaborate? Why do you need to cancel the UI thread?

In the case of HTML controls, the UI thread is not really a UI thread - it's the main thread that executes your query and continues running after your query finishes. This thread always exists - regardless of what you dump - and it has to keep running because there needs to be a way to interact with the process after the query has finished. If the main thread ended, then so would the process, and then there would be way to execute any event handlers in your HTML controls.

Note that by default, all event handlers on HTML controls queue onto this main thread - this avoids thread-safety errors that could otherwise occur (fairly easily) if the event handler ran on its own thread. However, you can disable this behavior by setting the control's IsMultithreaded property to true. This will make event handlers execute on pooled threads instead of the main thread. You then have to be careful with thread-safety, because multiple event handlers may end up executing at the same time.