HitCounterManager should ensure it references files relative to the application path rather than the pwd

[claytonw]

First of all, thanks for building such a solid app!

I spent a fair amount of time debugging an issue today with 2.x (I enjoyed reading the code BTW) only to discover that the root cause was that the binary (on mac at least) is expected to run from the folder the binary is in.

Consider resolving all paths from the binary location, rather than from the caller's CWD/PWD. Otherwise, the templates etc. don't get read etc.

n.b. It is possible now for users to have working configurations in other directories as well, so some additional logic to detect that may make sense as well

[topeterk]

Hi, I didn't want to force a specific path because of the flexibility using different paths for different configurations/runs.
Do you know what exactly changed that broke the installation? Maybe we can improve that instead?

[claytonw]

Thanks for the timely response. That makes sense. The change seems to have corresponded with an update to my OS, but I can't say for sure and could very well have just been user error. I tried updating the dotnet runtime (thinking it might be a library thing) and recompiling, but it did not address.

If it was simply user error, maybe some error messaging that a file can't be located etc. could help - but I think there's still an issue here.

In retrospect the bug title should have been: "Templates are not read and HitCounter.html does not update unless I run the binary from the application path" (The repro steps would be observing that HitCounter.html does not update when running the application from a different path than where the binary is located on a mac).

[topeterk]

Yes, a missing template could be a good reason for a warning message.

For Mac there is no installer, so from OS perspective I would assume all HCM files are "user files" and should not be touched during any system updates.
When there is an installer I would agree that an update "could" have impact on a software installation. However, the installers should do there potential reinstallation in order to maintain everything and make sure that e.g. desktop shortcuts or directory access rights or such things are as intended.
Therefore it sounds a little bit strange that HCM failed after the update.

Do you know if anything was changed in regards to file access rights / the application's location or paths in shortcuts / start scripts?
Would be nice to know the root cause (maybe it is because anything - I am not aware of - which is not correctly set and therefore an update might somehow break it).
Unfortunately I dont know how to develop or test for Mac as Apple doesn't seem to provide a test OS image that I could run on a virtual machine or something (without having any Apple device by myself).

TL:DR When I continue working on the project I think I will implement a warning message when the template is not found and make a hint that it might be due to a wrong working directory.

[claytonw]

I really wish I knew what caused it, but I'm at a loss. I thought it might be permissions-based (Apple has been doing sandboxing), but I'm skeptical of that. Could have been a subtle breakage between the .net runtime and the API calls it uses? It could have also have simply been user error on the command line. (ex: Ran the app from a different path and left things in a weird state).

Regardless, I think you're right: a dialog notifying the user that something the app is expecting to find isn't available (with some notes about where it's looking) makes sense.

Again, just wanted to say that I really appreciate your moving the tool to a cross-platform framework - I know MacOS/Linux users are not many in this community and the support cost is nontrivial. Thanks again.