Workflow designer fails to load when referencing netstandard 2.0

[darrensteadman]

I previously reported issue #1522 when I was having problems getting workflows to compile when referencing netstandard 2.0. The work around documented solved that problem for me however I've now gone to modify some of the workflows in my project and when I try to load the designer I get the following.

System.IO.FileNotFoundException: Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified. File name: 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' at System.Signature.GetSignature(Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType) at System.Reflection.RuntimeMethodInfo.FetchNonReturnParameters() at System.Reflection.RuntimeMethodInfo.GetParametersNoCopy() at System.Reflection.RuntimePropertyInfo.GetIndexParametersNoCopy() at System.Reflection.RuntimePropertyInfo.GetIndexParameters() at System.Xaml.Schema.TypeReflector.GetNonIndexerProperty(String name) at System.Xaml.Schema.TypeReflector.LookupProperty(String name) at System.Xaml.XamlType.LookupMember(String name, Boolean skipReadOnlyCheck) at System.Xaml.XamlType.GetMember(String name) at MS.Internal.Xaml.XamlContext.GetDottedProperty(XamlType tagType, String tagNamespace, XamlPropertyName propName, Boolean tagIsRoot) at MS.Internal.Xaml.Parser.XamlScanner.ReadPropertyElement(XamlPropertyName name, XamlType tagType, String tagNamespace, Boolean isEmptyTag) at MS.Internal.Xaml.Parser.XamlScanner.ReadElement() at MS.Internal.Xaml.Parser.XamlScanner.ProcessCurrentXmlNode() at MS.Internal.Xaml.Parser.XamlScanner.DoXmlRead() at MS.Internal.Xaml.Parser.XamlPullParser.d11.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__9.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__12.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__13.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d11.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d9.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d12.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d13.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__11.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d9.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d12.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d13.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d11.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__9.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__12.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__13.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d11.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d9.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d12.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d12.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__8.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d5.MoveNext() at MS.Internal.Xaml.Parser.XamlPullParser.d__4.MoveNext() at MS.Internal.Xaml.NodeStreamSorter.MoveNext() at System.Xaml.XamlXmlReader.Read() at System.Activities.Debugger.XamlDebuggerXmlReader.Read() at System.Activities.XamlIntegration.DynamicActivityXamlReader.Read() at Microsoft.Activities.Presentation.Xaml.ActivityTemplateFactoryBuilderReader.Read() at Microsoft.Activities.Presentation.Xaml.ViewStateXamlHelper.StripViewStateElement(XamlReader inputReader, Dictionary2& viewStateInfo, Dictionary2& viewStateSourceLocationMap) at Microsoft.Activities.Presentation.Xaml.ViewStateXamlHelper.ConvertViewStateToAttachedProperties(XamlReader inputReader, ViewStateIdManager idManager, Dictionary2& viewStateSourceLocationMap) at Microsoft.Activities.Presentation.Xaml.WorkflowDesignerXamlHelper.DeserializeString(String text, DeserializationMode mode, IList1& loadErrors, Dictionary2& sourceLocations) at Microsoft.Activities.Presentation.Xaml.WorkflowDesignerXamlHelper.DeserializeString(String text, IList1& loadErrors, Dictionary`2& sourceLocations) at System.Activities.Presentation.WorkflowDesigner.Load()

WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Has this been fixed with the PRs to fix my original bug? Does anyone have a work around I could use for the moment to get myself going again?

[darrensteadman]

Works in VS 2017 15.5

[SuhailCloud]

My VS edition is Community 2017 version is 15.5.2 and the issue remains the same. Any idea?

[darrensteadman]

I realised just before Christmas that this isn't totally fixed but I didn't have time to post back an update.

Basically what appears to be fixed is workflows will now load if the project references netstandard but the workflow itself doesn't use it.

I did a bit more investigating and it would appear that if you use a type as an input or output or variable in the workflow xaml and that type is held in an assembly that is netstandard then the workflow designer fails to load.

[livarcocc]

@Pilchie can you help direct this bug? Not sure what the SDK itself is doing wrong to cause this.

[darrensteadman]

I was just wondering if any progress had been made on this or if there was a potential work around while a fix was being sorted out?

[livarcocc]

@darrensteadman can you still repro this on the latest 15.6 release? If so, can you provide some repro steps or a repro repo that we can clone, open in VS and hit this?

[darrensteadman]

I can no longer repro this on my machine however a co-worker can. Unfortunately he is off ill at the moment. When he returns I'll work with him to create a repo that can repro the issue on his machine.

[github-actions[bot]]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.

[github-actions[bot]]

This issue will now be closed since it has been labeled 'stale' without activity for 30 days.