Greg Young | 10 Oct 12:23 2015

32 bit mono

As of now 32 bit mono is still being shipped with xamarin studio as I
understand for osx. Are there plans to start shipping 64 bit? Just
trying to figure out if its worth supporting a 32 bit build of our
profiler backend for mono.




Studying for the Turing test
Bill Seurer | 9 Oct 21:52 2015

Recent commits cause problems with thread test cases

There are a couple of recent commits which cause problems for some 
thread-related things in mono/tests.  At least they do on power.  I did 
a refresh (fetch/rebase) from mono/master just before I tried things a 
few minutes ago so no later commits fixed the problems.

The commits causing grief appear to be these:

commit 7aae649458bceb4375b74f078c4f24ddd4a486f5
Merge: e6ad2dc e5e97ea
Author: Rodrigo Kumpera <kumpera <at>>
Date: Tue Oct 6 10:40:47 2015 -0400

Merge pull request #2060 from ludovic-henry/socket-rework-async

[socket] Complete refactor of Begin/End and Async

commit e6ad2dc73b415e091c80a9912c66e86af1e7a761
Merge: 0056f1f 388b958
Author: Rodrigo Kumpera <kumpera <at>>
Date: Tue Oct 6 10:19:19 2015 -0400

Merge pull request #2110 from ludovic-henry/threadpool-exit-worker

[threadpool-ms] Exit worker thread after 5 to 60 seconds

Things worked fine with the commit previous to the above two which is 
this one:

commit 11096e3733b808a8bbfce262c256ec89887cac89
Author: Ludovic Henry <ludovic <at>>
(Continue reading)

Dan Liew | 9 Oct 15:40 2015

System.Diagnostics.Process behaves differently in and outside of a NUnit test case


This is an issue that I was bitten by a while ago but I didn't post
here because I managed to work around it but it looks like something
inside mono changed between 3.12 and 4.0.4 which my broke my

The issue basically is I observed my code failing when called from an
NUnit test but when run from an executable it would work fine. The
code in question [1] calls out to an external process using
``System.Diagnostics.Process`` where the standard input is redirected.
When running from an NUnit test a UTF-8 BOM gets sent to the process's
standard input and when running from an executable the UTF-8 BOM does
not get sent.

I looked at this again and I've noticed two things

* In System.Diagnostics.Process.Start_noshell() the encoding for the
writable end of the pipe connected to the child process's standard
input is taken from ``Console.Out.Encoding``. Is this really a good
idea? Depending on this global value seems like a bad idea and could
introduce weird race conditions if the Console.Out encoding is changed
in some way (e.g. ``Console.OutputEncoding = new
System.Text.UTF8Encoding(false);`` seems to do this and this the new
workaround I ended up using)

* When running in an executable the value of
``Console.Out.Encoding.emitUTF8Identifier`` is false but when running
in an NUnit test the value of
````Console.Out.Encoding.emitUTF8Identifier`` is true!
(Continue reading)

Numpsy | 8 Oct 12:42 2015

Having a problem with signed XML files

Hi all,
I have a Windows product that uses signed XML files which I'm trying to get
running under Mono on OSX, and I'm running into a verification failure at
I'm pretty hazy about how the internals of this stuff works, but debugging
through it, the issue seems to be occurring in
System.Security.Cryptography.Xml.SignedXml.GetReferenceHash(), due to the
call to FixupNamespaceNodes added  <at>

Which takes the XML in the form

&lt;Object Id="LICENCES"&gt;
    <ArrayOfString xmlns:xsi=""
xmlns:xsd="" xmlns="">

And copies the xmlns attributes on the ArrayOfString node onto the Object
node. If I skip over the FixupNamespaceNodes call, it all appears to work.

