I had Main.xaml where all workflow was defined. It had “Invoke Code” activity where in I had used AsEnumerable extension method for a Data Table. This code was running perfectly.
Now I chose “Extract Workflow” and made a new.xaml, so all my workflow went in new.xaml making Main.xaml empty.
Now I added new flowchart in main.xaml and added “Invoke Workflow File” activity and gave new.xaml path there.
I think you are having an issue that has cropped up elsewhere as well:
In short, the assembly containing the extensions may not have been loaded in the new workflow. You can probably cause it to be loaded by temporarily adding some DataTable activity, as this is probably how it got loaded in the original workflow.
I don’t have 2017.1, but I can confirm that extracting a workflow seem to only put default assemblies there (and maybe those related to used activities, haven’t tested too deep). DataSetExtensions dll is not added.
@badita - did you consider adding it by default or giving a way of adding it other than using a method from it to force load it? Since it’s not a namespace, it’s a little bit confusing for a lot of people of why it’s not working.
Indeed, but this exactly where the (subtle) problem is: it sometimes misses out on declarations that are in the same namespace, but a different assembly. It is currently not clear whether certain extension assemblies are loaded, other than by querying IntelliSense or catching a compiler error with no clear solution.
On examining .xaml content, following line is “missing” from inner.xaml: <AssemblyReference>System.Data.DataSetExtensions</AssemblyReference>
This line gets added if the compiler finds usage of anything from that .dll (namespace is still System.Data), but only during actual writing of the code.
Since System.Data namespace is already present, it cannot be added.
Similar issue I think can happen with System.IO.Compression.FileSystem.dll, as it also has a shared namespace with System.IO.Compression.dll - see this topic.
It seems to work fine when there’s an assembly reference in the .xaml that has the InvokeCode. It’s just that extracting to a workflow does not copy all references (which is good or bad, depending on how you look at it).
There’s a design decision to be made here and honestly I’d lean to ease of use side - overhead is already “high” (relatively speaking) and DataSetExtensions is quite extensively used, so I’d even go as far as to add it by default to xaml’s. That could also solve some issues with intellisense not working correctly until restart when this .dll is added.
I started with a blank workflow and System.Data namespace was already in the Imports list but still the VB.Net code failed to compile (because System.Data.DataSetExtensions.dll is needed). Extracting to a workflow is another story which I will test shortly.