Prevent multiple instances when "Allow multiple instances" is de-selected

[tamlin-mike]

Tested with 65792df.

Sometimes you might want to add multiple assemblies from command line. One might then use something like

for %i in (*.dll) do @ilspy "%i"

When ILSpy is already open that works (though the assemblies generally gets added in the wrong order).

Today I made the mistake of not having ILSpy running already when running such a mass-add. Ooops - umpteen instances of ILSpy started, leaving me frenetically closing a lot of instances. :-)

I suggest moving the check for an existing instance to way earlier in the startup sequence when "Allow multiple instances" is not selected, to prevent this.

It probably requires two synchronization objects. One to check for an already running instance, and one to check for "is the running instance ready to recieve the path of an additional assembly".

It's not a big problem, it can easily be deferred to the most rainy and boring day of the decade. :-)

[siegfriedpammer]

though the assemblies generally gets added in the wrong order

I don't think we will be able to do anything about this, because it depends on how explorer.exe launches the ILSpy processes and how WM_COPYDATA is then handled. I don't think the order can be made deterministic.

[tamlin-mike]

it depends on how explorer.exe launches the ILSpy processes

Explorer.exe wasn't even part of the equation.

It might be the slowness and undeterministic behaviour of .NET process startup (-time) in combination with the general slowness of Windows process startup. Hundreds upon hundreds of DLL's, with thousands upon thousands of forced relocations each isn't exactly helping either. But that's Windows for ya: "Please Wait...(tm)". :-)

Anyway, thanks for the fix.

[siegfriedpammer]

it depends on how explorer.exe launches the ILSpy processes

Explorer.exe wasn't even part of the equation.

My apologies. You are right of course. At the time of writing I was thinking about the "Open with ILSpy" shell extension. :-)

[tamlin-mike]

About the reordering.
Without having looked at the code, my hypothesis of the reordering is that the initial decompilation is kicked off at WM_COPYDATA arrival (to a thread or pool, to keep UI responsive), but defers adding it to the list (TreeView) until it has "matured" enough. If so, it's dependent on not only the order of the incoming (by WM_ message) assembly names, but also the relative complexity of their initial processing and even OS thread scheduling.

So is that worth losing any sleep over? No. :-)