Originally posted by rraghvani on December 01, 2025
That’s expected behaviour as Dispose() frees your class resources but doesn’t unload the assembly. The DLL remains locked until the TestComplete hosting process ends, so replacing the DLL requires closing/reopening the project or reopening TestComplete. Standard behaviour as mentioned in https://learn.microsoft.com/en-us/dotnet/standard/assembly/load-unload
I just tried it. When I remove the DLL completely and then click Reload, the DLL remains locked and I cannot overwrite or delete the file. Unfortunately, I still have to close the project in TestComplete first.
Originally posted by Hassan_Ballan on December 01, 2025
Just to add: while TestComplete can’t unload .NET assemblies once loaded, a few workarounds help avoid restarting the project every time:
Versioned build folders – output each DLL build to a new folder so TC loads it as a fresh assembly. • Shadow-copy loader – use a small .NET loader that copies and loads the DLL, keeping the original file unlocked. • Out-of-process wrapper – expose your logic via a small external service/COM server so TC never locks the DLL at all.
Doesn’t unload the assembly, but makes development much smoother.
Originally posted by rraghvani on December 02, 2025
I’m against killing processes, but since tcHostingProcess.exe doesn’t impact TestComplete you can kill the process via the command, in the Command Prompt
taskkill /im tcHostingProcess.exe /f
and copy the DLL over. Next time you run your script, the process will respawn. I’ve just tried this and it works.
Thank you very much. I agree with you that killing a process is not the most elegant solution. But it seems that there is no official way to terminate tcHostingProcess.exe directly from TestComplete.
Your suggestion would actually help me, because then I can create a postbuild event in Visual Studio that first terminates tcHostingProcess.exe and then copies the DLL to the target directory.
FYI: It works perfectly if tcHostingProcess.exe is still running, but throws an error if it has already stopped. To avoid this, these two lines of code should do the trick: