After trying this a bit more, here's a few things:
First time I ran it, it deleted my AllPlayed addon. No errors, no nothing. It just disappeared (it did add it to the revision database, though) (this was before my last post, though).
Secondly, does having HandlePackages set to False mean that instead of installing the packages, it uninstalls them? I have !!!StandAloneLibraries in my UI folder to check for new library downloads. However, if there is update available for the !!!StandAloneLibraries, the updater will remove every single stand alone library from my ui folder, that does not have update available on the same run.
Thirdly, it would be nice if the updater does not rewrite the log every single time. I was kinda thinking of running the updater as scheduled task, and it can be kinda bothersome to figure out if something went wrong at some point, because it destroys the old log every time it's run.
Secondly, does having HandlePackages set to False mean that instead of installing the packages, it uninstalls them? I have !!!StandAloneLibraries in my UI folder to check for new library downloads. However, if there is update available for the !!!StandAloneLibraries, the updater will remove every single stand alone library from my ui folder, that does not have update available on the same run.
If the HandlePackages is set to True, the updater will move the modules from the addon folder to the Interface\Addons folder after extracting the zip. It will also remove all of the modules related to the main addon when uninstalling.
When it's set to False, the updater will handle the package addons like regular addons and won't delete the related modules when uninstalling.
About the other 2 questions:
I'm not sure about what happened with the AllPlayed addon on the first run. I'll see if I can reproduce the error.
About the logging system, I'll reconsider it. I'll probably implement a configuration switch that modifies the logging behavior.
When it's set to False, the updater will handle the package addons like regular addons and won't delete the related modules when uninstalling.
Okay, perhaps phrasing it as a question did not exactly get my point through. I meant, it actually happened to me. I have HandlePackages set to false, and when !!!StandAloneLibraries has an update available (on "cmdau -up"), it WILL remove all the sub addons from the interface/addons/ folder that are not updated on the same run.
And this is also easily reproducable. For example, when I have all the addons up to date, just set the revision number in the updaters database for !!!StandAloneLibraries and for some other lib like "AbacusLib" for lower than they are. Run the updater normally with "cmdau -up" and I can see that it will update the "!!!StandAloneLibraries" and "AbacusLib", but mysteriously delete every other stand alone library from my interface/addons/ folder.
This is not related to only to !!!StandAloneLibraries, though. I tested it with Cartographer too, and it will remove all the cartographer sub addons from interface/addons/ folder if Cartographer is updated.
----
Though, I suppose I could just look at the source, and notice that the updater algorithm ignores the HandlePackages switch on uninstalling previous addon.
So updater uninstaller handles packages and never even takes a look at the "Settings.HandlePackages" switch, which is only looked at by the installer when actually installing the new revision.
----
Also, regarding the disappearing AllPlayed addon, I suppose it was some error somewhere. I notice that your updater isn't very big on notifying errors in the process (such as if the zip package failed to unzip or the package failed to download properly, etc...)
Ah yes, true. The uninstall function doesn't check the HandlePackages. Going to fix it and upload.
Edit: Just another note.
Updating of the libraries inside the !!!StandaloneLibraries isn't done in the same run as the installation of the !!!StandaloneLibraries.
When the updater installs is, it creates the empty library folders which are replaced by the libraries on the next update.
Edit2: So if you're using the !!!StandaloneLibraries package, the best and shortest way to update is doing the following:
Unhandled Exception: System.TypeInitializationException: The type initializer fo
r 'CmdAceUpdater.Output' threw an exception. ---> System.UnauthorizedAccessExcep
tion: Access to the path 'D:\Game.Stuff\WOW.Stuff\cmdau\conf\CmdAceUpdater.log'
is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, I
nt32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions o
ptions, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamWriter.CreateFile(String path, Boolean append)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encodin
g, Int32 bufferSize)
at System.IO.StreamWriter..ctor(String path, Boolean append)
at System.IO.File.CreateText(String path)
at CmdAceUpdater.Output..cctor()
--- End of inner exception stack trace ---
at CmdAceUpdater.Output.Info(String Text)
at CmdAceUpdater.CmdAceUpdater.Main(String[] Args)
Unhandled Exception: System.TypeInitializationException: The type initializer fo
r 'CmdAceUpdater.Output' threw an exception. ---> System.UnauthorizedAccessExcep
tion: Access to the path 'D:\Game.Stuff\WOW.Stuff\cmdau\conf\CmdAceUpdater.log'
is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, I
nt32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions o
ptions, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamWriter.CreateFile(String path, Boolean append)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encodin
g, Int32 bufferSize)
at System.IO.StreamWriter..ctor(String path, Boolean append)
at System.IO.File.CreateText(String path)
at CmdAceUpdater.Output..cctor()
--- End of inner exception stack trace ---
at CmdAceUpdater.Output.Info(String Text)
at CmdAceUpdater.CmdAceUpdater.Main(String[] Args)
D:\Game.Stuff\WOW.Stuff\cmdau>
I think that has something to do with the new access rights stuff in Vista. Unfortunately I can't test it at the moment as I don't have Vista installed. I'll see what I can do.
Unhandled Exception: System.TypeInitializationException: The type initializer fo
r 'CmdAceUpdater.Output' threw an exception. ---> System.UnauthorizedAccessExcep
tion: Access to the path 'D:\Game.Stuff\WOW.Stuff\cmdau\conf\CmdAceUpdater.log'
is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, I
nt32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions o
ptions, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamWriter.CreateFile(String path, Boolean append)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encodin
g, Int32 bufferSize)
at System.IO.StreamWriter..ctor(String path, Boolean append)
at System.IO.File.CreateText(String path)
at CmdAceUpdater.Output..cctor()
--- End of inner exception stack trace ---
at CmdAceUpdater.Output.Info(String Text)
at CmdAceUpdater.CmdAceUpdater.Main(String[] Args)
D:\Game.Stuff\WOW.Stuff\cmdau>
I think that has something to do with the new access rights stuff in Vista. Unfortunately I can't test it at the moment as I don't have Vista installed. I'll see what I can do.
Confirming that this crashes under Vista. Doesn't error for me, but instead crashes.
Shame. Just when I thought I could press one button to update instead of five.. :(
edit: It also crashes when listing addons. Could be because WoW is not installed in Program Files.
edit2: I just added a slash directly after the directories and it no longer errors on MOST addons. Instead, it errors on SOME addons. Going to do a bit more looking, hopefully I'll find out why. For now I'll list the addons it errors on: BigWigs, Prat.
ProfileDir=C:\Users\Admin\Desktop\CmdAceUpdater\conf\
WowDir=C:\World of Warcraft\
edit3: It DOES error. Except the very second it errors, Windows closes the program.
edit4: Tried enabling logging - and the error isn't written to the log.
edit5: It also crashes if any of the files in it's own directory are read-only.
edit6: :) I believe I have found the problem. The reason it crashed on the two addons listed above was because they were checked as read-only for some reason. This is the cause of some crashes under vista, apparantly. The other cause is it not being able to detect the WoW directory.
edit7: Request - Allow for a file to specify addons where we do not want to delete before extracting. I'd like to do this for Skinner so I don't have to recopy addon skins to the SkinMe directory.
Is there a way to keep custom files inside addon folders? PT3Bar is able to load a file called OtherConfig.lua, however it isn't distributed with it because it's a user-configurable file. This wasn't an issue with WAU but with CAU it seems it deletes and re-extracts the addon on a new update, correct?
Is there a way to keep custom files inside addon folders? PT3Bar is able to load a file called OtherConfig.lua, however it isn't distributed with it because it's a user-configurable file. This wasn't an issue with WAU but with CAU it seems it deletes and re-extracts the addon on a new update, correct?
Same goes for Skinner and the SkinMe subfolder.
Currently there's no way to do it because, as you said, CAU deletes the addon folder and then extracts the new zip.
It's on my todo list. :)
Also working on a fix for the problem on Vista. A bit short on time these days, but I'll make it work soon :)
Added a way to keeping the custom files inside the addon folders through the new DeleteBeforeExtracting setting which is disabled by default (means it keeps the custom files by default).
Possible fix for the Vista problems, can't test it.
If the Vista fix doesn't work, completely disabling logging should work at least.
Added a way to keeping the custom files inside the addon folders through the new DeleteBeforeExtracting setting which is disabled by default (means it keeps the custom files by default).
Possible fix for the Vista problems, can't test it.
If the Vista fix doesn't work, completely disabling logging should work at least.
cmdau -c Logging False
The program now crashes when attempting to install any addon in Vista.
edit: The exact line of code that crashes: (in server.cs):
using(WebClient wc = GetWebConfiguredWebClient()) wc.DownloadFile(FileUrl, LocalFileName);
Fixed and uploaded.
First time I ran it, it deleted my AllPlayed addon. No errors, no nothing. It just disappeared (it did add it to the revision database, though) (this was before my last post, though).
Secondly, does having HandlePackages set to False mean that instead of installing the packages, it uninstalls them? I have !!!StandAloneLibraries in my UI folder to check for new library downloads. However, if there is update available for the !!!StandAloneLibraries, the updater will remove every single stand alone library from my ui folder, that does not have update available on the same run.
Thirdly, it would be nice if the updater does not rewrite the log every single time. I was kinda thinking of running the updater as scheduled task, and it can be kinda bothersome to figure out if something went wrong at some point, because it destroys the old log every time it's run.
If the HandlePackages is set to True, the updater will move the modules from the addon folder to the Interface\Addons folder after extracting the zip. It will also remove all of the modules related to the main addon when uninstalling.
When it's set to False, the updater will handle the package addons like regular addons and won't delete the related modules when uninstalling.
About the other 2 questions:
I'm not sure about what happened with the AllPlayed addon on the first run. I'll see if I can reproduce the error.
About the logging system, I'll reconsider it. I'll probably implement a configuration switch that modifies the logging behavior.
Okay, perhaps phrasing it as a question did not exactly get my point through. I meant, it actually happened to me. I have HandlePackages set to false, and when !!!StandAloneLibraries has an update available (on "cmdau -up"), it WILL remove all the sub addons from the interface/addons/ folder that are not updated on the same run.
And this is also easily reproducable. For example, when I have all the addons up to date, just set the revision number in the updaters database for !!!StandAloneLibraries and for some other lib like "AbacusLib" for lower than they are. Run the updater normally with "cmdau -up" and I can see that it will update the "!!!StandAloneLibraries" and "AbacusLib", but mysteriously delete every other stand alone library from my interface/addons/ folder.
This is not related to only to !!!StandAloneLibraries, though. I tested it with Cartographer too, and it will remove all the cartographer sub addons from interface/addons/ folder if Cartographer is updated.
----
Though, I suppose I could just look at the source, and notice that the updater algorithm ignores the HandlePackages switch on uninstalling previous addon.
Worker.cs : line 15 : InstallAddon
Worker.cs : line 56 : Uninstall
So updater uninstaller handles packages and never even takes a look at the "Settings.HandlePackages" switch, which is only looked at by the installer when actually installing the new revision.
----
Also, regarding the disappearing AllPlayed addon, I suppose it was some error somewhere. I notice that your updater isn't very big on notifying errors in the process (such as if the zip package failed to unzip or the package failed to download properly, etc...)
Edit: Just another note.
Updating of the libraries inside the !!!StandaloneLibraries isn't done in the same run as the installation of the !!!StandaloneLibraries.
When the updater installs is, it creates the empty library folders which are replaced by the libraries on the next update.
Edit2: So if you're using the !!!StandaloneLibraries package, the best and shortest way to update is doing the following:
Changes:
Keep up the good work.
D:\Game.Stuff\WOW.Stuff\cmdau>cmdau -up
CmdAceUpdater v0.41
Unhandled Exception: System.TypeInitializationException: The type initializer fo
r 'CmdAceUpdater.Output' threw an exception. ---> System.UnauthorizedAccessExcep
tion: Access to the path 'D:\Game.Stuff\WOW.Stuff\cmdau\conf\CmdAceUpdater.log'
is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, I
nt32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions o
ptions, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamWriter.CreateFile(String path, Boolean append)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encodin
g, Int32 bufferSize)
at System.IO.StreamWriter..ctor(String path, Boolean append)
at System.IO.File.CreateText(String path)
at CmdAceUpdater.Output..cctor()
--- End of inner exception stack trace ---
at CmdAceUpdater.Output.Info(String Text)
at CmdAceUpdater.CmdAceUpdater.Main(String[] Args)
D:\Game.Stuff\WOW.Stuff\cmdau>
I think that has something to do with the new access rights stuff in Vista. Unfortunately I can't test it at the moment as I don't have Vista installed. I'll see what I can do.
Confirming that this crashes under Vista. Doesn't error for me, but instead crashes.
Shame. Just when I thought I could press one button to update instead of five.. :(
edit: It also crashes when listing addons. Could be because WoW is not installed in Program Files.
edit2: I just added a slash directly after the directories and it no longer errors on MOST addons. Instead, it errors on SOME addons. Going to do a bit more looking, hopefully I'll find out why. For now I'll list the addons it errors on: BigWigs, Prat.
ProfileDir=C:\Users\Admin\Desktop\CmdAceUpdater\conf\
WowDir=C:\World of Warcraft\
edit3: It DOES error. Except the very second it errors, Windows closes the program.
edit4: Tried enabling logging - and the error isn't written to the log.
edit5: It also crashes if any of the files in it's own directory are read-only.
edit6: :) I believe I have found the problem. The reason it crashed on the two addons listed above was because they were checked as read-only for some reason. This is the cause of some crashes under vista, apparantly. The other cause is it not being able to detect the WoW directory.
edit7: Request - Allow for a file to specify addons where we do not want to delete before extracting. I'd like to do this for Skinner so I don't have to recopy addon skins to the SkinMe directory.
Same goes for Skinner and the SkinMe subfolder.
Currently there's no way to do it because, as you said, CAU deletes the addon folder and then extracts the new zip.
It's on my todo list. :)
Also working on a fix for the problem on Vista. A bit short on time these days, but I'll make it work soon :)
Changes:
If the Vista fix doesn't work, completely disabling logging should work at least.
The program now crashes when attempting to install any addon in Vista.
edit: The exact line of code that crashes: (in server.cs):
using(WebClient wc = GetWebConfiguredWebClient()) wc.DownloadFile(FileUrl, LocalFileName);
Bah, I need a machine with Vista and a bit of time to do some reading about the Vista access rights changes. :)
Thanks for testing btw :)