Anyone have any thoughts on how to proceed with this? The 'I haven't solved
the puzzle on why it is needed though.' comment on the commit doesn't fill
me with confidence :-(

Richard Webb
(Continue reading)

Numpsy | 8 Oct 11:50 2015

System.DirectoryServices.DirectoryEntry.ObjectSecurity property

Hi all

When trying to build some Windows .Net libs in Mono (on OSX in this case,
but I don't think that matters), I got a compile error due to the
'ObjectSecurity' property of System.DirectoryServices.DirectoryEntry being
I was wondering, is there a reason for that, or is it an oversight?

As it happens I don't actually need to use the returned object on the Mono
build at the moment, but the compile error is annoying.

Richard Webb

View this message in context:
Sent from the Mono - Dev mailing list archive at
techi eth | 8 Oct 05:44 2015

Newtonsoft.Json build in mono


How do i get Newtonsoft.Json get build out of mono/external source folder on Linux.


Mono-devel-list mailing list
Mono-devel-list <at>
Neale Ferguson | 6 Oct 23:47 2015


We have a client who is testing the waters with porting some .NET based
applications to mono. However, a couple of these critical applications
rely on the windows registry. The implementation of registry-support in
mono is quite crude and not process-safe and this is holding them back. I
am looking for ideas as to improving this so that apps can share the
registry safely and efficiently.
Matt Guerrette | 6 Oct 21:39 2015

Re: Compiling 64-bit windows mono-2.0 library with Visual Studio

Im trying to embed scripting in C++ using the mono jit runtime in libmono. I wanted to build a 64 bit library of the mono runtime but that doesnt seem possible on Windows. Does anyone know of a way to do so using Visual Studio? The msvc project included in the mono github repo fails miserably.

On Oct 6, 2015 3:36 PM, "Edward Ned Harvey (mono)" <edward.harvey.mono <at>> wrote:

MMMmmmm...  No, that's still not clear.  (Also, you didn't reply to list, so if you want anyone else to answer, you'll have to resend or something).


Mono is the open-source implementation of C# and .NET. So if you're developing on windows, normally you don't need mono. You just write C# and access .NET.


You mentioned C++. Ok, no problem, you just access .NET however you do that in C++. (I'm not sure how to do that, but I know there are C++ bindings or something, which enable you to access .NET from C++).


The only reason I think you need mono is if you want something from the mono namespace, which is not part of .NET normally. Most of the mono namespace was created to provide support for things that don't exist in windows - for example, posix. But a bunch of things in the mono namespace can be useful in windows...


I get the impression you're not actually trying to access something mono specific. I get the impression you want to know how to access .NET from C++. This doesn't need mono. It's all microsoft.





From: Matt Guerrette [mailto:direct3dtutorials <at>]
Sent: Tuesday, October 6, 2015 10:22 AM
To: Edward Ned Harvey (mono) <edward.harvey.mono <at>>
Subject: RE: [Mono-dev] Compiling 64-bit windows mono-2.0 library with Visual Studio


Sorry i should have been more specific. Im trying to link 64 bit mono for a c++ project to use for scripting, but there is no prebuilt 64 bit windows library.

On Oct 6, 2015 7:03 AM, "Edward Ned Harvey (mono)" <edward.harvey.mono <at>> wrote:

> From: mono-devel-list-bounces <at> [mailto:mono-devel-list-
> bounces <at>] On Behalf Of Matt Guerrette
> I am currently trying to integrate mono into a project that I've built
> completely 64 bit.
> Currently on Windows there seems to be only 32 bit versions of Mono and
> no easy way to build a 64 bit version.

What do you mean you're trying to integrate mono into a project that you've built? This is presumably a C# .NET project you have in windows, so what do you mean "integrate mono?"

Mono-devel-list mailing list
Mono-devel-list <at>

Console.In.ReadToEnd() doesn't exit when stdin is closed


We found a small issue in the latest releases that is affecting our automated tests (and Plastic trigger/hook execution :P).

It goes as follows:

* Parent process in mono creates a new process and redirects its input and output.
* Child process also in mono does:


* Parent does


but child stays in ReadToEnd forever, although it shouldn't (it worked well on mono 2.x, 3.x and 4.0.3, and .NET).

We reported a bug here, all code attached:


Mono-devel-list mailing list
Mono-devel-list <at>
Matt Guerrette | 6 Oct 07:49 2015

Compiling 64-bit windows mono-2.0 library with Visual Studio

I am currently trying to integrate mono into a project that I've built 
completely 64 bit.
Currently on Windows there seems to be only 32 bit versions of Mono and 
no easy way to build a 64 bit version.
Has anyone successfully built a 64 bit version using Visual Studio 
2010-2015 (I am currently using 2015) ?

How to use lib64 in mono 4.3?


We're having trouble understanding the new lib64 thing in mono 4.3 (we're trying to move Plastic SCM to 4.3 now).

A simple app like this one:

using Mono.Unix;
namespace testunixdirinfo
    class MainClass
        public static void Main(string[] args)
            UnixDirectoryInfo dir = new UnixDirectoryInfo(args[0]);

Fails saying it can't find lib/, which is now under lib64 instead.

It is easy to fix just moving it under lib inside your mono binaries, but I guess this is not the right way to do it :confounded:

This is the build we're using Mono JIT compiler version 4.3.0 (explicit/b6dfce6.

Thanks! ">

Mono-devel-list mailing list
Mono-devel-list <at>