0

The problem is Inno (V6.2.2) fails to delete the temporary directory because there are still files in it that are not unloaded. Inno Setup's UnloadDll doesn't work on managed libraries.

Before this is tagged as duplicate, Unload a .NET dll from an Unmanaged Process provided a solution that works, but I feel has it's own flaws. @MartinPrikryl provided a method using a batch file. @Razique took the batch file a step further using PowerShell with a sleep parameter to allow deletion after Setup terminates.

Using the PowerShell approach, I am experiencing what seems to be orphaned processes from Inno and the PowerShell script and Console Window Host. When 20 tests are run a day these orphans build up. After several days without restarting the computer weird things happen to the Win 10 task bar. Granted, a user will not be running the install multiple times, but this seems like something that should not happen for a clean installation.

Being that technology changed rapidly since many of the articles were written I have started looking into creating an AppDomain. In the linked article above, @AQuirky posted an answer suggesting use of an AppDomain. @Martin criticized it and perhaps rightly. But, there seems to be sufficient cause to believe it could work if managed correctly.

Besides several libraries created to assist the installation process, my installer includes an executable that serves as a splash screen equipped with a progress bar. My thinking is that the splash screen program would create the AppDomain and load the dll assemblies into it early in the process. Then the window hides and the app summoned up to unload the domain during DeInitialize.

While it has been fun learning AppDomain, I'm wondering if Inno Setup creates its own kind of domain for the libraries when they are defined in code. If so, there would be two domains with the same libraries and one set would not be called. That could mean that when my program unloads it's app domain, it will. But the Inno set of dlls would still be dangling in memory until reboot or deleted as mentioned earlier. I'm not to the point of real tests on this yet.

Is there a more clean approach these days that I can take advantage of?

DigAtRandom
  • 11
  • 4
  • I'm not sure about the point of this questions. Still duplicate imo. Two notes anyway: 1) I do not think that @Razique improved my solution. On the contrary, his answer uses fixed timeout, what can fail easily, if the process does not finish in time. While my answer waits as long as it is needed. 2) Afaik, Inno Setup does not create any .NET app domain. Inno Setup does not care about .NET. It just loads the .NET DLL as any other DLL. It's the DLL (or the framework in invokes) that creates the domain. – Martin Prikryl Jul 27 '23 at 19:49
  • This: "what seems to be orphaned processes from Inno and the PowerShell script and Console Window Host" seems suspect. I would recommend to analyze this and determine a root cause. – Bill_Stewart Aug 08 '23 at 19:00

0 Answers0