[OASIS Issue Tracker] (LEGALXMLCO-2) Provide guidance on .NET implementations

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/LEGALXMLCO-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Cabral updated LEGALXMLCO-2:
----------------------------------
    Description: 
Consuming EFM APIs can be challenging in C# ASP.Net. The agreed upon approach for generating a client to communicate with SOAP XML API is to use either the build in Add Service Reference function inside of Visual Studio or to use the SvcUtil.exe utility provided by ASP.Net. The output of using this approach creates class name conflicts that are handled by the tool by incrementing a number on the end of the generated class. For example two classes with the same name could result in being output as "ClassName" and "ClassName1". Unfortunately, the tool does not let you control the order in which these class names are generated, so each time the utility is used the output C# client can have different class names for the same class. To handle this scenario, EFSPs needed to create custom code that cleaned up these class name conflicts after the SvcUtil.exe utility was used to generate the code.

Xsd2Code is a better tool for generating .NET contracts and interfaces from XSD and WSDL. There are still issues with substitution groups.

Provide some non-normative guidance or a link on the website to appropriate tools.

  was:
Consuming EFM APIs can be challenging in C# ASP.Net. The agreed upon approach for generating a client to communicate with SOAP XML API is to use either the build in Add Service Reference function inside of Visual Studio or to use the SvcUtil.exe utility provided by ASP.Net. The output of using this approach creates class name conflicts that are handled by the tool by incrementing a number on the end of the generated class. For example two classes with the same name could result in being output as "ClassName" and "ClassName1". Unfortunately, the tool does not let you control the order in which these class names are generated, so each time the utility is used the output C# client can have different class names for the same class. To handle this scenario, EFSPs needed to create custom code that cleaned up these class name conflicts after the SvcUtil.exe utility was used to generate the code.

Xsd2Code is a better tool for generating .NET contracts and interfaces from XSD and WSDL. There are still issues with substitution groups.

Provide some non-normative guidance.


> Provide guidance on .NET implementations
> ----------------------------------------
>
>                 Key: LEGALXMLCO-2
>                 URL: https://issues.oasis-open.org/browse/LEGALXMLCO-2
>             Project: OASIS LegalXML Electronic Court Filing TC`
>          Issue Type: Improvement
>            Reporter: James Cabral
>            Assignee: Enrique Othon
>            Priority: Minor
>
> Consuming EFM APIs can be challenging in C# ASP.Net. The agreed upon approach for generating a client to communicate with SOAP XML API is to use either the build in Add Service Reference function inside of Visual Studio or to use the SvcUtil.exe utility provided by ASP.Net. The output of using this approach creates class name conflicts that are handled by the tool by incrementing a number on the end of the generated class. For example two classes with the same name could result in being output as "ClassName" and "ClassName1". Unfortunately, the tool does not let you control the order in which these class names are generated, so each time the utility is used the output C# client can have different class names for the same class. To handle this scenario, EFSPs needed to create custom code that cleaned up these class name conflicts after the SvcUtil.exe utility was used to generate the code.
> Xsd2Code is a better tool for generating .NET contracts and interfaces from XSD and WSDL. There are still issues with substitution groups.
> Provide some non-normative guidance or a link on the website to appropriate tools.



--
This message was sent by Atlassian Jira
(v8.3.3#803004)