locked
WF 4.0 - Custom Typed OutArgument does not seem to work for x64 RRS feed

  • Question

  • Hi, I have got a very simple x64 project in VS 2010. there are two files added to it. one is Class1.cs and other one is Activity1.xaml. since i am using designer to add a custom typed OutArgument in the Activity1.xaml, it shows me the name of the assembly but i don't seem to see an option to select Class1. when i change configuration from x64 to x86, it lets me add the Class1. Is there anybody know what's going on?
    Moiz
    • Edited by Moiz Dhanji Tuesday, February 22, 2011 4:02 AM More Clear Message
    Tuesday, February 22, 2011 1:40 AM

Answers

  • Microsoft QA team - If you want to join, there are definitely openings here, indeed why not? :)

    I have never actually done performance comparison for assemblies resulting from AnyCPU vs x64 build of managed code, however, I would guess there is normally no difference. And that the platform you choose just sets a flag, it doesn't actually alter the generated code.

    Here is some info to back this up quoted from a quickly 'binged' source

    "The meaning of these options is often misunderstood. Based on their names, one might think that the compiler will generate code differently based upon the setting. However, the C# and VB.net compilers only generate IL code that is taken to native code by the CLR at runtime using the just-in-time compiler... The fact is that this setting actually does not affect the build of the assembly in any way except to set the platform status information on the assembly’s CLR header. In other words, the Platform Target setting is meant to communicate the platform that the developer intends to be compatible with."

    (In this case I guess the bug is considered 'by design'.)

    So in other words, platform target for managed code isn't the same as setting a compiler target for unmanaged code, where it would affect which machine instructions are generated, and if 'AnyCPU' works for you, I would recommend you to use that setting.

    Tim

    • Marked as answer by Moiz Dhanji Wednesday, February 23, 2011 2:39 AM
    • Unmarked as answer by Moiz Dhanji Wednesday, February 23, 2011 2:39 AM
    • Marked as answer by Moiz Dhanji Wednesday, February 23, 2011 2:39 AM
    Tuesday, February 22, 2011 6:38 PM

All replies

  • The default accessibility of Class1 is internal if no access modifier is specified (and I guess it's just your case). So even if you selected Class1 in type browser in x86 project, the build will not pass.  Inaccessible members should not present in type browser, it should be a bug in x86.

    In X64 project, you can simply add a public before Class1, have a build, then you can see 'Class1' in the type browser.

        public class Class1
        {
            //....
        }
    Tuesday, February 22, 2011 4:13 AM
  • i have double checked one more time. it is public for sure. its not a problem with the modifier. when i change project configuration to x86, it allows me to select Class1 however, as soon as i changed it back to x64, only assembly name gets displayed.
    Moiz
    Tuesday, February 22, 2011 4:32 AM
  • Interesting, seems like I can repro by the following steps:

    1) start VS
    2) new ActivityLibrary (i guessed the project type since you say Activity1)
    3) open project properties, go to build tab, set platform target to x64
    4) add a new class Class1, add the modifier 'public'
    5) build
    6) open Activity1

    Can I add an InArgument of type Class1 to my activity (Activity1) in the same project? Nope. It does not appear in the type browser.

    Is this a bug? I guess so. But I wonder why it might be happening? VS which is editing the activity definition is all in a x86 process, maybe it is refusing to load the x64 assembly you generated into the workflow designer?

    I wonder if we can reference the type by tricking the designer? Here is something else I tried out

    7. switch platform target back to any CPU
    8. add the argument (yay, we can do it!)
    9. build, everything builds OK
    10. switch platform target to AMD64 again
    11. build, everything builds without error
    12. try to open Activity1 again

    Then we get:

    System.Xaml.XamlException: 'The type ‘InArgument(local:Class1)’ of property ‘argument1’ could not be resolved.' Line number '3' and line position '34'.
       at System.Activities.XamlIntegration.DynamicActivityXamlReader.BufferedPropertyList.ActivityPropertyHolder..ctor(DynamicActivityXamlReader parent, XamlReader reader)
       at System.Activities.XamlIntegration.DynamicActivityXamlReader.BufferedPropertyList.BufferDefinitions(DynamicActivityXamlReader parent)
       at System.Activities.XamlIntegration.DynamicActivityXamlReader.ProcessCurrentNode()
       at System.Activities.XamlIntegration.DynamicActivityXamlReader.Read()
       at System.Xaml.XamlServices.Transform(XamlReader xamlReader, XamlWriter xamlWriter, Boolean closeWriter)
       at System.Activities.Presentation.WorkflowDesigner.DeserializeString(String text, Boolean errorTolerant, IList`1& loadErrors)
       at System.Activities.Presentation.WorkflowDesigner.DeserializeString(String text, IList`1& loadErrors)
       at System.Activities.Presentation.WorkflowDesigner.Load()

    Again it seems to point to everything working fine up to the point where we try to load an x64 assembly (which should mean compatible with x64-only) into an x86 VS process.

    Additional thing it would be possible to try, although I haven't energy right now, would be whether this scenario works in a 64-bit rehosted app.

    Is choosing AnyCPU as your project's platform target instead of x64 an option for you? It seems like the easiest solution to your problem.
    Tim

    Tuesday, February 22, 2011 8:07 AM
  • Thanks Tim for your answer and reproducing the problem. Are you saying i should have been in the Microsoft QA team .. no just kidding :))

    honestly, i don't know what would be the performance penalties for switching to AnyCPU. even though its an option for now but just wondering if WF team can fix it at their earliest convenience.

    Moiz



    Tuesday, February 22, 2011 1:43 PM
  • Microsoft QA team - If you want to join, there are definitely openings here, indeed why not? :)

    I have never actually done performance comparison for assemblies resulting from AnyCPU vs x64 build of managed code, however, I would guess there is normally no difference. And that the platform you choose just sets a flag, it doesn't actually alter the generated code.

    Here is some info to back this up quoted from a quickly 'binged' source

    "The meaning of these options is often misunderstood. Based on their names, one might think that the compiler will generate code differently based upon the setting. However, the C# and VB.net compilers only generate IL code that is taken to native code by the CLR at runtime using the just-in-time compiler... The fact is that this setting actually does not affect the build of the assembly in any way except to set the platform status information on the assembly’s CLR header. In other words, the Platform Target setting is meant to communicate the platform that the developer intends to be compatible with."

    (In this case I guess the bug is considered 'by design'.)

    So in other words, platform target for managed code isn't the same as setting a compiler target for unmanaged code, where it would affect which machine instructions are generated, and if 'AnyCPU' works for you, I would recommend you to use that setting.

    Tim

    • Marked as answer by Moiz Dhanji Wednesday, February 23, 2011 2:39 AM
    • Unmarked as answer by Moiz Dhanji Wednesday, February 23, 2011 2:39 AM
    • Marked as answer by Moiz Dhanji Wednesday, February 23, 2011 2:39 AM
    Tuesday, February 22, 2011 6:38 PM
  • Thanks much!!! It worked for me.
    Moiz
    Wednesday, February 23, 2011 2:42 AM