ThinkGeo.com    |     Documentation    |     Premium Support

TargetInvocationException on Deserialize

#1

Hi,


I upgraded to 6.0.0.75 this morning.


Now, when I read back serialized files that were created by a different user using the deserializer, I get a TargetInvocationException for ShapeFileFeature layers because the shapePathFileName value in the file points to another users machine.  This same error applies to GDIPlusRasterLayer.


Typically, I update the values in the PathFileNames after deserialize method returns and hence get past any problems with missing files.  Now, I don't get to this point, so users can no longer share data without editing the serialized file and changing the paths manually.


Unfortunately, I don't seem to be able to continue deserializing when this error occurs.


Prior to this version, this exception was not triggered so it is a recent change.


Is there a way to allow deserialize method to bypass this test?  It's very common to want to exchange our serialization files when work sharing.  If not, then I need a workaround.


Regards,


Damian



#2

Damian, 
  
 Thanks for your post, I think you must have opened the layers before serializing. However, we made a change before 6.0 releases in ShapeFileFeatureSource: the featureSource will keep open after deserializing if it’s open before serializing, but the file needs to be existed in the path which specified in the xml. So we suggest you to close the layer before serializing it in your scenario. 
  
 Thanks, 
  
 Edgar 


#3

Hi Edgar,


Closing the shape layer at the save file event has fixed this issue.  Thanks.


Regarding older serialized files.  These have the IsOpen tag in them for the ShapeFileFeatureSource set to True.  In order for me to fix these files, do you recommend setting this property to False or deleting the entire tag?  I do note that now when I save a file, the IsOpen tag is no longer in the output file for the ShapeFileFeatureSource so I am guessing that deleting it is the better solution.


Thanks,


Damian



#4

Damian, 
  
 Glad to hear that the last post solved your problem. 
  
 Yes, the tag could be deleted. In our algorithm, if one field’s value is the default one, it would not be written to the xml file. 
  
 If you have any questions, please let me know. 
  
 Regards, 
  
 Edgar