views:

214

answers:

1

I'm trying to work with MS Project files in an ASP.NET application, and came across the MPXJ library, which started out in Java and has been converted to a .NET version as well. It works fine in .NET, but the difficulty I'm finding with it is that all its methods use Java data types and not native .NET ones. This means that for things like formatting a date or number that is returned I have to go read up on java.text.NumberFormat, and the other Java-style ways to interact with things.

So my question is: am I doing something wrong, or do I basically have to program in "Java style" to interact with this library in .NET? I can certainly manage it, but I'm not sure what it will mean for future maintainability when someone looks at my code.

I guess another part to this question would be: is there any other good, free, mechanism for interacting with .mpp files besides MPXJ? The other two options I've seen are a) installing MS Project on the server and using the OLEDB provider (can't install because it's shared hosting), and b) buying Aspose.Tasks component (at least $600).

A: 

I maintain MPXJ, so I thought it might be useful to say hello, and let you know what I've been considering.

To answer your first question, I don't think you are doing anything wrong, I've also been looking for ways to mediate between Java and .Net types when using the IKVM version of MPXJ and there don't seem to be any established solutions out there. I'm still looking though!

I'm currently in the midst of adding Project 2010 support to MPXJ, but once clear of that I'm going to investigate the use of a datatype factory internally within MPXJ which in the Java version will give you native Java types from the API, and in the IVKM .Net version will give you extended IVKM types from the API which implement familiar .Net interfaces.

The goal is to avoid developers having to think about type conversion, these modified types should "just work" in most cases. Failing that I can provide type conversion utilities, but I'd prefer this to be invisible to users of the .Net version.

Apologies that I can't offer an immediate solution - but I am aware of the issue!

Jon Iles
Thanks for responding, Jon. I'm just happy that MPXJ even exists, so I guess I'll just suck it up and learn a little Java! I had considered making .NET wrapper classes for the MPXJ classes that would do the conversions and return .NET native types, but for the limited use I have for the component I couldn't justify the time involved.
patmortech