The first item in a list-expansion cannot be null

When generating a client, Autorest sets an empty string to the parameter…

if (entityTypes.Count == 0)
{
     _queryParameters.Add(string.Format("Blah={0}", System.Uri.EscapeDataString(string.Empty)));
}

This causes issues on model binding in controllers because now the list has a null item in it. It would be better not to set the parameter at all if the list is empty.

if (blah != null && blah.Count != 0)
{
    foreach (var _item in blah)
    {
        _queryParameters.Add(string.Format("Blahs={0}", System.Uri.EscapeDataString("" + _item)));
    }
 }

[felpel]

This issue should not be closed!

Why would we want to send a list with a single null element?

We had a nasty side-effect introduced in our generated code given my colleague updated the client code to contact one of our services and he wondered if the parameter should be set as an empty list or anything else. We should not have to look at the generated code to ensure that the code is correct. It is our fault to not have tested thoroughly after the code was regenerated, but this behavior is very strange.

The suggestion by @zunama was great, in my opinion, but it might diverge from @olydis.

[eanyanwu]

Hmm good question. I did a little bit more digging and found that asp.net has some interesting behavior here:

• If the controller accepts an actual list e.g. (List<string> myList), model binding will create an empty list if the string “myList” is not sent at all. So POSTing http://localhost:80/api/values to a controller that accepts a list, will actually initialize the list parameter and have it empty. This is a bit odd, but it is documented to some degree (Search for “Reference Types”). This is the case in the original repro I linked. Including the “myList” string like so: http://localhost:80/api/values?myList= will create a list with one null element.
• Now for the weird part. If the controller accepts an object of some type which has a list property, omitting the list parameter from the query like above doesn’t give the same behavior. To get an empty list, you need to post http://localhost:80/api/values?testlist[]. Oddly enough, you will get a different result if you post http://localhost:80/api/values?testlist (no brackets)

To repro my second bullet point, simply modify the original AutoRest project by adding a class similar to this:

public class Wrapper
{
    public List<string> TestList{ get; set; }
}

My original problem was the second bullet point, but this seems to be a bit more convoluted than I thought at first, so I think I’ll switch to passing the object in the body of the request instead :0 since I can just send this: { TestList : [] } in the request body.

So I am all set 👍