Mono Support

Aug 18, 2011 at 11:58 AM
Edited Aug 18, 2011 at 11:59 AM

Hi :)

I am a contributor of FubuMVC related projects and we are using DotNetZip. After upgrading from v1.9.1.5 to v1.9.1.8 some of the unit tests start to fail on Mono on Unix based systems.

I think I have an idea of where the problem is as the stack trace points to Ionic.Zip.ZipEntry.InternalExtract.

Looking through your code I can see that you do something like: 

 // workitem 10639                outFileName = outFileName.Replace("/","\\");

inside ValidateOutput.

That is probably the cause, because you are not using Path.DirectorySeparatorChar (or Path.AltDirectorySeparatorChar).

This, along with not using Path.Combine, is the most common problem with regards to Mono compatibility issues on other platforms.

Aug 20, 2011 at 12:03 PM

No taker? :/

Aug 20, 2011 at 5:38 PM

I managed to fix the issue with the following changes in ZipEntry.Extract.cs::ValidateOutput

                var f = FileName.Replace(Path.DirectorySeparatorChar, Path.AltDirectorySeparatorChar);

               ...

               
if (f.IndexOf(Path.VolumeSeparatorChar) == 1)

                    f= f.Substring(2);

               ...

               
// workitem 10639

                outFileName = outFileName.Replace(Path.AltDirectorySeparatorChar, Path.DirectorySeparatorChar); 

Aug 23, 2011 at 10:56 AM

Any news of this? We also rely on DotNetZip for Mono.

Aug 23, 2011 at 3:05 PM

I'm very disappointed to see the lack of response in here. Are there any takers for this? We're happy to provide some Mono support and compliment your team on this :)

Aug 23, 2011 at 3:37 PM

+1, one of our projects depends on DotNetZip and we require the Mono support as well, we need this fix pulled into the codebase ASAP.

Aug 25, 2011 at 12:29 AM
Edited Aug 25, 2011 at 12:31 AM

It would be nice to get some sort of feedback :)


Are we better off forking this project and put it on GitHub in order to ensure Mono compatibility? 

Aug 25, 2011 at 4:04 AM
ahjohannessen wrote:

It would be nice to get some sort of feedback :)


Are we better off forking this project and put it on GitHub in order to ensure Mono compatibility? 

+1. We need a response to this.

Coordinator
Aug 25, 2011 at 2:39 PM

> we need this fix pulled into the codebase ASAP.

Well ok! Listen, I appreciate your concern.  But... It seems like you fixed the problem for yourself. Why does it need to be in the codebase "ASAP"?  I don't understand the urgency.  Can you explain.

> We're happy to provide some Mono support and compliment your team on this :)

I see this a lot.  Comments like "Hi everyone!" OR "Hello, guys!"   or  some reference to  "your team."   Look, there's no "team".  There's just me. One guy. Just one.  So... When you say stuff like "where's the response?!?!"  it's not like there are 7 people volunteering to respond to these questions. It'd be nice if *someone besides me* contributed answers once in a while on this forum.  Or contributed in a way that did not produce more demands for my time.  Regardless, I answer the ones I can, and I answer when I can.  

If you are interesting in contributing, contact me and say so. I will not let just anyone onto the project. I'll need to evaluate your work.  I haven;t seen anyone submit patches via the codeplex system.  In other words: so far I don't have any way to evaluate competency or goodwill.  Obviously, I will not add contributors if I am not confident in their competency.

Getting back to the core issue, regarding the use of Path.SeparatorChar in the method in question, the fix proposed here sounds reasonable. Problem is, I don't have a mono/linux workstation, I don't have a VM, and I don't have the ability to test the fix you are proposing.  I also will not expand my testing effort beyond the existing work I'm doing.  I am spending enough time on this; I will not do more.  It may be a simple matter of installing Ubuntu and Mono and then running a test suite, but. . . I am not willing to do that.

I'm glad you guys are using the library on Mono. Really.  I'm pleased to hear it.  I hope it's useful. I'll do what I can to make that easy. To encourage it.  I can insert mon-related fixes into the codebase that you, or anyone in the community, proposes.  But I have no Mono tests for them, and since you already have the fix, I don't see the benefit to you, if I insert the fix in a changeset here, "ASAP". 

I'll be interested to hear your feedback.

Coordinator
Aug 25, 2011 at 2:39 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 26, 2011 at 12:11 AM
Edited Aug 26, 2011 at 1:11 AM

First of all, thanks for creating a task item for this. Appreciate it :)


Some remarks:


- One guy: Have you considered, and do you, wish for more contributors? If so, I would suggest you to migrate to DVCS -  It is *far* easier to collaborate through DVCS than with SVN/CVS/TFS/etc. I think you would have a much easier task accepting/rejecting pull requests and such. Moreover, this would give you a better tool to evaluate quality / goodwill and grow trust. We use GitHub for FubuMVC and it is a blast :)


- Continuous Integration: I wonder if you have considered using TeamCity for CI builds? CodeBetter.com provides free TC accounts for OSS projects. This would allow you to automate different build configurations and get a faster feedback cycle. "Works on my machine" is not an issue with CI.

 

- ASAP: Maintaining a custom build of DotNetZip is tiresome and error-prone in the long run, something we wish to avoid because there are many people involved - easy for someone to blindly update to your latest code that might not have some necessary fixes.

 

- Competency: Yep that is a valid concern - In the end, I think you would become a more happy camper if you got some serious committers/maintainers that could take some burden off you - One step in this direction is going DVCS and improve your current setup: no CI, convoluted versioning control, no easy way to issue pull requests.

 

- Mono support: If the build ceremony is streamlined and running unit tests is easy then contributing code that is working and has quality is much more likely - The ability to create a fork + combined with pull requests makes it easier for someone to contribute, e.g. Mono compatibility.


Hope this is of some value.

Aug 26, 2011 at 2:09 PM

Thank you for this post, I had exactly the same problem after editing the code as suggested we now have this working under Mono!

Aug 26, 2011 at 8:25 PM

@Cheeso,

First of all, I would like to apology, I never meant to dictate how you should use your valuable time, so, sorry for the "ASAP" part.

On the other hand, you don't have to deal with all this by yourself, there are many projects out there that depend on your library...as other people is suggesting, you could take a stab at some DVCS hosting like github to get some contributors to help you to maintain the codebase.
I know the OSS .Net community  would be willing to give you a hand at it.

Once again, my apologies for my rude words.

And finally, thanks for releasing this tool to the OSS .Net community, we really appreciate that.

Kind regards,

Jaime.