OData / ODataConnectedService

A Visual Studio extension for generating client code for OData Services
Other
79 stars 41 forks source link

Parsing for the xml file name can result in exception with multiple services #405

Open Algorithman opened 1 month ago

Algorithman commented 1 month ago

Describe the bug

If you have multiple services in your project this here can lead to a linq enumeration exception. (same goes for the ttinclude as well of course)

This should not be done via EndsWith but comparing the full filename.

Version of the Project affected

ODataConnectedService latest VisualStudio Version v17.10.4 Microsoft.Odata.Client v7.21.3

To Reproduce

Steps to reproduce the behavior:

  1. Install a odata service, name it "OData Service"
  2. Install another odata service and name it "My secondary OData Service" into the same assembly
  3. make some boilerplate code to initialize and connect to the first service
  4. Run
  5. See error

Expected behavior

Expected behavior: Both services should be found, no exception should be thrown.

Actual behavior

Since both services end with "OData Service", the line mentioned above results in finding the xml for BOTH services. So the comparison should not be done via EndsWith, it should check the whole file name, not just a part of it.

Additional context

Exception thrown: System.InvalidOperationException: 'Sequence contains more than one matching element'

Algorithman commented 1 month ago

Just seen this was reported a while ago here #360 Necroing this so that it gets fixed please.

habbes commented 1 month ago

@Algorithman thanks for bringing attention to this. Should be a rather straightforward fix.

habbes commented 1 month ago

EndsWith is definitely not the best. But should point out that the full manifest resource name is different from the file name, so comparing that full string will return an incorrect result.

The manifest name is of the form <Namespace>.Connected_services.OData_Services.<filename>. I'm not sure if the naming convention of embedded resources is standardized. If it is, we could extract the last component and compare that. Alternatively, we could find all matches and return the shortest?