search

FOGProject / fog-client

A cross platform computer management client
GNU General Public License v3.0
108 stars 34 forks source link

Extraction of files on Linux and Mac OS X uses wrong path #122

Closed Sebastian-Roth closed 4 years ago

Sebastian-Roth commented 4 years ago

When extracting the files from the self containing ZIP file the installer uses backslashes (Windows) as directory separator on all systems. Looks like this on Linux:

$ ls /opt/fog-service/
ca.cert.der                      FOGService.exe                   hu\Modules.resources.dll         pt\Modules.resources.dll
Common.Logging.Core.dll          FOGService.exe.config            ICSharpCode.SharpZipLib.dll      Quartz.dll
...

This is known and has been fixed a long time ago: https://github.com/icsharpcode/SharpZipLib/issues/54

We just need to update SharpZipLib in UniversalInstaller (and possibly mode sub projects?). But needs testing on different platforms as well as we have added two specific ZIP fixes between 0.11.16 and 0.11.17 that might be influenced by this update.

Sebastian-Roth commented 4 years ago

@danielbmiller Would you help testing on Mac OS X after updating the ZIP lib?

Sebastian-Roth commented 4 years ago

@danielbmiller This is probably gonna be delayed. I kind of had that feeling that there is more to it than just updating that SharpZipLib itself. Tried to do it and ran into:

Severity    Code    Description Project File    Line    Suppression State
Error       Could not install package 'SharpZipLib 1.2.0'. You are trying to install this package
into a project that targets '.NETFramework,Version=v4.0', but the package does not contain any
assembly references or content files that are compatible with that framework. For more information,
contact the package author.

This definitely needs some more consideration and testing than I would have hoped. I am still too new to all this .NET world and don't know the consequences of moving on to v4.5 or v4.6 or v4.7...

danielbmiller commented 4 years ago

Branched to see what breaks: moved target .net to 4.7.2. See https://github.com/danielbmiller/fog-client/tree/Issue_122_fix I haven't done this as a PR because I haven't done any testing with it yet, but it at least doesn't generate any compile time errors. still a warning about metroframework, but I think there are breaking changes in some definitions between the version used and the version currently available. Going to try to make some time to test tomorrow or monday

Sebastian-Roth commented 4 years ago

@danielbmiller Nice, thanks! Do you know if moving to 4.7.2 could cause trouble e.g. on Linux with Mono? Not knowing too much about the versions I would have gone to 4.5 for now.

While I can find the current compatibility list for mono I don't seem to find any information on older versions. For example I suppose we still have users with Ubuntu 16.04 (LTS up until April 2021) which uses mono version 4.2.1. I am not sure if mono version equals .NET version?!? While I can't find a definite answer to that on the net I would imagine it to be equal.

Doesn't mean we can't move on until Ubuntu 16.04 is end of life. Just saying that we should consider those kind of things before rushing into 4.7.2. :-)

danielbmiller commented 4 years ago

Like I said, seeing what is going to break ... hence no PR 4.5 is actually EOL with Microsoft, so lowest I would probably do would be 4.5.2 if I am reading their lifecycle policy correctly https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework . 4.5.2 is also purportedly the last version to have breaking changes. I may actually put up a branch for 4.5.2 if I have time later today.

danielbmiller commented 4 years ago

Created a branch for each target. https://github.com/danielbmiller/fog-client/tree/Issue_122_fix_4.5.2_target https://github.com/danielbmiller/fog-client/tree/Issue_122_fix_4.7.2_target When I was going through re-targeting to 4.5.2 I saw that the projects that I thought were 4.5 were actually 4.5.2, so there is a chance that there are no obsoleted installation environments for that branch.

Sebastian-Roth commented 4 years ago

@danielbmiller Thanks heaps. I will have a closer look soon, when I have a bit more time.

danielbmiller commented 4 years ago

Had an excuse to try the new build (4.5.2 branch) on a mac. /opt/fog-service has a directory structure now, so at least extraction during install works. fog.log looks as expected.

Sebastian-Roth commented 4 years ago

Sounds great! I will give it a try this week as well.

danielbmiller commented 4 years ago

also tested the 4.5.2 branch on a Win machine yesterday. no abnormal behavior noted or oddities noted in the logs.

Sebastian-Roth commented 4 years ago

@danielbmiller Still haven't found the time to test myself, sorry! Sounds pretty good from what you say. I hope to find a bit more time to work on this after the next FOG release. I won't loose track of this.

danielbmiller commented 4 years ago

FYI: brought in the upstream changes to the 4.5.2 branch that I apparently didn't include like I thought I did when branched. This broke the MSI build as there are missing references in .\bin. Building all the targets in batch mode apparently takes care of it, but probably need to figure out what isn't getting called in the build script (I suspect a NuGet package download) that causes things to go pear-shaped.

Sebastian-Roth commented 4 years ago

@danielbmiller Hope you are doing fine these days! I finally got around to test your branch on moving to 4.5.2 - still not sure if we should go to 4.7.2 right away. Sorry for taking so long!

Seems to be working on Linux (tested on Ubuntu pre-20.04 so far only)! Will test Windows soon as well.

brought in the upstream changes to the 4.5.2 branch that I apparently didn't include like I thought I did when branched. This broke the MSI build as there are missing references in .\bin. Building all the targets in batch mode apparently takes care of it, but probably need to figure out what isn't getting called in the build script (I suspect a NuGet package download) that causes things to go pear-shaped.

Did you figure this one out? I am not sure I can follow what exactly you mean here.

danielbmiller commented 4 years ago

Don't have as much physical access to my build environment or testing hardware due to precautions, so waiting on some new hardware to at least create a little one at home. Haven't had a heap of time to look into the build issue due to provisioning for those same precautions, but will hopefully have some time in the coming weeks to take a peek. 4.5.2 is certainly the safe choice in terms of apparent effort to address the immediate issue and overall impact on the user base. I'd be agreeable to putting 4.7.2 on the back burner for now.

Sebastian-Roth commented 4 years ago

@danielbmiller Thank you for getting back so quickly! Sure, things are a little different right now. Take your time.

If we see that 4.5.2 is not enough to get things fixed we might still push on to 4.7.2 then. :-)

Sebastian-Roth commented 4 years ago

@danielbmiller Finally I got around to take some time to update the .NET stuff and SharpZipLib as well. Thank you once again and sorry for the long time it took.