Key cannot be Null. Parameter Name: Key

Hi,

I am reading a microsoft project xml file and have received the following error:

Key cannot be Null. Parameter Name: Key

The error occurs on:

mprjDocument = prdrReader.Read(pfstFile)

I do not have a sample to send that recreates this problem.

Any idea where I should be looking to isolate this problem.

Regards, Bruce

Here is an extract from the application error log:

Source="mscorlib" Description="Key cannot be null. Parameter name: key">

<CallStack> at System.Collections.Hashtable.get_Item(Object key)

at xa1fe07b53ec150fc.x262765c9bc37137f.x5586b6ed3aa176aa(XmlElement xb330e6c5348f97c7, Object xa59bff7708de3a18)

at xa1fe07b53ec150fc.xdfba7dd89cb7c399.x94327e5699969182(XmlNodeList x781cc54ff626ff75, x2dbf098d6814a03c xe134235b3526fa75, Type x0c56543344513108)

at xa1fe07b53ec150fc.x3bcd232d01c14846.x06b0e25aa6ad68a9(Project xb0108c8c2308c091, Stream xcf18e5243f8d5fd3)

at Aspose.Tasks.ProjectReader.Read(Stream stream)

at ChangeAide.clsMSP_AsposeTasks.Project_FileOpen(String vstrFileName, Boolean vblnReadOnly) in D:\Projects\ChangeAide\clsMSP_AsposeTasks.vb:line 480</CallStack>

</ErrorEntry>

Hi Bruce,


Could you please provide us with the project’s file you have the error. It would help us understand the problem.

I can see from the call stack that you met the problem when reading XML data. We are using hash tables there to convert integer values from XML to Aspose.Tasks enumeration values. And it looks like we got null value instead of the integer.

I can repeat the problem if for example the XML has empty task’s type element:

In this case we will try to convert the empty Type’s value to task’s type (fixed units, fixed work or fixed duration) and get the exception. According to MS Project Data Interchange Schema one of the 0, 1, 2 integer values here is required. Of course, it is just a suggestion and the project’s XML data is required to understand the issue.


Hi Sergey,

Many thanks for the response. I've checked for the following in the XML:

<Type All looked valid across the entire project - all numbers valid

or Does not exist in the file

></ Does not exist in the file.

