Leaderboard

Solved at last. The DLL was hanging due to the call to AddToLog in CloseServer due to the Log thread being terminated at the same time as the call. In the meantime, I had added a TFDMoniFlatFileClientLink component to provide a FireDAC trace to see what was happening with the FDManager as I thought that was causing the problem. Once I'd fixed the problem with the thread log, I still had issues. By a process of starting from scratch (as you suggested) and adding units/components as I went along, I eventually managed to narrow it down to the FlatFile component. Once I removed it, all was well. Must be a threading problem or some such. Many thanks for your help

What? Assignment of these three types consist of multiple operations - just look into _UStrAsg, _IntfCopy or _DynArrayAsg - hence they are not atomic.

Well, I'd clone/backup the project and start removing all 3rd party units, including firedac. - did you check the system/application events? - if you kill all the w3wp processes in the taskmanager, will then IIS stop faster?

Yes. I'm sure that freeing of FDManager is not the issue. Yes. Will do.

Further process of elimination. It was nothing to do with the call to free FDManager. It was the AddToLog calls that were causing the problem. These are threaded using the FThreadFileLog, which I free in the final part of CloseServer and before the threads called in CloseServer had terminated. I have changed these calls so that they are now not threaded and also as a double precaution added a check in ThreadFileLog's destroy event to make sure no threads are running before it is shut down. My CloseServer procedure now frees all the resources as expected, but the application pool is still taking an age to close down. There must be some resource I am creating and not freeing. I will check all my code and if I can pinpoint what it is I will update.

Streams don't know about encoding. You might better do with a TStreamReader. In its FillBuffer method there is some code taking care of your concern (look for ExtraByteCount).

I researched a lot this because I wanted to include ads in my desktop app as well. The bottom line is that all the content publishers support only mobile apps. I have seen the link you give before but I am unclear as to whether it works. I doubt TBH. Google ads does not allow desktop apps indeed and they ban your account even if you "fake" a website withing a browser component. I have a app on my desktop (TuneIn) that shows ads from google. In earlier versions, they were using Taboola but now they moved to Google Ads. When I was reaching out people from the ad networks, they all told me that the app is using a few google accounts and cycles them so detection is avoided. They also said that eventually google will figure it. If you download the app, you can click and drag and select all the components in the window; pretty much what you do in a web page. This makes me think that the app is written with some sort of web framework and is mocking a website and thus the ads show normally. One of those people I talked to said that in general revenue from ads in desktop apps is extremely low which in practice makes it a worthless choice unless you have 4-5 million downloads. He suggested to consider other forms of licensing, like freemium, etc.

Not when using blocking sockets, no. There are no asynchronous events in that situation. A remote disconnect is reported only when an I/O operation fails due to the peer having already closed the connection on their end. A peer disconnecting gracefully is typically discovered as a read operation that returns 0 bytes rather than an error code. That is the condition that Indy uses to raise EIdConnClosedGracefully for a remote disconnect, so a read has to be performed to get that exception in most cases.

Client side or server side? On the client side, OnDisconnect is only fired when Disconnect() is called, it is not an asynchronous event. Indy is largely synchronous only, so it is hard to get this exception without do something to trigger it. Server side might make more sense, since Indy servers generally run a continuous reading thread, so the exception is more likely to happen on that side, but just let the server handle it internally for you.