You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we're using your framework and stumbled upon the problem where File.Exists(localPath); from *Condition classes returns false because our app was not started manually (by clicking on an exe) but through registry upon machine startup.
After some debugging we found out that the problem was System.IO.File would look at a different default folder based on the two different ways of starting the app. If the app is started manually it properly looks into its root and updates the changed files. If however the app is started automatically on startup, the default directory that System.IO.File uses is for some reason C:\Windows\SysWOW64.
This caused us some problems so we temporarily fixed NAppUpdate by adding these few lines:
A better approach would be do the append the path to a more generic place such as SetNauAttributes(INauFieldsHolder fieldsHolder, Dictionary<string, string> attributes) method from Reflection.cs but we didn't want to do this as we didn't want to break some other functionality (we saw that in some places you actually did something similar to what we did (for example in FileUpdateTask class).
The mix of absolute/relative behavior should probably be refactored and standardized so it wouldn't cause the kind of problems we experienced.
Anyway, hope this helps if someone else stumbles into same problem or until this (hopefuly ;) gets fixed/refactored in a future version of the framework.
Also, thanks for creating the framework! :)
It helped us a lot.
Cheers
The text was updated successfully, but these errors were encountered:
Thanks - haven't noticed it before but it can definitely explain some issues people were having. If you could send a PR fixing / standardising this I will be more than happy to pull it in.
I think the correct approach would be to always normalize paths to be based on the app path - absolute paths don't really make sense. We just have to be careful not to override complex folder structure.
Yes, "based on the app paths" was what I was aiming at.
When I find some free time, I could look into the problem and try and fix it. I will probably need to ping you about a few questions, I'll need some answers about a few parts of your code to make sure I don't break anything in the process. Would that be ok?
Hi,
we're using your framework and stumbled upon the problem where
File.Exists(localPath);
from*Condition
classes returns false because our app was not started manually (by clicking on an exe) but through registry upon machine startup.After some debugging we found out that the problem was
System.IO.File
would look at a different default folder based on the two different ways of starting the app. If the app is started manually it properly looks into its root and updates the changed files. If however the app is started automatically on startup, the default directory thatSystem.IO.File
uses is for some reason C:\Windows\SysWOW64.This caused us some problems so we temporarily fixed NAppUpdate by adding these few lines:
after:
in the following classes:
A better approach would be do the append the path to a more generic place such as
SetNauAttributes(INauFieldsHolder fieldsHolder, Dictionary<string, string> attributes)
method fromReflection.cs
but we didn't want to do this as we didn't want to break some other functionality (we saw that in some places you actually did something similar to what we did (for example inFileUpdateTask
class).The mix of absolute/relative behavior should probably be refactored and standardized so it wouldn't cause the kind of problems we experienced.
Anyway, hope this helps if someone else stumbles into same problem or until this (hopefuly ;) gets fixed/refactored in a future version of the framework.
Also, thanks for creating the framework! :)
It helped us a lot.
Cheers
The text was updated successfully, but these errors were encountered: