Aspose.Tasks 2.4.0.0 ProjectReader.Read() Error

Aspose.Tasks Product Family
1

I am having trouble reading some .mpp files with your latest build of the Aspose.Tasks. I usually get an null reference error but I have also been getting this error as well

"Item has already been added. Key in dictionary: '302' Key being added: '302'"

Sorry but I cannot supply the source file that is causing this error because it has propietary information and cannot seem to replicate the problem when I create a file from scratch.

2

Hi,


We will try to
identify the problem. The issue “302 Key issue” was created on our bug
tracking system and connected to this forum thread.

Could you open your file in Notepad and make a search for string “MSProject.MPP”? The full string I am
looking for can be “Microsoft Project 12.0 MSProject.MPP9” or “Microsoft Project 12.0 MSProject.MPP12” or “Microsoft Project 9.0 MSProject.MPP9” or something like that (some
unprinted symbols can be missed). It will get us information about the mpp file
format and make the problem analyze easy.
3

This is the string I found in the file, with some clean up

Microsoft Project 12.0 MSProject.MPP12 MSProject.Project.9

I hope that helps

4

Hi,


Thank you for the information. According to it the file was created in MS Project 2007 and saved in the same format. Twice less data to check:) Will try to repeat the issue.

Have you tried to load the same file with some previous version of Aspose.Tasks?
5

Hi,


We still can not recreate the issue on our side (fortunately or unfortunately).

Could you check the file by new ProjectReader’s ReadProjectFileInfo methods and show us a result?

The method is new for Aspose.Tasks 2.6.0. You can find a sample in this thread.

6

Ok I downloaded the latest version of Aspose.Tasks 2.6.0.0 and this is what ProjectFileInfo is telling me

  • CanRead: true
  • ProjectApplicationInfo: MSP2003
  • ProjectFileFormat: MPP9

But when I execute the ProjectReader.Read() method I am still getting an this error

Message: "Object reference not set to an instance of an object"
StackTrace: " at x9d5a5f8cb1bea48a.x06ab8cb464ad263f.x06b0e25aa6ad68a9(Task x801bd3a7d5412d70, Hashtable x8f199855adaa4854, Byte[] x7201b70971f98378, Byte[] xf9d37f33bce6fbd5, xfa0847bcee021cf4 x5bab213824e6b068)
at x9d5a5f8cb1bea48a.x8f3e927637419190.x06b0e25aa6ad68a9(Stream xcf18e5243f8d5fd3)
at Aspose.Tasks.ProjectReader.Read(Stream stream)
at NGC.PACE.MSProject.IMS.GetAsposeProjectFile(String SourceFile) in C:\Visual Studio Projects\2008\PACE\NGC.PACE.MPXJ\Aspose.2.x.cs:line 419"

Hope this helps

7

Hi,


Thank you a lot! It looks that the file structure is OK and the issue is on our side.

Will try to resolve it ASAP, sorry for inconvenience.
8

Hello Sergey,

We have the same error with reading a valid project using version 2.7.0.0. Could you give some estimation when this issue may be closed?

Regards,

Evgeny

9

Hi Evgeny,


Could you please provide me with the project data? In case the data is private, you can put it in separate private thread or send by mail.

The problem is that when I find and correct some issue I am just don’t know is that the issue you have.

Before you can check that Aspose.Tasks has to read the project format like in the sample in this thread.

10

Hello Sergey,

Thank you for quick reply. Hope that correction will be quick as well. )

I have sent you example of file by e-mail. There is one thing about this file: after opening file in MS Project 2007 and closing it without doing any changes, MS Project proposes to save changes. You can agree and save it in 2003 format. After this ProjectReader reads updated file without errors. If you compare both files (original and modified) in some editor, you will see some minor differences. I believe these could help you investigate the issue.

There is data from ProjectFileInfo class: CanRead: true, ProjectApplicationInfo: MSP2003, ProjectFileFormat: MPP9.

Stack trace: at x9d5a5f8cb1bea48a.x06ab8cb464ad263f.x06b0e25aa6ad68a9(Task x801bd3a7d5412d70, Hashtable x8f199855adaa4854, Byte[] x7201b70971f98378, Byte[] xf9d37f33bce6fbd5, xfa0847bcee021cf4 x5bab213824e6b068)
at x9d5a5f8cb1bea48a.x8f3e927637419190.x06b0e25aa6ad68a9(Stream xcf18e5243f8d5fd3)
at Aspose.Tasks.ProjectReader.Read(Stream stream)
at ...

Regards,

Evgeny.

11

Hi Evgeny,


Now I can repeat the issue on my side. Thank you for the data.

See temporary Aspose.Tasks 2.7.0.1 version attached. It works OK with the data on my side. Finally, the issue will be fixed in the next official release in end of April.

I think it would be impossible to find the issue source without the data. Thank you again and sorry for inconvenience.
12

Sergey,

Thank you for fix. It works well so far. Look forward to next release.

Regards,

Evgeny.

13

The issues you have found earlier (filed as 13684) have been fixed in this update.

This message was posted using Notification2Forum from Downloads module by aspose.notifier.
14

I am still getting various key errors from various files from your latest update 2.8.0.0

Here are some of the messages I am getting

"Item has already been added. Key in dictionary: '410' Key being added: '410'"
"Item has already been added. Key in dictionary: '427' Key being added: '427'"

Plus I am still getting this error with MANY large files "Object reference not set to an instance of an object."

I really really wish I could provide you a source file that is causing the error but I just cannot because it contains proprietary company information. Any attempt I have at creating smaller versions of the files I don't get the error. In all my files cases the ProjectFileInfo returns CanRead = true

Please double check that you are properly using try catch blocks to handle null references. I will try to see what I can do to get you a smaller sample file that is triggering this error to help you guys out. I know how hard it is to trouble shoot problems when you cannot replicate the behavior on your end

15

Hi,


Thank you a lot for your feedback. Sorry that the problem is still unresolved.

All what we can do in the case it is just keep adding new projects in our NUnit testing engine. Now we have more than 300 different projects in it, some of them are pretty large, but we very glad to any opportunity to get some more.

We don’t use any try-catch block while read project data as the exception means that we possibly misinterpret some piece of data and we don’t want to fill the project by some incorrect information. It will be to easy solution.

Sorry for inconvenience.
16

I can understand about using try-catch blocks so it doesn't ignore data from the file but you could throw a unique Exception that gives more information about what returned null instead of the generic null reference error message

Looks like you are planning on doing something like that in this thread
<A href="https://forum.aspose.com/t/6651</A></P> <P>So this would be <FONT color=#ff0000><STRONG>EXTREMELY</STRONG></FONT> helpful on my end so I could trouble shoot more problems on my end so you don't have to randomly hunt these things down</P>

17

Hi,


I don’t quite understand what information we could provide here.

I don’t think that information like ‘byte with offset 0x12345 has wrong value’ could be helpful without seeing all data for us and what difference it could make for you.

As a variant we can create a console application which will cut some binary data from the MPP you have problem and save it to disk. If you are agree to send some parts of the project to us for the problem investigation on our side I think we could understand the problem and resolve it faster.

Only some part of the project information (e.g. tasks only, without resources and assignments) can be restored from the data.
18

Hi Sergey,

I agree that 'byte with offset 0x12345 has wrong value' is not helpful.

However, good error handling, as cborden20 pointed out, is very important to keep development going.

I would imagine that reading an MPP is similar to reading XML as it's a stream of data with some structure.

I would hope that the way you read the files (MPP and XML) provide a context for knowing how to interpret any error that may some up.

The error may be interpreted as 'we've not implemented this yet' or 'missing value' for a Task or a Resource or Assignment. It is possible to generate your own exception values and messages or raise an event.

It would be nice also to be able to continue and ignore the error to be able to check the entire file for other problems.

Any errors you define for the XML would probably be applicable to the MPP - maybe using a similar XML tag to indicate the type of data would be useful as we would only need one type of error handling on our side.

Once again, I have my application log all errors so I can get an idea of the fault internally. I also decide the severity of the problem - sometimes blocking any further processing or at other times allowing the application to continue.

Please take a step back and help us understand where the problem might be. This will help us provide better samples to populate your test framework.

Also, please make sure that any problems, such as the key missing problem, or object not found are eliminated and a sensible pointer to the problem is provided. These problems are totally under your control ... note I don't believe any performance reduction due to improved error handling will be noticed (others please comment).

I'm looking forward to improvements in error handling and will test these immediately as released.

Regards, Bruce

19

Hi Sergey,

Here is another thought ... maybe there could be an error log or trace mode built into the component that we could enable or disable. This way the component could log where it was in processing the file so we can get an idea of where to look in the source file.

If we can also indicate, keep going after error, then all errors can be seen or a pattern can be seen.

Just a thought..

Regards, Bruce

20

I know it would be really helpful if I could provided my source file for unit testing but that is just not an option since it contains Proprietary Governmental data. Even if I send it to you through a private message I would still be violating company policy. So I have to have some way to narrow down where the error in the Aspose.Tasks.ProjectReader.Read() method is occurring so I can provide you feed back. Every time I try to create a smaller version of the file removing all Proprietary information I don’t get the errors. So I am having a hard time replicating the same problem.

If the error is returning a null reference it must be occurring on something that you are not casting or converting properly, or maybe you are trying to reference a property of an object that wasn’t instantiated properly. It shouldn’t be difficult to place a couple try, catch, throw blocks to return more relevant information in the exception message about the particular location of the error occurring. Then I would be able to find the exact line item and column creating the problem and help you guys improve your product.

If we cannot find a resolution to this problem then we will have to unfortunately drop you as a solution and move forward with one of your competitors