Back to Questions
4.6k
views12
comments
F# and Mono: Not finding System.Net.Sockets.*?
f#testingclasses

Hi,

I am testing the portability of some code that I have written and I have been encountering some trouble with the fsc not finding TcpClient and TcpListener when run under mono. I get

1
2

TcpServer.fs(12,33): error FS0039: The type 'TcpClient' is not defined.  
TcpServer.fs(13,20): error FS0039: The type 'TcpListener' is not defined.

I wrote a small C# program and mcs doesn't seem to have any problems finding TcpClient and TcpListener. It seems unlikey that my setup is completely broken because fsc does find classes within System.IO. Also, I didn't have any problem configuring it to find Gtk#. The code compiles without problems on Visual Studio 2010.

I am using version 1.9.6.16 of fsc and Mono 2.4.2.3 installed via Mac Ports. F# reports that it is searching:

1
2
3
4

/opt/local/lib/mono/2.1
/opt/local/lib/mono/2.0
/opt/local/lib/mono/gtk-sharp-2.0/
/local/FSharp-1.9.6.16/bin

Any ideas on what I could be doing wrong here?

.

You probably need to reference System.Net library in your project. I don't now about Mono libraries much, but we're developing some Silverlight 3 libraries in F# and we need System.Net library reference even though we don't use any methods/classes from this library.

By on 8/16/2009 6:41 AM ()

No, it is not that. I had already tried referencing System.Net.dll and it doesn't resolve the problem. Furthermore, I have definitively verified that the classes of interest live in System.dll. Then there is the fact that it is not necessary to reference System.Net.dll with older versions of the compiler or when using Mono under Linux.

By on 8/18/2009 5:59 AM ()

Are you referencing System.dll (which seems to hold these types)? How do the command-lines of the C# versus the F# differ with regards to '-r' references?

(I know little about mono, just trying to speculate ways to diagnose such a failure.)

By on 8/11/2009 5:47 AM ()

I wasn't, but adding -r System.dll does not make the problem go away.

I'm not sure what you mean about the differences between the C# and F# command-lines? With mcs I did not need to provide any references for it to find System.Net.Sockets.TcpClient, etc. I just gave it the name of the file with the C# code.

By on 8/11/2009 5:58 AM ()

I see; I don't know mcs, I just know that e.g. with C# in Visual Studio, if I reference System.dll, then that turns into

/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll

passed to csc.exe, and if I remove the reference to 'System' in my VS C# project (that uses e.g. TcpListener), then that part is dropped from the command-line and the program quits compiling successfully.

So it sounds like mcs is implicitly referencing some framework DLLs, and you need to add an explicit reference to those DLLs for fsc.exe, but unfortunately I'm not sure how to find that on Mono, though pages like this

[link:www.go-mono.com]

suggest that TcpListener should be in System.dll somewhere.

By on 8/11/2009 6:55 AM ()

I tried disassembling the executable gmcs produced for my C# test program and it indeed is referencing System.dll.

So I am not sure where to go from here, as it seems like this is most likely a problem with fsc. I know when I give it "-r System.dll" or "--reference:System.dll" or even "--reference:/opt/local/lib/mono/2.0/System.dll" it never complains. But if I tell it to reference a nonexistent dll, I will get an error, so it must be finding System.dll but just not considering its contents. What makes this even stranger is that "-r gtk-sharp.dll" works just fine at resolving the references to Gtk, TextBuffer, etc. in a different part of my code.

By on 8/12/2009 2:05 AM ()

Can fsi find TcpClient? E.g.

1
2
3
4
5
6
7
8

> #r "System.dll";;

--> Referenced 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll'

> let client = new System.Net.Sockets.TcpClient();;

val client : System.Net.Sockets.TcpClient
By on 8/12/2009 3:07 AM ()

I was initially having some problems with fsi not finding the GDI+ shared libraries, but eventually sorted out the correct solution to that. Now:

1
2
3
4
5
6
7
8
9
10
11
12
13

% DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib:/usr/lib mono /local/FSharp/bin/fsi.exe
Microsoft F# Interactive, (c) Microsoft Corporation, All Rights Reserved
F# Version 1.9.6.16, compiling for .NET Framework Version v2.0.50727
Please send bug reports to fsbugs@microsoft.com
For help type #help;;
> 
warning FS0191: Could not determine highest installed .NET framework version from Registry keys, using version 2.0
#r "System.dll";;
--> Referenced '/opt/local/lib/mono/2.1/System.dll'
> let client = new System.Net.Sockets.TcpClient();;
  let client = new System.Net.Sockets.TcpClient();;
  ------------------------------------^^^^^^^^^
\Users\geoffw\stdin(2,37): error FS0039: The type 'TcpClient' is not defined.

and just for comparison, here is the Mono C# "shell:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Mono C# Shell, type "help;" for help
Enter statements below.
csharp> LoadAssembly("System.dll");
csharp> var x = new System.Net.Sockets.TcpClient();
csharp> ShowVars();
System.Net.Sockets.TcpClient x = System.Net.Sockets.TcpClient
csharp>  
csharp> using System.Net.Sockets;
csharp> ShowUsing();
using System;
using System.Linq;
using System.Collections.Generic;
using System.Collections;
using System.Net.Sockets;
By on 8/12/2009 4:52 AM ()

Okay, so I discovered that if I downgrade to version 1.9.6.2 of fsc, it compiles without any problems. So I kind of suspect that there is indeed some kind of problem in the newer versions of the compiler.

By on 8/12/2009 8:09 AM ()

FWIW i have tried to reproduce the issue with F# 1.9.6.16 and Mono 2.4 on Windows and Mono 2.0 on Ubuntu but it works on my machine.

By on 8/12/2009 11:06 AM ()

It is also possible that it is somehow a Mac specific issue. I am hoping to get some time to test on a Linux system in the next day or two.

By on 8/13/2009 1:29 AM ()

Okay, after getting the newest version of Mono installed on my ThinkPad running Ubuntu, I can confirm that I do not have any problems with 1.9.6.16 under Linux. So it must be a Mac issue.

By on 8/15/2009 4:28 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper