En utilisant MPXJ dans .NET

Question

Je suis en train de travailler avec des fichiers MS Project dans une application ASP.NET, et suis tombé sur le bibliothèque MPXJ , qui a commencé en Java et a été converti en une version .NET ainsi. Il fonctionne très bien dans .NET, mais la difficulté je trouve avec elle est que toutes ses méthodes utilisent des types de données Java et non natifs les .NET. Cela signifie que pour des choses comme le formatage d'une date ou numéro est retourné, je dois lire sur java.text.NumberFormat, et les autres moyens de style Java pour interagir avec les choses.

Alors ma question est: ce que je fais quelque chose de mal, ou dois-je essentiellement à programmer dans « style Java » pour interagir avec cette bibliothèque dans .NET? Je peux certainement le gérer, mais je ne suis pas sûr de ce que cela signifie pour l'avenir maintenabilité quand quelqu'un regarde mon code.

Je suppose une autre partie à cette question serait la suivante: est-il une autre bonne, libre, mécanisme permettant d'interagir avec les fichiers .mpp en plus MPXJ? Les deux autres options que j'ai vu sont: a) l'installation de MS Project sur le serveur et en utilisant le fournisseur OLEDB (ne peut pas installer car il est l'hébergement partagé), et b) l'achat d'élément Aspose.Tasks (au moins 600 $).

Answer 1

Je maintiens MPXJ, donc je pense qu'il pourrait être utile de dire bonjour et vous faire savoir ce que j'ai envisageais.

Pour répondre à votre première question, je ne pense pas que vous faites quelque chose de mal, je l'ai aussi cherché des façons de servir de médiateur entre les types Java et .Net lorsque vous utilisez la version IKVM de MPXJ et il ne semble pas être des solutions établies sur le marché. Je suis toujours bien!

Je suis actuellement en train d'ajouter le soutien du projet 2010 à MPXJ, mais une fois clairement que je vais enquêter sur l'utilisation d'une usine de typage au sein MPXJ qui, dans la version Java vous donnera les types Java natifs de l'API, et dans la version .Net IVKM vous donnera prolongé IVKM types de l'API qui mettent en œuvre des interfaces .Net familières.

Le but est d'éviter les développeurs d'avoir à penser à la conversion de type, ces types modifiés devraient « travailler juste » dans la plupart des cas. A défaut que je peux fournir des services de conversion de type, mais je préférerais que cela soit invisible pour les utilisateurs de la version .Net.

Toutes mes excuses que je ne peux pas offrir une solution immédiate - mais je suis au courant du problème