1
Vote

Importing of Custom Type Initializers fails

description

The source code at:

Microsoft.Research.ScientificWorkflow.TridentComposer.ImportActivityProxy line 121
"WorkflowComposer.ImportTypeInitializer(this.fileReferences, this.registryConnection);"

indicates that an attempt is made to import custom type initializers found in referenced assemblies when activities from said assemblies are imported.

This call is made after the assemblies have been imported into the registry.

One of the first lines of code which imports the custom type initializers at:

Microsoft.Research.ScientificWorkflow.TridentComposer.ActivityComposer line 694
"if (!ActivityComposer.CanContinueWithImport(references, assemblyPath))"

will almost always evaluate to True and cause the custom type initializer import logic to exit before importing the initializers contained within the assembly. This means custom type initializers from that assembly can never be imported. The line calls a method which checks to see if the assemblies have been imported into the registry (and they have because the code to import the activities was run just prior).

I have some thoughts on a possible fix should you concur with my assessment.

Thank you for your time.

Rob

comments

abhisheks wrote Jan 22, 2013 at 5:45 AM

Yes, community users' contribution is what is needed for an open source product. You may upload the fix as a patch which will be accepeted in main build after testing.

Also, you can see this thread

http://tridentworkflow.codeplex.com/discussions/349717 (Type Initializer For Fileinfo Doesn't work ) which has the same issue.

Thanks!

rbridgart wrote Feb 6, 2013 at 4:25 AM

After some more work I found that a much more substantial code change would most likely be required to address the issue mentioned above than I originally thought.

In reassessing the situation I discovered that as long as I create my CustomTypeInitializers in a separate assembly to my Activities, then the problem doesn't arise.

Assuming Trident was intentionally designed for this to be the case (keeping the Initializers and Activities in different assemblies), I consider the issue resolved.

abhisheks wrote Feb 6, 2013 at 10:53 AM

Assuming Trident was intentionally designed for this to be the case (keeping the Initializers and Activities in different assemblies), I consider the issue resolved.

No, I don't think so because I have tried this way and not succeeded.

Can you put some light on this issue with working code. This will be a good contribution to the community as there are a couple of open discussions and many other might also be facing this issue.

http://tridentworkflow.codeplex.com/discussions/349717
http://tridentworkflow.codeplex.com/discussions/237674

wrote Feb 14, 2013 at 8:04 PM