Hi Jon,
Warning. I am writing this from Memory when I last observed
this error (few months back). This error is benign.
This error last time I debugged deep into mono and found that this was
related to IPv4 and IPv6 Address Family checking, When I was porting
System.Web to Android/IOS and for Android i was able to avoid the
error by implementing some other work arround, but I believe IOS is
still getting the error and will verify and get back to you on Monday
since I have to switch my development to Mac (currently busy with
Android Dev) and verify again and that I can do only on Monday as I am
preparing my self to for a 54hr Startup Weekend.
When I executed the following function to get a Free Port, I
used to observe this error.
Socket socket = null;
bool ret =true;
try
{
IPAddress ipAddress = IPAddress.Loopback;
socket = new Socket(ipAddress.AddressFamily,
SocketType.Stream, ProtocolType.Tcp);
if (socket != null)
{
socket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ExclusiveAddressUse, true);
socket.Bind(new IPEndPoint(IPAddress.Any, port));
socket.Listen(5);
}
ret = true;
}
catch { ret = false; }
finally { if (socket != null) socket.Close(); }
Everything seems to work, but just that exception is
raised. I have also observed in the adb logs this error many times -
DEBUG/SntpClient(60): request time failed: java.net.SocketException:
Address family not supported by protocol
I believe this exception is raised during socket creation
using IPv4 or IPv6 Address Family when that particular Family is not
supported in the OS? and I even tried to pass
AddressFamily.InterNetwork, AddressFamily.InterNetworkV6 with some
checking using (Socket.SupportsIPv4 == true) or (Socket.OSSupportsIPv6
== true), but still the exception gets raised. After spending too much
time on this and finally I wrote a work arround using
IPGlobalProperties ipGlobalProperties =
IPGlobalProperties.GetIPGlobalProperties();
IPEndPoint[] endPoints =
ipGlobalProperties.GetActiveTcpListeners();
to find free port. Unfortunately this does not work in MonoTouch and
since any way this error is not creating any problems, I stopped
further work on this.
Sorry for writing without being very sure. I just wanted to
tell what I observed so that you may make a better sense on it and not
spend too much time in your busy schedule.
Best Regards,
Sridharan Srinivasan
Alias Sri.
On Fri, Oct 14, 2011 at 10:13 AM, Jonathan Pryor <[email protected]> wrote:
> Warning: I'm not known for being the smartest guy in the room. That said...
>
> On Oct 13, 2011, at 8:47 AM, Nicklas Møller Jepsen wrote:
>> The main problem is that I’m seeing completely different behavior when
>> running the app from VS (on a device) compared to manually copying the APK
>> to the same the device and installing it. How can this be?
>
> There are _lots_ of potential reasons for this. :-)
>
> 1. Release builds (which are deployable to the Android Market, and which you
> mentioned later) bundles the runtime and links all required assemblies in
> order to minimize application size. Debug builds don't do that (by default):
>
> http://docs.xamarin.com/android/advanced_topics/linking
>
> This is the most plausible reason for your ClassNotFoundException -- you've
> performed a Release (linking) build, and the linker failed. Try rebuilding
> with linking disabled for whatever assembly contains the missing type, and
> please file a bug at bugzilla.xamarin.com (assuming that the "much smarter"
> linker in 1.9.1 doesn't fix the issue).
>
> 2. For Debug builds (by default), Installing a .apk outside of the IDE won't
> result installing the required shared runtime packages, which will result in
> numerous errors when attempting to launch the application.
>
> 3. The shared runtime is not ABI stable. If you deploy the shared runtime to
> your device and then later upgrade your Mono for Android install, if the
> shared runtime isn't upgraded on your device all sorts of bizarre things will
> break.
>
> I'm probably missing other scenarios, and the differences between Release and
> Debug builds will only increase over time (in order to speed up developer
> turnaround while debugging).
>
> As far as the TypeInitializationException from System.Net.Sockets.Socket,
> unfortunately we're going to need a bug filed for that one, as we don't see
> any way for an exception to be emitted from the System.Net.Sockets.Socket
> static constructor:
>
>
> https://github.com/mono/mono/blob/mono-2-10/mcs/class/System/System.Net.Sockets/Socket_2_1.cs#L770
>
> If someone seeing this could file a bug with a reproducible test case, it
> would be much appreciated.
>
> Thanks,
> - Jon
>
> _______________________________________________
> Monodroid mailing list
> [email protected]
>
> UNSUBSCRIBE INFORMATION:
> http://lists.ximian.com/mailman/listinfo/monodroid
>
--
Sridharan Srinivasan
Alias Sri
Ph:(65)98255785/(65)63922439
www.arshu.com
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
