Missing System.Web.Http using in generated file

[Lukas Behal]

Generated proxy class file is missing System.Web.Http using therefore compilation of project is falling afterwards.

.Net framework - 4.5.2
WebApiProxy-CSharp version - 1.0.5.35849

[YetAnotherPhil]

This is still an issue with the latest version (1.3.6021.11899).
Please can you add using System.Web.Http; to avoid error:

CS0246 The type or namespace name 'IHttpActionResult' could not be found (are you missing a using directive or an assembly reference?)

Here is an example method: IHttpActionResult Delete(int MyID); that generates the error.

TY

[Fanie Reynders]

Adding a reference to System.Web.Http will solve the problem but leaving it with another reference to another assembly that it really doesn't need on the client side. We don't want to do this.

The return type IHttpActionResult is an abstraction of a HttpResponseMessage and therefore needs to be generated as HttpResponseMessage instead of an interface, (given that ResponseType isn't explicitly specified on the method of the controller).

I've noticed that this does indeed gets generated like mentioned above, but only some of the methods and will push out a bug fix that addresses this shortly.

In the meanwhile I would suggest explicitly specifying the return type using ResponseType when using IHttpActionResult responses.

[YetAnotherPhil]

Fair comment, thx for the speedy reply. Cheers

[Fanie Reynders]

After further investigation on this issue (and hoping it was changed by an accidental merge earlier on), I found that this specific scenario is implemented by design to enforce the use of ResponseType on actions.

It generates 3 methods, 2 of which returns a standard HttpResponseMessage by default:

1. A special async message e.g. Task<HttpResponseMessage> FooAsyncMsg()
2. A normal async e.g. Task<HttpResponseMessage> FooAsync()
3. A concrete e.g. Bar Foo()

Really don't know what the actual difference (or use) is between nr. 1 & 2, therefor I suggest the following:

1. A special async (as message) e.g. Task<HttpResponseMessage> FooAsyncMessage()
2. A async e.g. Task<Bar> FooAsync()
3. A concrete e.g. Bar Foo()

[Fanie Reynders]

The only thing is that it still shouldn't break if one doesn't use ResponseType. It should fall back to HttpResponseMessage IMHO