WebRequest.Create(Uri uri) throws System.NotSupportedException: The URI prefix is not recognized.
USMember ✭✭
I'm in the Stable channel and I updated today (from mono 4.6.2 to 4.8.0, I didn't take note of the Xamarin.Mac and Xamarin Studio previous versions, but they were at the previous instances of the Stable channel). Since this update, I'm getting this exception (in the title) on every WebRequest.Create(Uri uri). By the way, the prefix is http.
The weirdest thing is that if I include the Mono runtime in the application bundle, this issue disappears.
I still wanted to find another workaround. So I did play around a bit and tried registering the prefix directly with this quite unappealing but somewhat functioning code:
Type httpRequestCreatorType = Assembly.GetAssembly(typeof(WebRequest)).GetTypes().FirstOrDefault(t => t.FullName == "System.Net.HttpRequestCreator");
IWebRequestCreate httpWebRequestCreate = (IWebRequestCreate)FormatterServices.GetUninitializedObject(httpRequestCreatorType);
WebRequest.RegisterPrefix("http", httpWebRequestCreate);
It does go through the WebRequest.Create without throwing an exception, only to throw the following exception on the HttpWebRequest.GetResponse:
System.NullReferenceException: Object reference not set to an instance of an object at System.Net.HttpWebRequest.EndGetResponse (System.IAsyncResult asyncResult) [0x0005e] in /private/tmp/source-mono-4.8.0/bockbuild-mono-4.8.0-branch/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/System/System.Net/HttpWebRequest.cs:1029 at System.Net.HttpWebRequest.GetResponse () [0x0000e] in /private/tmp/source-mono-4.8.0/bockbuild-mono-4.8.0-branch/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/System/System.Net/HttpWebRequest.cs:1043
This is when I realized I was wasting my time and Including the Mono runtime would make for an acceptable workaround, since we were not including the Mono runtime only on debug build.
Still, I'm letting this here in case anyone has the time to look into this.
Best Answer
-
ChrisHamons
USForum Administrator, Xamarin Team Xamurai
The weirdest thing is that if I include the Mono runtime in the application bundle, this issue disappears.
So you still are on Classic then
Classic has a number of "if you include mono in the bundle, X is fixed" issues. Using system mono without copying it until your bundle changes a number of behaviors, and tracking them down is a bit nightmarish. At this point, I tell all Classic users to bundle mono if you are stuck in Classic.
There is a reason we got rid of the option in Unified.
Also, please seriously consider porting to Unified. It pains me to see people on Classic, given the massive improvements we'd made in Unified.
6
Answers
So you still are on Classic then
Classic has a number of "if you include mono in the bundle, X is fixed" issues. Using system mono without copying it until your bundle changes a number of behaviors, and tracking them down is a bit nightmarish. At this point, I tell all Classic users to bundle mono if you are stuck in Classic.
There is a reason we got rid of the option in Unified.
Also, please seriously consider porting to Unified. It pains me to see people on Classic, given the massive improvements we'd made in Unified.
Then you will be please to hear that I am currently working on porting to Unified.
But as mentioned, it caused some issues and because of the random nature of some of those issues, nearly everything requires extensive testing, which is extremely time consuming. I should see the end of it someday, though.
Thank you for your quick answer.
Awesome.
Porting large application, in particular ones with non-trivial GUIs, can be challenging. Best of luck o/