did exist - now = does exist. (I've even deleted these and no luck).

This is the largest MS Project XML file I've seen (over 44,000 lines). The file validates against the MSP 12 Schema without problems. The file opens in MS Project - however, MS Project does report a circular dependency ... I've not checked this out yet.

As I indicated in another post, I really need better error handling as the file is being read ... to avoid guessing what the problem might be.

I cannot submit this file as it's a customer live project. I'll continue to isolate ... and see if I can eliminate the circular dependency.

I also think they may be using some features that might not be implemented yet ... could this error arise if some enterprise tags are used? or other not implemented yet tags?

I've also noticed they don't have a task UID = 0.

Any other thoughts appreciated!!

Regards, Bruce

Hi Bruce,


I think we can update the XML parsing and just ignore the elements with null values like MS Project does in any case even when the value is required according the schema description. Hope it will resolve the problem.

I have created a new issue ‘Ignore XML elements with no values.’ with ID = 16459 and linked it to this forum thread. We are going to fix it in this month release. I will provide you a temporary build as it be ready.

We are planning to put some information about XML parsing exception in the exception’s message. I will create the issue and link it to your correspondent thread.

Sorry for inconvenience.

Hi Sergey,

Many thanks... Just one more note about error handling ...

Given that automation is slow (unless an addin) and Aspose.Tasks is fast, adding extra code to check for null references or missing objects when reading xml to protect and report errors will most likely have minimal impact on performance.

I would prefer to have an Aspose.Tasks notice of an error rather than Microsoft.

Regards, Bruce

Hi Sergey,

I think I've found one of the problems ... you were very close.. This line was missing from all resource elements.

<Type>1</Type>

As is an optional element, this passed the schema validation.

I'm looking forward to better error handling ... please make this a priority.

A related problem is exactly that there are very few required elements in the MS Project XML Schema. Any application following the schema does not need to provide all elements (this was raised a while ago). A default value of 1 could be used if is missing.

Maybe there could also be a file or set of defaults that can be set or an event generated where we can provide a default value and allow the processing to continue.

Unless a capability to handle this type of problem is made, we will continually be handling exceptions and changing the component.

Any optional element probably needs some default value..

BTW: The assignments are also very lean ... (not many elements)... here is a sample:

<Assignment>

<UID>302</UID>

<TaskUID>258</TaskUID>

<ResourceUID>-65535</ResourceUID>

<ActualCost>0</ActualCost>

<ActualWork>PT0H0M0S</ActualWork>

<Cost>0</Cost>

<Delay>0</Delay>

<OvertimeWork>PT0H0M0S</OvertimeWork>

<RemainingWork>PT0H0M0S</RemainingWork>

<Units>1</Units>

<Work>PT0H0M0S</Work>

</Assignment>

Hope this helps ... a hotfix would be helpful so I can continue to test the interface (e.g. read resources so can test the assignments.)

Regards, Bruce

Hi Bruce,


I am going to build an interim release with some logging and exception describing information for both XML and MPP next week.

Sorry for delay.

Hi Sergey,

Many thanks for an interim release with some logging and exception description. I'm looking forward to testing this.

I also wanted to clarify the following:

'Ignore XML elements with no values.'

I would have described this approach slightly differently ...

'Provide default values when optional XML Elements are missing'.
(or unhandled elements / attributes are found (not implemented yet) - like Stubs).

(required elements, unhandled elements (those you don't have a processor for) or elements you need to make the interface work should be flagged and optionally allow my application to provide a default value) and if necessary save the XML to pass through to the output.

NOTE: For new projects, I have dealt with this problem by using a 'new' template. This has the minimum tags and defaults I need ... and the user can tailor this to their own needs.

I'm now reading a lot of XML generated by different tools and am generating output for a number of different tools (e.g. many of the MS Project Readers. There are some MS Project Readers that cannot read the XML from Aspose.Tasks). So the complexity of interface compatibility is increasing. This is why a more robust exception handling on the input and even filtering on the output may be required.

NOTE: I am not asking that Aspose.Tasks fully support all of these other tools ... just provide a complete and safe implementation of the various MS Project XML Schema -

Re: Requirements for development...

I'm also learning about a new definition of 'Test Driven Development'. All I was suggesting in some of my other notes, is that by sharing your plans (at a more detailed level) I will have a better idea of what has been developed and what is remaining and priorities for solutions - rather than learning from my customers that something has not been implemented yet or potentially damaging a customer plan and then requesting an emergency 'new requirement'.

I do understand the complexity of product development. I also understand that if you want to develop using Agile principles that even more transparency / visibility is required about requirements, capabilities of the current version, and priorities needs to be shared with your users.

Thanks for your efforts...

Regards, Bruce

Hi Bruce,


I have created the interim 2.8.0.5 release and attached it to this thread. Could you please try it. I have updated some XML elements processing as well. Some of them are not required any more, like tasks link’s Type.

As you may understand, current development plans for the product are influenced
by a variety of factors like customer’s requests, priority support requests,
market demand, competitors etc. Right now we do not provide customers with
detailed information about our plans and may only take their requests into
account and plan based on current priorities.

As soon as some request is
implemented, you are notified (as a part of monthly release procedure) about it
and at that time, it’s possible to check release notes to know to what extent it
has been done, however even though we are doing our best to cover all possible
data scenarios by our tests, sometimes it is still it still possible that some
specific file content would cause issues, so the best way to diagnose such
issues is to be able to receive such files.

You can get some product’s updates from this Blog too.

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


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