Why does PCL not support System.Net.WebProxy?

Why is System.Net.WebProxy supported in the device projects but not in a PCL? In a PCL, I'm forced to implement my own via IWebProxy. This works so I'm just wondering why it is necessary. Is there some best practice that says this should be done in the device layer rather than the PCL? Since it is the same regardless of device (right?), not sure why this would be the case.

Tagged:

Best Answer

Answers

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @RodBarnes
    Take a look at the NuGet packages 'Shim' or 'Splat'.
    They make an effort to fill in the holes of silly things like this.

  • RodBarnesRodBarnes USMember ✭✭

    @ClintStLaurent Thank you. So, it seems I'm at least correct in expecting that this should be available in a PCL. I couldn't think of a reason why it wouldn't be.

    For the moment, I'll wait to see if anyone can chime in as to why it is the way it is. But I'll check out the packages you recommended.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @RodBarnes

    Yeah. There are a few missing calls that exist on all the platforms but not the PCL. Some are System.IO.File for example. You can specify File.Delete on each platform but not from the PCL - or something like that but I'm hazy on which calls. I just made my own FileHelper dependency service and do all my IO through that so I forget which ones.

    That would be your other choice if you don't like making your own interface: Make a Dependency service that wraps your web work calls. Most calls will just make the platform call. Some calls gives you a single place to add some robustness.

    For example: System.IO.Directory.Delete won't delete a folder if it has contents. So my service empties the folder first, then deletes it. That way I don't have to remember to do that all over my PCL. It also does it on its own thread so it doesn't hold up the UI waiting for files to delete.

Sign In or Register to comment.