Re: [Mono-dev] Bug preserving stack trace

[Edward Ned Harvey (mono)]

Any responses?


> -Original Message-
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono)
> Sent: Wednesday, June 22, 2016 7:59 AM
> 
> I know you don't usually want to catch & throw, because you're not adding
> new information. If you want to add new information, generally you should
> throw a new exception and include an InnerException. Here are some
> examples of situations you would want to catch and rethrow:
> https://msdn.microsoft.com/en-us/library/0yd65esw.aspx
> 
> I also know you destroy the stack trace if you explicitly name the exception
> you're rethrowing. In order to preserve the stack, you should throw without
> any arguments.
> https://msdn.microsoft.com/en-us/library/ms182363.aspx
> 
> I know the difference between a debug build and release build, particularly
> with regards to optimizations and inlining.
> 
> In a debug build, the following code behaves as expected (prints out the full
> stack trace) on .NET, but doesn't print out the full stack on mono 4.2.3. I'm
> pretty sure it's not an expected behavior.
> 
> using System;
> 
> namespace FunWithRethrow
> {
>   class MainClass
>   {
>     public static void Main (string[] args)
>     {
>   try {
>     Third ();
>       }
>   catch (Exception e) {
>     Console.WriteLine (e);
>   }
>     }
>     static void Third()
>     {
>   Second ();
>     }
>     static void Second()
>     {
>   try {
>     First();
>   }
>   catch {
>     throw;
>   }
>     }
>     static void First()
>     {
>   throw new Exception ("Something said... Not good...");
>     }
>   }
> }
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Mono does not include full stacktrace while rethrowing exception

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of ??? ?
> 

First, just to be sure you know, you *almost* should never catch and rethrow, 
because you're not adding new information. If you want to add new information, 
generally you should throw a new exception and include an InnerException. Here 
are some examples of situations you would want to catch and rethrow:
https://msdn.microsoft.com/en-us/library/0yd65esw.aspx

And just to confirm you're right, you *should* expect the stack to be 
preserved, if you throw without any arguments.
https://msdn.microsoft.com/en-us/library/ms182363.aspx

I've confirmed the behavior you reported. In a debug build, on windows, and on 
mono, the behavior is not the same on .NET and on mono. It should be.

I think this is probably an actual bug and I'll go report it.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-dev] Bug preserving stack trace

[Edward Ned Harvey (mono)]

I know you don't usually want to catch & throw, because you're not adding new 
information. If you want to add new information, generally you should throw a 
new exception and include an InnerException. Here are some examples of 
situations you would want to catch and rethrow:

https://msdn.microsoft.com/en-us/library/0yd65esw.aspx



I also know you destroy the stack trace if you explicitly name the exception 
you're rethrowing. In order to preserve the stack, you should throw without any 
arguments.

https://msdn.microsoft.com/en-us/library/ms182363.aspx



I know the difference between a debug build and release build, particularly 
with regards to optimizations and inlining.


In a debug build, the following code behaves as expected (prints out the full 
stack trace) on .NET, but doesn't print out the full stack on mono 4.2.3. I'm 
pretty sure it's not an expected behavior.

using System;

namespace FunWithRethrow
{
  class MainClass
  {
public static void Main (string[] args)
{
  try {
Third ();
  }
  catch (Exception e) {
Console.WriteLine (e);
  }
}
static void Third()
{
  Second ();
}
static void Second()
{
  try {
First();
  }
  catch {
throw;
  }
}
static void First()
{
  throw new Exception ("Something said... Not good...");
}
  }
}

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Cross Platform on Linux/Windows with Mono.Posix reference on Linux

[Edward Ned Harvey (mono)]

> From: Chris Swiedler [mailto:cswied...@trionworlds.com]
> 
> Why not just include references to Mono.Posix.dll in the Windows build? You
> don't have to install the full framework.

Then when you run it on mono, you're using the Mono.Posix.dll that you packaged 
with your application, instead of using the one that's included in the OS. 
Although it's arguable which way is better, because each way has pros and cons, 
the OP specifically said he didn't want to do this (and I personally agree).

It's not difficult to write the abstraction factory, and it's the most elegant 
solution. I will advocate for this because I've been burned in the past by 
*not* doing it.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Cross Platform on Linux/Windows with Mono.Posix reference on Linux

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Greg Young
> 
> 

(for clarification of my previous response, because I was asked for 
clarification off-list)

If you have some code that calls Mono.Posix.Something(), and you have a 
conditional reference to Mono.Posix in the project, then you're able to build 
on Mono, but on windows, without the reference, your call to 
Mono.Posix.Something() will not compile, which prevents you from building, even 
though at runtime you might never make that call. In order to compile on 
windows, you'll need to comment-out your Mono.Posix.Something() line, via #if 
or [Conditional], which means you need a compiler symbol to indicate whether 
you're building on mono or windows. This could be either separate project 
files, or multiple build configurations. (Or dynamically generated project 
files).

Maybe you can have a conditional reference to Mono.Posix on mono, and have a 
separate conditional reference to ../../ExtraClassLibraries/Mono.Posix.dll on 
windows, with copy-to-destination, so you can get the same code to build on 
both mono and windows, resulting in an effectively identical cross-platform 
binary... But I'm almost certain I recall somebody on this list telling me, 
that the JIT compiler can or will or might in the future, eagerly link 
assemblies at runtime (or just before runtime), so the Mono.Posix.dll file must 
be present on windows at runtime in order to avoid runtime exceptions, even 
though the runtime code execution will never execute that path.

You avoid all these problems by abstracting the functionality you want into an 
interface or abstract class, and using a factory to perform a runtime dynamic 
load of a mono-specific or windows-specific assembly with a derivative class. 
You can build the mono-specific assembly on mono, or maybe you can use the 
double-conditional described above and get the mono-specific assembly to also 
be buildable on windows. No need to copy Mono.Posix.dll to the destination, 
because Mono.Posix will only be called at runtime when run on mono.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Cross Platform on Linux/Windows with Mono.Posix reference on Linux

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Greg Young
> 
> 

That doesn't do the trick all by itself, because then your code won't compile 
on windows, in all the places where something references Mono.Posix. If you 
want to use this as a solution, you'll need to define a compiler symbol in the 
project, and maintain different project files (or different build 
configurations) when building on windows or mono, and then #if to remove 
references to Mono.Posix, when built in windows. While this technique works, it 
would result in binaries that are not cross-platform compatible (maybe you 
don't care). And you have to maintain the separate project files, which is 
annoying.

The other way is to build a factory, and do a run-time check to load the 
appropriate assembly. For example, you can put the abstract StuffDoer class in 
a common assembly, which is available to all your platform agnostic code. Then 
write a StuffDoerWin derivative class in a windows-only assembly, and a 
StuffDoerMono class in a mono-only assembly. Choose which one to instantiate 
using a run-time check, like:

// This is defined in a common assembly
public static abstract class StuffDoer {
public static StuffDoer CreateInstance() {
if (Type.GetType("Mono.Runtime") == null) {
// running on windows
// Use Activator.CreateInstance to return an object of 
type StuffDoerWin, from my Windows assembly
return newStuffDoer;
} else {
// running on mono
// Use Activator.CreateInstance to return an object of 
type StuffDoerMono, from my Mono assembly
return newStuffDoer;}
}
public abstract void DoStuff();  // Must be overridden in derivative 
class
}

// This is defined in a windows-only assembly
public static class StuffDoerWin : StuffDoer {
...
}

// This is defined in a mono-only assembly
public static class StuffDoerMono : StuffDoer {
// Here, I can use Mono.Posix stuff
...
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] mono-core still required after using mkbundle --static to make executable

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Eugene Kobrinsky
> 
> We finally got mkbundle --static to build a single executable of our
> microservice, but when we move it to another machine, it fails to run unless
> we install mono-core (this is all on Cent0S 7 installs).

mkbundle works poorly. If you need to use it, please ignore me. The advice is 
to rely on having a functional mono installation, unless you have a solid 
reason not to (and hence require mkbundle).
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Unix Signal in mono

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of techi eth
> 
> Thanks for quick hint.
> We can receive signal by using signal handler using
> Mono.Unix.Native.Stdlib.signal.
> I am trying to check possibility of sending signal from one process to 
> another.

Start with http://mono-project.com
Documentation > Getting Started > Overview > API Reference

And this should do it for you:
http://docs.go-mono.com/?link=M%3aMono.Unix.Native.Syscall.kill(System.Int32%2cMono.Unix.Native.Signum)

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] HTTP 500 error while accessing a webservice developed in asp.net from RHEL with Mono installed

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Madhu Gowda
> 
> I am new to linux and Mono.
> I have a simple webservice developed in asp.net using visual studio.
> I want to host this on a linux apache httpd server.

Just so you know, although .NET and mono both support ASP.NET and MVC, they are 
quite different from each other. You may have success, but I know I never had 
much luck running the ASP.NET project from Visual Studio on mono, or 
vice-versa. I found that it works well if you either (a) develop your service 
on mono, using xamarin studio or monodevelop, and then run on mono, or (b) 
develop your service in VS, and deploy on windows server or Azure.

Again, you might have better luck than me.

Side note: I'm extremely impressed with the ease of developing ASP.NET in VS, 
and deploying to azure. It's fully integrated; you just enter your azure 
credentials and Publish. I didn't feel love for mono ASP.Net a year ago, as it 
was not supported in any of the distro packages - you had to build from source, 
watch for security fixes, re-build from source to apply updates, and manage 
your own selinux/apparmor policies and stuff like that. It felt very 
undercooked to me, but some people are using it.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] System.IO.FileNotFoundException:System.Threading.Tasks.Dataflow

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of MrBlaTi
> 
> A quick search and
> https://www.archlinux.org/packages/extra/i686/mono/files/
> tells me its part of the standart mono package, wich is, in fact, installed.
> Anyone had a similar issue, or am I just being plain dumb here?

First, even though the package is installed, make sure the file in question is 
actually present, without any obvious wrong permissions:
ls -l /usr/lib/mono/4.5/System.Threading.Tasks.Dataflow.dll

On my centos6 system, the path is slightly different (no /usr) but here is what 
I see, for comparison:
ls -l /lib/mono/4.5/System.Threading.Tasks.Dataflow.dll 
/lib/mono/gac/System.Threading.Tasks.Dataflow/4.0.0.0__b77a5c561934e089/System.Threading.Tasks.Dataflow.dll
lrwxrwxrwx. 1 root root   100 Apr 25  2014 
/lib/mono/4.5/System.Threading.Tasks.Dataflow.dll -> 
../gac/System.Threading.Tasks.Dataflow/4.0.0.0__b77a5c561934e089/System.Threading.Tasks.Dataflow.dll
-rwxrwxr-x. 1 root root 84480 Apr 25  2014 
/lib/mono/gac/System.Threading.Tasks.Dataflow/4.0.0.0__b77a5c561934e089/System.Threading.Tasks.Dataflow.dll

Second, even though that seems to be the right file, there are many cases where 
namespaces and assembly names don't match, or multiple assemblies have the same 
name, etc. So just to be on the safe side, yum install mono-complete (or 
apt-get install mono-complete, or whatever).


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] File Locking

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Andy York
> 
> I have found help in the Banshee source code particularly in
> Banshee.Core/Banshee.IO.SystemIO namespace.  Also FSpot has some IO
> classes that may be of help try the FSpot.Core/FSpot.Core namespace.
> 
> A quick google search should get you right to git.gnome.org where the
> source code is housed. It has been a while since I've dealt with IO code so my
> knowledge is not incredibly recent.
> 
> I hope that helps

Thanks for trying. The two links are:
https://github.com/GNOME/banshee/tree/master/src/Core/Banshee.Core/Banshee.IO.SystemIO
 
and
https://git.gnome.org/browse/f-spot/tree/src/Core/FSpot.Core/FSpot.Core

Unfortunately I didn't see anything useful there (maybe I missed something) ... 
but thanks for the suggestions anyway.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] File Locking

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Andy York
> 
> Have you tried checking out other project in GitHub or CodePlex? I've gotten
> some really good tips from reading other cross-platform code that deals with
> locking files. Just a suggestion.

Any pointers? Just googling for "mono file lock" doesn't yield much. The 
results mostly pointed to this thread.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] File Locking

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of shrimpywu
> 
> i have the same issue. any solution?

Kinda sorta. The underlying issue is that OSX, Linux, and Windows all have 
different underlying file locking constructs, and then of course, there's some 
variability about even *which* filesystem is being used. I didn't thoroughly 
figure out all the answers for every OS or filesystem, and I don't know under 
which situations this will be good enough, but this is what I ended up using, 
works under the conditions we needed it to work:

using (var foo = new FileStream(filePath, FileMode.Open, FileAccess.ReadWrite, 
FileShare.None)) { // must include Write access in order to lock file
foo.Lock(0, 0);   // 0,0 has special meaning to lock entire file 
regardless of length
}

For windows, simply specifying the FileAccess and FileShare is good enough. For 
linux, at least ext4, files are concurrently readable regardless of what you 
specify for FileAccess and FileShare. The Lock() method does something of a 
soft-lock. It's not enforced by the OS, but at least all the situations we 
tried, other client apps honor the lock. Didn't look into it any deeper.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] WCF and Named Pipes on OS X

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Miguel de Icaza
> 
> We do not support named pipes in Mono.
> 
> Named objects were a feature that was supported on earlier versions of
> Mono, but emulating them without kernel support introduced more trouble
> and pain than it was worth.
> 
> So we removed it, and the code that supported it has been removed as well.

I vaguely recall, I thought, didn't you write a blog post, or maybe an email to 
the list, in which you described what works, what doesn't work, and made 
suggestions on how to do IPC or something? If so, I'd like to bookmark it...
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono, C#, RaspberryPi2 and MS Azure

[Edward Ned Harvey (mono)]

Well, the one thing that's clear is "Invalid certificate received from server." 
You said it works on other systems, so most likely there isn't an *actual* 
problem with the certificate, so the question is why mono on the pi is 
rejecting it.

Can you print the URL? From another system, we can connect to the URL and look 
at the certificate chain, to see if there's some other possible cause of the 
problem ... like multiple intermediates, or signed by a root that isn't in the 
Mozilla list, or using EC keys, or supporting only up to SSLv3, or supporting 
only TLS >= 1.1. Any of these would be possible explanations, that will only be 
found by inspecting the cert from another system.

If there's a general problem with mono on the pi, can you try fetching some 
other URL, such as 
https://raw.githubusercontent.com/mono/mono/master/README.md
This is just a random HTTPS url for a small file you can fetch. So you have 
more clues to figure out the cause of the problem.


> I cannot find the certificates directory to
> physically confirm they are there 

Did you check those directories?
To find out if you have root CA's installed, look in... (There's a distinct 
possibility these directories will be different for a raspberry pi ... I'm just 
not sure...)
~/.config/.mono/certs/Trust/
and
/usr/share/.mono/certs/Trust/

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono, C#, RaspberryPi2 and MS Azure

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of myusername
>  
> 

Looks like you're getting TlsException, when fetching from the https server. 
Most likely this means you don't have any installed trusted root CA's. I'm not 
sure how mono gets installed in raspberry pi, but the mono trusted root CA list 
is separate from the OS root CA list (which you may or may not have).

To find out if you have root CA's installed, look in...
(There's a distinct possibility these directories will be different for a 
raspberry pi ... I'm just not sure...)
~/.config/.mono/certs/Trust/
and
/usr/share/.mono/certs/Trust/

If there's nothing there, you might need to populate it with cert-sync or 
mozroots. (Executables that are installed as part of mono). Mozroots downloads 
the certs from mozilla over the internet. Cert-sync copies them from your /etc 
directory. 

If cert-sync and mozroots aren't available (or don't work) in raspberry pi, you 
can run it on some other system, and then copy the files, preserving 
permissions.

Since some recent version of mono (I guess around 4.1) the yum and apt packages 
automatically run cert-sync during installation. The same is not true when 
building from source, copying binaries, using an older version, or on a non-rpm 
non-deb system. Also, if raspberry pi uses a different OS root ca package, then 
even if cert-sync is run automatically on the pi, it would still fail to 
populate anything, and mozroots would then be your best bet.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Which mono libraries should be packed along with the mac app ?

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Rajesh Khan
> 
> 1- The first issue is that in my code I am doing this at the start
> 
>  mono_set_dirs("/opt/mono/lib", "/opt/mono/etc");
> 
> 2- Which libraries should be packed along with my .app ?

I don't know what mono_set_dirs is, or why you would need to use it. If you've 
installed the MDK in the normal way, and you're building and running your app 
in the normal way, you shouldn't need to do anything.

The mono class libraries are MIT licensed, so if you need to distribute those 
with your app, should be easy for you to comply. The mono runtime is GPL, so 
unless your app is GPL, you'll have a license conflict trying to distribute 
mono with your app legally.

If you pay for Xamarin.Mac, you are licensed to bundle the mono runtime with 
your non-GPL app. In fact, when you build your app, Xamarin by default bundles 
it automatically for you into the .app.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mkbundle --mono : Cannot find assembly

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Rajesh Khan
> 
> /Users/User/MyApp/ext/mono/bin/mkbundle -o createcore_managed.c -
> oo createcore_managed_deps.o -c --nomain --config-dir
> /Users/User/MyApp/ext/mono/etc --config
> /Users/User/MyApp/ext/mono/etc/mono/config --machine-config
> /Users/User/MyApp/ext/mono/etc/mono/4.5/machine.config --mono
> /Users/User/MyApp/ext/mono/lib/mono/4.5/ --deps /Users/User/MyApp-
> Build/bin/CreateCore.dll /Users/User/MyApp-Build/bin/FM.dll
> /Users/User/MyApp-Build/bin/FSLLINK.dll /Users/User/MyApp-
> Build/bin/Ionic.Zlib.dll /Users/User/MyApp-Build/bin/PList.dll
> /Users/User/MyApp-Build/bin/Renci.SshNet.dll /Users/User/MyApp-
> Build/bin/MIConvexHullPlugin.dll /Users/User/MyApp-
> Build/bin/MathNet.Numerics.dll

I don't know if the options to mkbundle have changed over the years, perhaps 
the project you're building used an old version or something like that, but I 
know (man mkbundle) that currently --mono isn't an option to mkbundle. Neither 
is --config.

If that's the build process the project gives you, obviously you have to do 
whatever they support, but in general, mkbundle isn't necessary, isn't 
beneficial, and doesn't work great. What mkbundle does is kind of analogous to 
static linking. It's supposed to build a binary that has copies of all the 
dynamic libraries built-in to it, so it's not pulling from the dynamic 
libraries at runtime.

If the project gives you any other build method, that doesn't involve mkbundle, 
give that a try.

 
> I downloaded the mono project from the git resource
> git clone https://github.com/mono/mono.git

There's also usually no reason for you to build mono from source, unless you 
want to develop mono internals. Usually the best thing to do is follow the 
instructions on http://www.mono-project.com/download/

Caveat: On redhat systems, the mono yum repo only supports the latest version. 
(No centos6). In that case, there's probably some external repo that could get 
you a recent version of mono, but I don't know off the top of my head.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Unhandled Exception on test compile

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of k.joatmon
> 
> I installed mono for one purpose, to run duplicati on LINUX. I got errors, so
> I started trying to troubleshoot them and this led me back to it being the
> mono install.  I have searched for the errors on the nabbel site and web in
> general and do not find any clue as to the solution.
> 
> The machine is running CentOS Linux release 7.2.1511 (Core)

What you've described sounds, at least approximately, like you've done things 
right. In order to help, I just created a fresh new centos7 VM, installed from 
the centos7 minimal DVD. Here are my exact steps:

sudo yum -y groupinstall base
sudo rpm --import 
"http://keyserver.ubuntu.com/pks/lookup?op=get=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF;
sudo yum-config-manager --add-repo http://download.mono-project.com/repo/centos/
sudo yum -y install mono-complete
(43 packages)

mono --version

Mono JIT compiler version 4.2.1 (Stable 4.2.1.102/6dd2d0d Thu Nov 12 04:43:41 
EST 2015)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. 
www.mono-project.com
TLS:   __thread
SIGSEGV:   altstack
Notifications: epoll
Architecture:  amd64
Disabled:  none
Misc:  softdebug 
LLVM:  supported, not enabled.
GC:sgen

cat > hello.cs
using System;

public class HelloWorld
{
static public void Main ()
{
Console.WriteLine ("Hello Mono World");
}
}

mcs hello.cs
ls
hello.cs  hello.exe

mono hello.exe 
Hello Mono World

Works for me. What's different in your system? I tried both on the console text 
terminal, and ssh'd in from Terminal on OSX. Just in case there was some sort 
of weird terminal emulation thing messing with Console.

[eharvey@centos7 ~]$ cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 
[eharvey@centos7 ~]$ uname -a
Linux centos7 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 
x86_64 x86_64 GNU/Linux

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Data protection failed exception

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Neale Ferguson
> 
> Further to the problem, tt seems to be a threading issue since if a lock
> is put around this method call:
> 
> return ProtectedData.Protect(data, extraEntropy, dataProtectionScope);
> 
> then it would work. This seems to try an access some file in .mono/keypair
> and it seems to be some concurrency issue since we have multiple threads
> all calling this code at the same time and that’s where it get tripped up.

It sounds like you've nailed it. ProtectedData indeed accesses key files in 
~/.config/.mono/keypairs (slightly different from what you said) and if you've 
got multiple threads accessing that concurrently, locking or sharing will be 
necessary. Evidently, that's not working, so it should be a relatively 
straightforward thing to test (or find in source) if mono is / isn't supporting 
locking / sharing for those operations.

Given that you wrapping ProtectedData in a lock() solves the problem, most 
likely this is a mono bug, in which ProtectedData is not threadsafe. Your 
workaround will be to continue using the lock.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Mono, Windows Forms, and Headless operation

[Edward Ned Harvey (mono)]

I think the advice would generally be:

1. Yes you can absolutely write a Console Application, which works perfectly 
cross-platform, and does not need any WinForms or X11. (Right click your 
solution, new project, Console Application). It's better to create a new 
project than to convert an existing WinForms project, unless you know all the 
details of what's different between the two types of projects. They launch 
differently, in different thread compartments, and some stuff like that - it's 
not as simple as merely removing the System.Windows.Forms reference. Which 
brings me to the second point...
2. You really should separate your business logic from the GUI code.
3. In general, you should not expect WinForms to work well on anything other 
than windows. If you need a GUI for other platforms, design a new one, or use a 
cross-platform GUI toolkit such as Eto.Forms. If you don't need a GUI... Then 
separate the WinForms GUI code from the non-GUI code, so you can build your 
non-windows project independently of WinForms.

Really, the core logic should be moved to its own assembly, so the winforms 
project and console project can both reference it.

There is *some* support for WinForms on non-windows platforms. Rarely does it 
ever work well - nobody on a mac or linux wants windows that look like WinForms 
- and that's if it works at all. (Lots of times it's straight up 
nonfunctional). Even if it works perfectly, nobody wants to be dependent on 
launching X11 on a mac, and it's only *sometimes* acceptable on linux.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Regarding - SHA-2 supported version in mono

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Kaushik Velusamy
> 
> I have a query regarding SHA-2 supported version in mono.
> 
> Novell iFloder ( On OpenEnterpriseServer11SP3) which runs on SLES11SP3
> ran into an issue because of SHA2 certificates. eDirectory has moved to SHA-
> 2 certificates and hence all components of OES needs to be compatible.
> However iFloder is having issue since MONO that is part of SLES11SP3 (
> mono-core-2.6.7-0.9.1.x86_64.rpm) does not support SHA-2.
> 
> I tried in mono-3.6 as well.
> 
> Could you tell me which is the supported mono version for SHA-2?

I think there's something wrong in your question. SHA2 (generally SHA256 to 
SHA512) is definitely supported in mono.

Your error message does say " Unsupported hash algorithm: 
1.2.840.113549.1.1.11" and the OID does map to sha256WithRSAEncryption, but the 
problem is in Mono.Security.X509.X509Certificate, which is all kinds of messed 
up, and barely functional at all. I have not heard of anyone working on it - 
but that doesn't mean they're not.

If I'm not mistaken, iFolder is not actively maintained, right? That would be a 
problem. Yes, there is a limitation of mono in the brokenness of 
X509Certificate, but assuming that's not going to be fixed anytime soon, the 
iFolder developers will basically need to find a way to workaround the 
problem...
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Debugging Mono applications under GDB

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Chris Swiedler
> 
> We have a server application that's being developed under Visual Studio and
> run under Mono 3.12. We're generating .mdb files from the .pdbs that VS
> creates. With those deployed next to the executable, mono will give full
> callstacks with source and line information when logging exceptions, so I
> believe the .mdbs are correct.

Have you considered monodevelop or Xamarin Studio?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] self hosted WCF service with client certificates?

[Edward Ned Harvey (mono)]

Martin, is this a question for you?


> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Darkness
> 
> I currently have the following up and running without issues:
> * self hosted WCF service, compiled with .Net/Visual studio 2013, running on
> Linux+mono 3.12.0
> * WCF service uses basicHttpBinding with transport security (self-signed
> certificate with rootCA certificate)
> * WCF client running on windows/.Net 4.0 with corresponding
> basicHttpBinding
> configuration
> 
> 
> The client can connect and communicate with this service (client currently
> ignores the certificate error due to self-signed certificate -
> ServicePointManager.ServerCertificateValidationCallback)

Does WCF service using basicHttpBinding use SslStream under the hood? Or 
something else provided by the OS?

Last I knew, SslStream as a server, works for self-signed certs, but fails if 
you have a real cert signed by a CA intermediate.


> However, I would like to add client certificates to this setup to be able to
> identify clients on the server side for client-specific handling.

Given that SslStream doesn't work in a *standard* configuration, is there any 
chance of client cert authentication working?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Buggered yum repo (Mono-devel-list Digest, Vol 127, Issue 9)

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Jo Shields
> 
> I've added some explicit version numbers to the download page. I was
> under the impression the Centos 7 minimum was clearer, but I was wrong.

I never saw "Centos 7 minimum" or else I would have understood it clearly.

Thanks for adding the info now.

Bummer that there's no support for Centos 6.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Using Mono/C# to develop simple OSX app

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of sams
> 
> I know this post is now forking off in all kinds of different directions but
> I just wanted to ask one more thing - the original app I was talking about
> now includes a loop that determines the size of files whose names are
> passed
> in via XML. This takes a little time to run so I'd like to add some progress
> bars. I got as far as adding them and writing the code to make them work but
> the UI does not refresh until the loop is completely finished (ie rather
> than incrementing bit by bit, the UI gets refreshed when the progress bar's
> value is set to the maximum so to the user they just appear to jump from
> beginning to end).
> 
> I have investigated a few asynchronous techniques but I have not had any
> luck. If anyone can shed some light on this, I'd be very grateful! When I
> used to program .net, the solution for me was a call to
> Application.DoEvents..

For this type of question, I've had the best luck asking in the Xamarin Mac 
forums. But if I remember when I get back here later, I'll try to answer here.

Short answer: It's very likely you're hogging the main thread. You need to 
release it and run on a different thread in order to let the main thread get 
back to the main run loop, where it handles things like GUI updates.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-dev] Buggered yum repo

[Edward Ned Harvey (mono)]

Right now, when I follow the instructions to install mono
http://www.mono-project.com/docs/getting-started/install/linux/#centos-fedora-and-derivatives

rpm --import 
"http://keyserver.ubuntu.com/pks/lookup?op=get=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF;
yum-config-manager --add-repo http://download.mono-project.com/repo/centos/

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
rpm -ivh epel-release-latest-6.noarch.rpm

On a RHEL 6.7 x86_64 box, fully updated, with EPEL repo installed, and then I 
run (as root)

yum -y install  mono-complete

I get a bunch of errors, including

Error: Package: mono-devel-4.0.4.1-0.xamarin.1.x86_64 
(download.mono-project.com_repo_centos_)
   Requires: libc.so.6(GLIBC_2.15)(64bit)

So I double-checked that my system is fully updated, and confirmed that I have 
merely glibc_2.12.

So then I thought, maybe you guys support on Centos but not RHEL? And I looked 
at what's available in Centos ... Centos only goes up to 2.12.

So I have to conclude there's something buggered in your yum repo. Requiring a 
version of glibc later than what the OS provides.

This sort of thing happens often enough, that in general I don't use the mono 
repositories (because then I get stuck in positions like I am now, where 
installing mono is blocking productivity). I have to remove the mono 
repository, and rely on version 2.10 provided by epel. I wish you could improve 
the testing of this release process.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Looking for mono expert to help debug a hanging process

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of River Satya
> 
> We have a c# binary running under mono on Ubuntu 14.04 which hangs
> periodically.
> 
> When it hangs, SIGQUIT does not generate a thread dump, and all threads,
> including one heartbeat thread that does very little but pulse the logs once a
> minute, seem to stop.

First and foremost, make sure you're running the latest version of mono. What 
version are you on?

You should also be aware, that Xamarin has a list of 3rd party contractors for 
support work like this. You should be able to find that on their website.

Sounds like (probably) a deadlock. But a deadlock between some other threads 
shouldn't affect your heartbeat thread - unless your heartbeat thread is 
dependent on something. How is your heartbeat thread written?

For example, if you have a heartbeat thread that uses a Timer, the Timer needs 
to raise an async event from the threadpool, so if the threadpool is drained by 
some other threads, then your Timer event might not occur. But if you created a 
managed instance of System.Threading.Thread, and then launched it into a 
while(true) loop, that uses System.Threading.Thread.Sleep(), you can be assured 
you don't have a dependency on the threadpool. But if you accidentally drop 
reference to your heartbeat thread, some time later it will be collected by the 
GC (while it's still running) which is no bueno. If the heartbeat thread is 
using any locking, that's a possible issue. If it's writing to some log 
resource, or file, which is shared by other threads, that's a possible issue.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Using Mono/C# to develop simple OSX app

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of sams
> 
> I did experiment with accessing a sqlite db directly
> which was also very simple to implement.

If you care about sqlite working cross-platform, be sure to test that 
explicitly. Most people run into some difficulty with sqlite cross-platform, 
but the problems are all solved if you follow the right rituals, use the right 
versions of the right libraries, etc. Write back if you have any trouble.

Glad your xam mac experience was a good one.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] basichttpbinding with client certificates not working - alternatives?

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Darkness
> 
> Regarding the win-win, mono-mono, ... client server options, this case would
> be a service on linux+mono with clients on .Net/windows.

Right now, today, there's a problem with mono SslStream operating as a server. 
I don't know precisely what class you're using as a listener - if there's 
something like HttpListener (or whatever) that exists at a higher level, it may 
not use SslStream under the hood. It may use some other OS-provided libraries. 
This is why I suggest being specific and asking on the dev list, where they 
know those details.

If whatever you're doing is indeed using SslStream under the hood, and you want 
to use a standard SSL cert, signed by an intermediate CA, the current release 
of SslStream is broken. It doesn't distribute the chain to the clients, which 
means, any client that has already cached that intermediate from a previous 
connection will mask the problem - connect fine without exposing a problem to 
you. But any new clients that require the chain will display invalid cert 
warnings on the site.

(Again, ask on the dev list) there are two workarounds that I'm aware of. I 
hacked up a version of mono to support a single intermediate. It's hacky. And 
very likely will fail to do the client cert authentication that you're seeking. 
There are some very old mono bindings for openssl - so old I wasn't comfortable 
considering it possible - but maybe you'd like to consider that option. And 
there's Eidos secure blackbox, which is a commercial product.

Or run a windows server. Or wait till mono has it fixed. (Martin currently 
working on it).

Martin, Sebastian, Miguel, or someone else, might tell you you don't need a 3rd 
party library, if you just follow some particular process that I don't know. Or 
they might suggest using one that I'm not aware of.

I'm on that list too, and I look forward to learning whatever you uncover. Good 
luck.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] basichttpbinding with client certificates not working - alternatives?

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Darkness
> 
> Transport security is working fine with basicHttpBinding, but when I set the
> transport client credential type to certificate, the client authentication
> does not seem to work on mono. (all certificates are in place)

There is a bunch of stuff related to SSL and TLS that is broken, and currently 
under development. I suspect you're probably bumping into it. I suggest you 
re-post your question to the mono-dev list - but first look at the archives and 
look for recent posts from Martin Baulig, on Nov 3 and Oct 26. Also see 
Miguel's blog post http://tirania.org/blog/archive/2015/Aug-27.html

There are a different set of compatibility issues depending on whether your 
server is mono and client is windows, or server is windows and client is mono, 
or win-win, or mono-mono. So be specific about precisely what platform your 
clients & servers are running.

There are additionally some compatibility problems, with mono servers serving 
SSL cert chains for real valid certs. I think it works if the server cert is 
signed directly by the CA root - which never happens unless you are the CA. I 
had to hack the mono server in order to make it work with a single 
intermediate, but then it works *only* with a single intermediate (doesn't work 
if directly signed by root, or if signed by 2 intermediates).

All of the issues I'm talking about are even more basic than what you're 
asking. I'm talking about simply establishing a standard, common, TLS channel. 
Your question involving client authentication with certs is even more advanced, 
even more likely to be broken.

I say ask on the mono-dev list, not only because you're most likely to get your 
answers there - You might also get suggestions such as "use eidos secure 
blackbox as an alternative."

Good luck.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Using Mono/C# to develop simple OSX app

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of sams
> 
> Thanks all, some really useful info there - I'm going to try MonoMac and the
> libraries suggested by Mel. I'll post back to let you know how I got on.

MonoMac is the precursor to Xamarin.Mac. You should use Xamarin.Mac.

If you get the Starter edition of Xamarin Studio, it'll include Xam.Mac, but 
the limitation is a small app size. And maybe a restriction prohibiting 
distribution to the app store (I'm not sure).

You should really start with Hello.Mac
http://developer.xamarin.com/guides/mac/getting_started/

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Using Mono/C# to develop simple OSX app

[Edward Ned Harvey (mono)]

> MonoMac is the precursor to Xamarin.Mac. You should use Xamarin.Mac.
> 
> If you get the Starter edition of Xamarin Studio, it'll include Xam.Mac, but 
> the
> limitation is a small app size. And maybe a restriction prohibiting 
> distribution
> to the app store (I'm not sure).

https://xamarin.com/starter
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Android - libmono.so

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of robot9706
> 
> I would like to use Mono to develop a simple test application for Android (I

Use Xamarin Starter Edition.
https://xamarin.com/starter

As far as I can tell, the only limitation of Starter is the application size, 
and you can't publish to the iOS App store. But it should be fine for your 
small Android app (and publishing to Play store).
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Android - libmono.so

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of robot9706
> 
> I can't use Xamarin to embed C# into an android native application.

"Xamarin apps look and feel native because they are."
https://xamarin.com/platform

Do you mean something else? You mean you have an app already built in Android 
Studio, and you don't want to redesign your app, but you have some little task 
that would just happen to be easiest if run in C#, so you're looking for a way 
to do that?

If that's what you're looking for, I don't know how to do it (maybe somebody 
here does - you could also ask the mono-dev list, there seems to be very little 
overlap between the two lists). You'll have to take care about licensing 
issues. When you pay for Xamarin.Mac, Xamarin.iOS, Xamarin.Android, you are 
getting a paid license that permits you to distribute the mono runtime with 
your application. If you don't pay for it, that may cause complication.

Good luck...
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Deserialising double values

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Peter Hagen
> 
> Posted:
> 
> dValue: 3.4563000202179
> dcValue: 12.3457
> fValue: 0.12345
> 
> Received:
> 
> dValue: 34563000202179
> dcValue: 123457
> fValue: 12345

You probably need to get into some specifics, like - 
When you serialize, what class or method are you using?
What string is returned?
What class/method are you using to POST?
At the server, what string is received?
The server presumably then deserializes. What's the type of the variables that 
it deserializes to?
And then the server repeats the process - it serializes. What string does it 
generate?
What string is received by the client?
What types does the client deserialize to?
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Compiling 64-bit windows mono-2.0 library with Visual Studio

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] 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@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] high performance Unix-based TCP socket server

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of hlavko
> 
> do you recommend the Mono for high performance Unix-based TCP socket
> server
> with thousands of concurrent connections?

Let us know what you find.


> I already found and tried  high performance implementation using
> SocketAsyncEventArgs

The official documentation is here:
https://msdn.microsoft.com/en-us/library/system.net.sockets.socketasynceventargs(v=vs.110).aspx


> However, I am little bit sceptical about other possible drawbacks:
> 1. Not sure if the Mono implementation of the SocketAsyncEventArgs is fully
> replacable to .NET implementation on Windows. Is it ready for production in
> the current state?

Judging by the existence of SocketAsyncEventArgs in MSDN, apparently Microsoft 
considers it production ready. To see if there are any known differences 
between the mono and ms implementations, you check the class compatibility 
pages:
http://mono-project.com
Documentation > About Mono > Class Status 
(http://www.mono-project.com/docs/about-mono/class-status/)

It's a little annoying the way the class assemblies are broken up, you don't 
really know if you should start by digging into System.Net, or something else. 
Today, the correct answer is go into System, and then System.Net.Sockets, and 
you find SocketAsyncEventArgs. It looks like mono's implementation does have a 
few known issues, so you'll want to pay attention to those. I'm not sure how to 
tell you to find more info about the known issues - Look in the mono source for 
comments on the failing items (sometimes it's just a particular argument of the 
method is unsupported, because there's no such thing in Linux, or something 
like that). Maybe search bugzilla https://bugzilla.xamarin.com


> 2. Not sure if this is still issue with last versions but I found many hate
> comments targeting Mono performance. Is Mono comparable to other high-
> level
> languages like Java/C++/.NET in the question of performance?

Ignorance is rampant on the Internet. All of the above perform excellent - but 
there are differences. I have benchmarked many different operations in mono, 
.Net, java, and python. I have found that each one outperforms the others in 
particular ways. The only way to know is to pick a specific operation you care 
about, and then benchmark it. All the results vary from platform to platform, 
version to version. Don't forget to build "Release" mode, to enable compiler 
optimizations. And if you want to squeeze more performance out of it, you might 
do an AOT fully optimized build for the platform that you care about.

The conclusion I've reached is that there is no general winner or loser. There 
are only specific winners and losers on specific things.


> 3. You know it looks like there is not many people which are going this
> server way with Mono. Also we want to focus primarily on business logic
> rather then polish and hack core server functionality. So, is it possible to
> rapidly prototype relatively stable framework around Mono or we will need
> to
> solve many hidden secrets and issues?

This is what we do at my work. We use SslStream to make mono a server, 
listener. We're using TcpListener. I'm not sure what/if there are advantages to 
SocketAsyncEventArgs, but it sounds like your requirements might be higher than 
ours. Yes, there are some issues, but we got over them, and I suspect you 
probably can too. 

The other alternatives you mentioned were Java and C++. I would anticipate java 
is probably less ready than mono for this purpose, because a java server is 
usually wrapped up in something else like apache or whatever, which handles the 
lower level socket stuff, while C# is often used for server stuff - at least on 
Windows Server. So mono's readiness really comes down to the question of how 
complete mono has implemented the .Net API. And I would anticipate this is 
probably already done excellently well in C, but a lot more effort for you to 
use. So it's really up to you to choose.


> 4. Looks like the future of Mono is in crossplatform mobile market not
> servers. (we are looking forward to next few years)

Most focus is definitely on mobile. But everything else is getting attention 
too.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono throws "OutOfMemoryException" on Linux but Visual Studio does not on Windows

[Edward Ned Harvey (mono)]

> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@lists.ximian.com] On Behalf Of Mohamadsoltani
> 
> It's 2.10.2.
> Do you now whether it is resolved in newer versions?

I'm not saying your mono version is the problem, but that is very old 
(ancient), and it seems clear you're likely to upgrade as the first attempt of 
solving the problem.

I recommend following this: (First, remove your existing mono packages)
http://www.mono-project.com/ (click Download, Linux)

They have instructions that start with adding yum or apt repositories. 
Definitely be sure to do that. It's by far the easiest best way.

And then apt or yum install mono-complete
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-dev] Unexpected binary element

[Edward Ned Harvey (mono)]

I have a project that has always built fine before, in mono 4.0.3 and 3.8.1, 
but suddenly now, when I try to do anything with 3.8.1, I get "Unexpected 
binary element."

In monodevelop, try building or cleaning, "Clean failed: Unexpected binary 
element" and "Build failed: Unexpected binary element."

When I search around, it seems people always equate this to mono version 
upgrades, or target runtimes being unsupported. So I changed all the target 
runtimes to Mono/.Net 4.5, and still have the same problem. Have not upgraded 
mono or anything.

What else could cause this?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Accessing wifi by mono

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of techi eth
> 
> What is the way to access wifi under Linux by using Mono ?

How would you do it in any other language?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Edward Ned Harvey (mono)]

I like the advice I'm getting from Alex and Robert.

Alex, you said you're using
Path.Combine(Directory.GetCurrentDirectory(), "foobar.dll")

When I look around, it seems like this might be more reliable?
Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "foobar.dll")

I'm doing pretty well now, but not done yet - I have a base factory class, in a 
factory assembly, that returns instances of derivative classes from specific 
assemblies at runtime. The new question is: My main project only needs to 
reference the factory assembly, and in fact the derivative assemblies must also 
reference the factory assembly, because they derive from the factory assembly. 
So by default, the derivative assemblies dll files don't get copied to the 
build dir of the main project. I cannot reference the derivative assemblies 
from the factory assembly, because of circular reference. But I can reference 
the derivative assemblies from the main project, which seems to have the effect 
of copying their DLL's to the build dir, as desired.

So is it safe for me to reference the derivative assemblies from the main 
project, even though the main project doesn't actually use anything from those 
assemblies? Or is it possible that the JIT compiler or something will someday 
be aggressive and cause crashing? (I think it's good - just want sanity check).

And is this a reliable way of getting the dll's to the target directory? Or 
will the compiler/linker/whatever sometimes exclude those dll's from the build 
process, because they're referenced but never used? (Again, I think it's good - 
just want sanity check).

Thanks.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] SslStream X509 certificate

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of lorenzo.delana
> 
> I'm struggling to find a way to run a SSL server on Linux using mono,
> I have a certificate with a private key installed using certmgr and I can
> see by listing that the certificate is in the store with Private Key: True

I assume you mean you have a real CA signed certificate, with an intermediate, 
right? You're not doing self-signed or anything like that - your cert is not 
signed directly by any CA. The point is you have an intermediate, that needs to 
be served by the server, right?

Mono's implementation of SSL/TLS and x509 has always been rather incomplete. In 
particular, there are a series of bugs or missing functionality that prevent a 
mono SslStream server from sending the intermediate to the client, which is a 
problem. The official fix is in progress, but still a long way off - Miguel 
wrote about it here: http://tirania.org/blog/archive/2015/Aug-27.html

For business purposes, I have had to hack it to work. Officially, you should 
probably pay for Eidos SSLBlackBox, but it's kind of expensive. Unofficially, 
you can get my hacked version at http://downloads.conceptblossom.com/mono/ and 
if you want to see my source changes ... Apparently I've deleted the github 
fork, so it'll be some effort, but I definitely have a local repo sitting 
around somewhere.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Edward Ned Harvey (mono)]

> From: Greg Young [mailto:gregoryyou...@gmail.com]
> 
> Use conditional compilation.

Unless I've somehow missed your point? You said that twice, so I want to make 
sure we're on the same page - You're talking about defining a compiler symbol, 
and then using [Conditonal] or #if, right? The end result would be different 
binaries for different platforms. But you can see in my original post, I got my 
ego bruised and I got taken down a notch by Miguel and others here for doing it 
- I am *specifically* looking to avoid conditional compilation. That was the 
point of the original question. The folks who maintain the mono source consider 
it incorrect enough to reject any pull request that does it, except for 
compiler code. I'm here to learn a new pattern that is better and more 
flexible, although not trivial to learn for the first time. That's exactly what 
I've gotten from Alex and Robert: Use a factory and two assemblies.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Edward Ned Harvey (mono)]

I've always used separate project files on windows and linux, in order to 
include different compiler symbols, in order to make projects build with 
different dependencies. I've been chastised here for doing it, so I'd like to 
find a better way. (Miguel and others tore apart a pull request, saying I 
should never check __MONO__, if I need behavior to be different on windows and 
non-windows, I need to use a runtime check. The problem is, as described below, 
the runtime check can't build or run on windows, so I'd like to figure out how 
it should be done).

Right now, I have a class, which is using Mono.Unix.Native, because of a method 
that does this: 
if (Type.GetType("Mono.Runtime") != null) {
Syscall.chmod(...);
}

When built and run on mono, works great. The problem is building and running on 
windows. In order to make it build, I copied Mono.Posix.dll into the project 
and referenced it, with CopyLocal = False. This way, Mono.Posix.dll doesn't get 
copied to the build directory, which is good because it's already present on 
mono systems, and not needed on windows systems - the only reason for it to 
exist in the project is because windows can't build without it.

So it builds. But unfortunately, it won't run on windows. It throws 
FileNotFoundException "Mono.Posix.dll" before evaluating the if-clause.

The workaround I've found is to create a wrapper class MonoSpecific, so the 
if-clause and the Mono.Posix call are not in the same file. But this is clearly 
a hack. Is there a better way?

Hello.cs:
using System;
namespace helloProject
{
static class Hello
{
static void ChangePermsIfNecessary()
{
if (Type.GetType("Mono.Runtime") != null) {
MonoSpecific.DoChmod();
}
}
}
}

MonoSpecific.cs:
using System;
using Mono.Unix.Native;
namespace helloProject
{
static class MonoSpecific
{
static void DoChmod()
{
Syscall.chmod(...);
}
}
}

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Garbage collector problem ?

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of gbenrais
 
 I have written a program with visual studio and it runs a lot slower with
 mono on my linux machine, though the linux machine has a good CPU. It
 takes
 10 seconds on windows vs 80 seconds on linux.
 The program can be summarized as a loop on objects. I printed the elapsed
 time for each iteration and it is constant on windows whereas it grows on
 linux (0.05 seconds for the first object, up to 0.45 seconds for the last
 one (up to 90 times slower)). Therefore I suppose there is a garbage
 collecor problem ?
 Any clue ?

Some things run faster in mono, and some things run faster in .Net. In extreme 
cases, one platform will run 10x or 40x faster than the other. 

Also, if you enable optimization, sometimes it results in 10x performance 
difference.

In general, it is best not to think about it too much. But if you have a 
situation where you need to think about it and dig into it, you're going to 
have to work your way down to a specific method call or something like that. 
The email you wrote above was nowhere near the level of detail necessary to 
figure it out.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] bug #28777

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Stephen Parry
 
 We have what looks like a reversion of bug #28777
 (https://bugzilla.xamarin.com/show_bug.cgi?id=28777). This is causing

You'll have to re-post this to the mon-dev list.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Monodevelop made application not starting on ubuntu

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Robert Jordan
 
 On 05.08.2015 18:40, Andres G. Aragoneses wrote:
  I hope you've considered the licensing implications. In particular,
  if you distribute the mono runtime with an application, your
  application will need to be GPL.
  The runtime is LGPL.
 
  But AFAIU when you use mkbundle you're not linking anymore, you're
  joining everything together in one executable. So then the result must
  be LGPL as well.
 
 Only if mkbundle's --static option is used. Otherwise (w/out --static),
 the bundled app is still dynamically loading the LGPLed runtime
 (libmono*.so) = the license of the bundled app does not need
 to be LGPL compatible.

This is emphatically a lawyer question. Are you a lawyer?

The legal implication of static linking files is a fuzzy one - What if you're 
not static linked but then your application gets distributed in a zip file or 
some other package that joins them all into a single file? What if that package 
file is self-executable? Very fuzzy.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Monodevelop made application not starting on ubuntu

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of onedevteam.com
 
 I'm not concerned about licences or anything else, because application i'm
 creating is for internal use only in company. I only need it to work on any
 computer running linux, without any external libs or any other user input...
 
 Just insert usb, run application and move on...

My advice is to first make it work the normal way which means install 
mono-complete from package manager.

And then incrementally try getting the mkbundle stuff to work. Because you're 
surely going to run into issues, you'll want to deal with those one at a time.

Personally I don't think it's realistic to expect users to be able to run a 
mono/gtk# application without any ability to install mono/gtk# dependencies. 
But you may succeed - Good luck.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Monodevelop made application not starting on ubuntu

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of onedevteam.com
 
 running with mono myapp.exe is not an option. I wan't application to be
 useful on computers with no mono installed.

I hope you've considered the licensing implications. In particular, if you 
distribute the mono runtime with an application, your application will need to 
be GPL.

My personal experience is that mkbundle is unreliable. But making a package 
that depends on mono-complete is reliable.

The normal thing to do is to make a package that depends on mono-complete, and 
let the package manager satisfy dependencies.

Good luck.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Monodevelop made application not starting on ubuntu

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of onedevteam.com
 
 I have made simple application with few forms, buttons and text edits in
 monodevelop for Ubuntu, using GTK, and now i'm trying to deploy it to
 another computer.
 
 I have sucessfully built an bundle using
 
 mkbundle TestApp.exe --deps -o TA

You probably don't want mkbundle, unless there's a specific reason you require 
it.

Normally, you make your application run by running mono myapp.exe and as long 
as the other computer has installed mono-complete, you can also just run mono 
myapp.exe on the target computer.

Since you said your app runs on GTK, the target computer will also have some 
other package dependencies - you'll just have to figure them out.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Problem with mono and HtttpWebRequest (ssl)

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of MkProc
 
  My best guess is that your server doesn't support below ECDHE.
 
 Yes, that seems to have been the Problem. I had my Co-worker disable it
 temponary and the exception stopped showing.

Glad and sad simultaneously.   ;-)   Glad to have found the problem, sad it's 
not going to be an easy fix (unless you can leave the server configured to 
allow TLS 1.0 without ECDHE).

If you want, you can ask on the mono-dev list, about incorporation of the 
Microsoft .Net TLS stack. Somebody might be able to give you an update on 
progress, or even an estimate on how long before it's ready.

For that matter, Microsoft might not be releasing the Elliptic Curve code 
(might be patent encumbered). I'm not sure. You can ask on mono-dev if you like.

If you want to move to a different library to support TLS, there is very little 
out there - Supposedly there's a way to make openssl work, but it looked like 
it was unmaintained. There are some other unmaintained libraries too. And the 
only *supportable* thing I've found is eldos secureblackbox. But it's not cheap.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Problem with mono and HtttpWebRequest (ssl)

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of David Curylo
 
 If you're on linux and run `curl https://your-server`, do you get any errors
 about missing intermediate certificates?  If so, mono won't be happy either.

The SSLLabs result that he posted excludes this as a possibility. I missed this 
the first time I read too:
https://www.ssllabs.com/ssltest/analyze.html?d=mars-solutions.des=188.40.173.108hideResults=on

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Problem with mono and HtttpWebRequest (ssl)

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of MkProc
 
 but using my company’s site I always get exceptions like this:
 
 System.Net.WebException: Error getting response stream (Write: The
 authentication or decryption has failed.): SendFailure ---
 System.IO.IOException: The authentication or decryption has failed. ---

Try using these guys on your company server, and see what they say. If you have 
a broken server SSL configuration, they'll expose it for you.
https://www.ssllabs.com/ssltest/index.html 

First of all, works for me. I tested on windows, mac (mono 3.12.1), and linux 
(centos 6, mono 3.4.1). I tested against my own company server.

My first suspicion, make sure your company server is correctly serving the 
intermediate cert, and that the company server is using a root which is trusted 
by the client. In Apache, the relevant directives are SSLCertificateFile, 
SSLCertificateChainFile, and SSLCACertificateFile

When you run mozroots, you only populate roots. Not intermediates. It just so 
happens, mono doesn't store intermediates, which requires the server to send 
the intermediate every time. The behavior on windows is different - Every time 
windows sees an intermediate cert, it stores it, and if any connection ever 
fails to deliver an intermediate, windows attempts to fix the broken chain by 
scanning cached intermediates. IMHO, this is bad behavior because Windows is 
covering up for a broken server configuration - but that's the way it is.

What kind of server are you running?

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Problem with mono and HtttpWebRequest (ssl)

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono)
 
 Try using these guys on your company server, and see what they say. If you
 have a broken server SSL configuration, they'll expose it for you.
 https://www.ssllabs.com/ssltest/index.html

Oh, sorry - I just saw that you already did that. And also helpful, in the 
SSLLabs report, it says your hostname, www.mars-solutions.de, and also helpful, 
when I repeat my test run, connecting to *your* company server, I get the 
exception just like you. Exception in mono only, not in windows.

The most obvious explanation would be if the server cert (or chain) used 
Elliptic Curve, which isn't supported by mono - so I looked for that, but I 
didn't see any reason to suspect it. I didn't look *exhaustively* so I could be 
wrong (need to check the server cert, the chain, and root), but at a quick 
glance, I don't think you're bumping into an EC problem.

I noticed, on the SSLLabs report, every single client handshake negotiated 
ECDHE, which isn't supported by mono. So maybe your server has disabled 
protocols that don't use ECDHE?

Mono only supports up to TLS 1.0, but I noticed in SSLLabs, that your server 
*does* support TLS1.0, so that's good.

The next most obvious thing to check for would be to ensure the CA root is 
trusted - I know it's Comodo, and seems like it's common and should be expected 
to be trusted, but perhaps Comodo pushed out a new cert that just hasn't 
propagated down through Mozilla yet. It'll take a little bit of effort to scan 
through ~/.config/.mono/certs (or the equivalent system directory) and ensure 
the root CA is present.

My best guess is that your server doesn't support below ECDHE.

They are working on pulling the Microsoft code into the mono TLS stack, which 
will solve lots of problems, but I don't know how soon it will be ready. Could 
it be years away still? Don't know.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Mono/Windows Services

[Edward Ned Harvey (mono)]

 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of Paul McEwan
 
 Thanks, the mono-service tool is working well so far

Glad it's working for you. I never had any luck with mono-service and 
mono-service2. What we did, instead, was to create a console application, and 
let upstart or systemd manage it. Easy peasy.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Porting to Linux

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of floyd
 
 We currently developed a POS system under .Net 4.5. I would like to explore
 the possibility of migrating it to linux. How hard will it be if we will use
 mono to run it to linux?

First, check for compatibility:
Start at http://www.mono-project.com/
Go to Documentation / About Mono.
See the Compatibility and Class Status pages.

Then, on linux, go to the mono download page, follow instructions to add a new 
yum or apt repo.
Install mono-complete, and monodevelop.

Monodevelop is your linux IDE. It's very nice. Try opening your project and see 
how much stuff needs to change.

In particular, don't expect winforms or wpf to be useful. The GUI will probably 
need rewrite in GTK#, or you could switch to a cross-platform GUI toolkit such 
as Eto.Forms, or XWT.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Which Mono package is for Slackware?

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of nenad
 
 I am Slackware user and I want to install Mono. Can You tell me which Mono
 package is for Slackware?

Your question is about mono. Andy's reply is about monodevelop. So that was 
probably just a miscommunication.

I haven't used slackware in 20 years, but the mono project download page 
doesn't have anything about slackware, so unless slackware is compatible with 
debian/ubuntu and derivatives, or centos/fedora/rhel and derivatives, or 
opensuse/sles, then I would have to assume, there is no slackware mono package 
aside from whatever slackware distributes.

On all those other platforms, I've had very good luck building from source. 
Simply follow the instructions (which usually boil down to ./configure  make 
 sudo make install). Hopefully you could have a very pleasant experience 
building from source. I have rarely ever seen it fail, and when it does fail, 
it has always been easy to remedy. On other linuxes.  YMMV.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono on Linux and Missing methods

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Zacharia Karami
 
 To finalize this voyage into missing methods, here's my fix for any future
 (would-be) users of MapToIPv4/6.

Why don't you submit it as a pull request for the mono source? Also, did you 
look up the Microsoft reference source?

There are two Microsoft reference sources - you have to make sure you look at 
the right one (MIT licensed) because you're forbidden to contribute to mono 
sources if you looked at the other reference source (MSPL licensed).

There's a contributing guide here: http://www.mono-project.com/community/

The contributing guide has some verbage about If you have looked at 
Microsoft's proprietary... you will not be able to contribute, but it's all 
striked-out, and added the new verbage, Microsoft open-sourced parts of .Net 
and includes a link to .Net Source Code Integration.

http://www.mono-project.com/docs/about-mono/dotnet-integration/

The first question there would be, has MS open-sourced the part that you care 
about?
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] NullReferenceException in Mono.Security.X509.X509Certificate.Hash and IsSelfSigned

[Edward Ned Harvey (mono)]

The problem is confirmed Xamarin.Mac specific. And steps to reproduce are here:
http://forums.xamarin.com/discussion/42318/sslstream-on-mac
 
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] NullReferenceException in Mono.Security.X509.X509Certificate.Hash and IsSelfSigned

[Edward Ned Harvey (mono)]

Recently, I'm encountering a problem where Mozroots is throwing 
NullReferenceException. I am working on a reproducible example, but until then, 
I'd like to revisit this issue:

First, here is reproduction code that shows the mac client requires mozroots to 
be run. This code throws exception on a pristine mac, but succeeds after 
mozroots has been run:

const string hostname = google.com;
const int PortNumber = 443;
TcpClient client = new TcpClient();
client.Connect(hostname, PortNumber);
using (var mySslStream = new SslStream (client.GetStream (), 
leaveInnerStreamOpen: false)) {
mySslStream.AuthenticateAsClient (targetHost: hostname, clientCertificates: 
null, enabledSslProtocols: SslProtocols.Tls, checkCertificateRevocation: false);
}

Given that the above throws exception, I'd like to ask, are there plans to make 
the SslStream client on mac utilize the system keychain, and if so, how soon 
might we expect it? The way things are now, we have to bundle a copy of 
Mozroots in our app, and programmatically call it. I would love to eliminate 
the need for this.

Right now, MozRoots is throwing the NullReferenceException on this line:
https://github.com/mosa/Mono-Class-Libraries/blob/master/mcs/tools/security/mozroots.cs#L158
if (!trusted.Contains (root)) {

When I debug and step through, I can see root is a 
Mono.Security.X509.X509Certificate, where Hash and IsSelfSigned both throw 
NullReferenceException if they're accessed.

System.NullReferenceException: Object reference not set to an instance of an 
object
  at Mono.Security.X509.X509Certificate.get_Hash () [0x00057] in 
/private/tmp/source-mono-mac-4.0.0-branch/bockbuild-mono-4.0.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.0.0/mcs/class/Mono.Security/Mono.Security.X509/X509Certificate.cs:301
  at Mono.Security.X509.X509CertificateCollection.IndexOf 
(Mono.Security.X509.X509Certificate value) [0x00011] in 
/private/tmp/source-mono-mac-4.0.0-branch/bockbuild-mono-4.0.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.0.0/mcs/class/Mono.Security/Mono.Security.X509/X509CertificateCollection.cs:123
  at Mono.Security.X509.X509CertificateCollection.Contains 
(Mono.Security.X509.X509Certificate value) [0x0] in 
/private/tmp/source-mono-mac-4.0.0-branch/bockbuild-mono-4.0.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.0.0/mcs/class/Mono.Security/Mono.Security.X509/X509CertificateCollection.cs:95

For reasons that I don't yet understand, this exception occurs when we call the 
MozRoots class in our app, but does not occur when I run mozroots command on 
the Terminal. So I'm still figuring this out and have not yet got example code 
to reproduce the issue.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Mono on Linux and Missing methods

[Edward Ned Harvey (mono)]

 From: Zacharia Karami [mailto:heatedphoe...@gmail.com]
 
 It works in 4.5 on Windows. But again, there is a problem (in so far that

Oh! Ok, I get it. You should check the mono class compatibility page. Although 
*most* stuff in .Net is implemented in mono, there are areas where things are 
known absent or broken. So whenever you encounter something like this, which 
works in .Net and doesn't work in mono, always start by checking the class 
status page.

From http://mono-project.com, Documentation, About Mono, Class Status,  Status.

Here, you can browse the 4.5 column, System.Net.IPAddress, and the two methods 
MapToIPv4 and MapToIPv6 are both marked as broken. There may be more info 
somewhere about *why* it's broken and what needs to happen to fix it, but that 
would be a discussion best for the mono-dev list, to assist in fixing mono 
sources.

In this case, you have a definite answer. That method is definitely just broken 
in mono, end of story. Your only solution is not to use that method on mono... 
Hopefully there is a workaround you can use without suffering too much pain.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono on Linux and Missing methods

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Heatphoenix
 
 IPaddress. When targeting Mono 4.5 this function works just fine but when
 rolling it out to my Linux development environment the function throws
 
 After a bit of research, I've found out that this is because this function
 is only in MONO / .NET 4.5 and not 4.0 and seemingly my Linux environment
 only goes up to 4.0 (because if I target 4.0 it will not compile with this
 function).
 
 How do I get my Linux to allow the usage of this function? Is this even
 possible? I am using Debian Wheezy (7.8). If any more information is
 required, please let me know.

Why is this confusing? You seem to answer your own question - It works in 4.5, 
but your target runtime environment only goes up to 4.0. So you either need to 
avoid using that method, or upgrade your target environment.

But then you said you upgraded to mono 4.0.1, which definitely supports 4.5. So 
the obvious solution seems to be, build and run with 4.5. You already said this 
works, and now that you have a recent version of mono runtime on your target 
environment, you should be good to go.

So what's the problem?
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Unable to build in mono

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono)
 
 I would suggest completely apt-get and dpkg removing *all* mono related
 packages.

Oh - I mean purge. Not remove. I don't know if it matters, but that's what I 
always do, and has worked.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Unable to build in mono

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Baltasar García Perez-Schofield
 
 AFAIK, the problem is that mono-tools-devel (from Xamarin's PPA) is not
 going to be installed because the libmono-cecil it asks for is an old package,
 instead of the modern one.

Whenever I've seen that problem before, it was always because some package was 
included from the default debian/ubuntu apt, instead of the xamarin repo.

I would suggest completely apt-get and dpkg removing *all* mono related 
packages. And then adding them again via apt-get, with obviously the xamarin 
repo included.

At least, that's what's worked for me in the past.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] just installed mono, most basic test failed.

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of David Curylo
 
 It's not like Java where you can blindly expect your code to run across
 platforms.  More like Python or Erlang or numerous other languages and
 runtimes where most of the code will work across platforms, but some
 libraries are platform-specific.

Even in java, python, or any other language, you can't just build and test on 
one platform and blindly expect (without testing) that it will work on another 
platform - because there exist platform specific variations.

For example: If you wrote an https server application, and it ran on windows as 
a service, it *won't* simply run on linux. Because binding low numbered ports 
requires root escalation. So you need to be careful to launch your application 
as root and then make a POSIX call to drop privilege after the port is bound.

And if you use a path like C:\foo\bar your app will break on a non-windows 
platform. And even if you do the smart thing using special folder 
enumeration... Personal evaluates to My Documents on windows, but evaluates 
to your home directory on linux/unix. So you have to use *different* special 
folder enumerations on different platforms, in order to have the same effect.

Not to mention differences of supported filesystem characters... Path separator 
char '/' vs '\' ... 

Case sensitive filesystems, vs case insensitive... Unicode vs Ascii ...  
Disallowed characters in windows...  Maximum path length in windows that 
doesn't exist in linux/unix...

What else? There are simply TONS of differences that are different on different 
platforms, regardless of the language you use. It is not realistic, in *any* 
language, to write and test on one platform and expect it to be functional on 
another platform without testing. Unless your app is a trivial calculator or 
similar.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] just installed mono, most basic test failed.

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Pierre-François Culand
 
 Actually I observe Mono is not a fully functional and complete .Net
 Framework virtual machine for Mac... It's a pity...

Nothing's perfect, but for a guy who says he doesn't want to develop, build, or 
test on a different platform - just expects the binaries to unconditionally run 
on different OSes with zero effort - nothing in the world will ever be good 
enough.

Glad it almost worked. I guess.  :-/
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] ECDSA support

[Edward Ned Harvey (mono)]

 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of techi eth
 
 Is mono support ciphers ECDSA ?
 Mono 4.0.0 release show some handling of same under mono-
 4.0.0/external/referencesource/System.Core/System/Security/Cryptograph
 y.
 Please let me know how to use the same in build.

Just in case you want, there's an example of bouncycastle ECDH usage here:
https://github.com/rahvee/CBcrypt/blob/master/CBcrypt/CBcrypt/CBcrypt.cs#L129

Depending on what you want to do, you might even use CBCryptKey from the above 
project (also available in NuGet). I found bouncycastle's API quite lacking in 
documentation, and kind of difficult to use, so the most useful stuff was 
abstracted to
https://github.com/rahvee/CBcrypt/blob/master/CBcrypt/CBcrypt/CBCryptKey.cs 

The ECDH and ECDSA keys are exactly the same - but it's recommended you be 
explicit (don't just use EC), and only use a key for its intended purpose. As 
far as I know it's not well studied if there might be some bad interaction 
between the ECDH algorithms and ECDSA algorithms. In other words, don't use a 
single key for both ECDH and ECDSA. Generate separate keys if you need both. 
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] ECDSA support

[Edward Ned Harvey (mono)]

 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of techi eth
 
 Is mono support ciphers ECDSA ?
 Mono 4.0.0 release show some handling of same under mono-
 4.0.0/external/referencesource/System.Core/System/Security/Cryptograph
 y.
 Please let me know how to use the same in build.

If it's not coming for any reason, I know bouncycastle has it.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] just installed mono, most basic test failed.

[Edward Ned Harvey (mono)]

 Oh, you should give up now. There is no chance of simply taking a complex
 app already built and developed in VS/Windows, and then straight up
 launching it under mono on a different platform and expecting it to work.

To REALLY get to the bottom line, just do this:

You have installed the MDK on a mac. Now copy all your app's exe and dll files 
(and any other necessary files) to some directory on your mac, and simply 
launch:
mono yourapp.exe

If it runs, kudos to you. You either have a trivial app, or you've disproven 
what I said above.

If it doesn't run, then there's no escaping the fact, that additional testing  
development would be necessary to make it run.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] just installed mono, most basic test failed.

[Edward Ned Harvey (mono)]

 From: Pierre-François Culand [mailto:p...@culand.ch]
 
 I do not intend to develop nor compile my app on the Mac/mono. I just want
 to deploy and run the already compiled WCF Winforms client .exe app with
 its WCF config file to consume the WCF service.

Oh, you should give up now. There is no chance of simply taking a complex app 
already built and developed in VS/Windows, and then straight up launching it 
under mono on a different platform and expecting it to work. Also if you check 
the mono compatibility page, it says limited WCF which may or may not affect 
you. I don't know if limited WCF compatibility affects server-side, 
client-side, or both.

In reality, if you want to develop cross-platform, you can achieve  95% code 
reuse, and binary compatibility across platforms, but it's not going to happen 
automatically except for trivial apps or libraries. You have to develop and 
test with that goal in mind. You need VS on windows, and XS/MD on mac and/or 
linux. And you need to test on every platform that you care about supporting. 
There *will* be differences in the OS, as well as differences between .Net and 
mono, which you'll have to workaround.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono GUI toolkits

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Elmar Haneke
 
 Gtk is an multi-platform-toolkit, you can use it on all important
 Desktop systems: Windows, MacOS and Linux.
 
 The only problem is 

... Let me stop you right there. Because to me, the only problem is the fact 
that GTK is not natively included with either windows, mac, or mobile OSes, and 
due to LGPL, it's very unclear if you can legally bundle it with your 
application. 

GTK is LGPL, not GPL. But you need a lawyer to understand if that's ok for you, 
because the GPL itself is one long-ass license, and the Lesser part almost 
doubles its length. It's not an attractive license, like MIT.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] just installed mono, most basic test failed.

[Edward Ned Harvey (mono)]

 From: cov...@ccs.covici.com [mailto:cov...@ccs.covici.com]
 
 Why not use vs 2015 and vs code, supposed to work on Windows, OSX or
 Linux, although I don't know what versions of OSX they are supporting.
 I wonder how long mono is for this world?

Is that just a blatant troll? Even with .Net being open source, you cannot ever 
expect it to simply compile straight up, on a non-windows platform. Lots of 
changes are required under the hood to implement things like file and socket 
operations, which are fundamentally based on different underlying technologies. 
You should not expect such an effort to ever be done - because it's already 
been done in mono, and there's no motivation for anyone to repeat all that work 
in a separate project.

So the long and short of it is: You should expect mono to adopt the .Net source 
code rapidly, and therefore mono is and will continue to be indefinitely, the 
canonical way of running .Net code on non-windows platforms.

It just so happens, VS is better than XS/MD in a lot of ways... But XS/MD is 
also better than VS in a few ways. Particularly, I don't think you should ever 
expect VS to build a Xam.Mac project, and in VS, if you want interactive code 
analysis you have to pay for Resharper. But that capability is built-in to 
XS/MD.

Personally I like to edit code in both XS/MD, and VS, so I can take advantage 
of the strengths of each.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] just installed mono, most basic test failed.

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of ChipRaptor
 
 I compiled and ran the basic tests proposed on the mono page at
 http://www.mono-project.com/docs/getting-started/mono-basics/

I recommend, forget about it unless you care - 

GTK isn't usually used anywhere except on Linux.
Normally on the mac, you're using Xamarin.Mac, or MonoMac.
Normally on windows, you're using WinForms or WPF.

Definitely *don't* bother with winforms on non-windows platforms. Nobody has 
ever had a good experience with that. If you're looking for a cross-platform 
GUI toolkit, you can look at Eto.Forms and XSP. But I think most people just 
design business logic separate from GUI code, and build native GUI's on 
Xam.Mac, GTK#, and Winforms/WPF.

If you're looking for cross-platform GUI toolkit for mobile devices, there's 
Xamarin.Forms... And probably some competitors, but I don't do this, so I don't 
know.

So the big questions are - What do you want to accomplish? Are you planning to 
develop mono sources and contribute to mono? Or do you just want to learn mono 
and start doing cross-platform stuff like you were doing on .Net with VS?

If you want to just develop .Net applications, I would suggest: Install 
MonoDevelop (which is completely free, and confusing, because after 
installation its name will be Xamarin Studio, but if you were to go to the 
xamarin downloads page to download xamarin studio, it's not free). Play around 
with the Xamarin.Mac Hello Mac. Play around with GTK# on linux.

Installing the MDK is pretty brainless and straightforward. And in fact, you 
can run your apps just because the MDK is installed. But you don't want to (and 
sometimes can't) make it a requirement for end users to install MDK in order to 
run your app - If you pay for Xam.Mac, there is a checkbox inside your xam.mac 
project to bundle the runtime with your app. This is by far, the recommended 
way to go. (And a requirement, in order to distribute in the appstore).

MonoMac and Xamarin.Mac are the same thing - except Xam.Mac has been developed 
more with more features added onto it. So you can get a good idea how to design 
basic forms and how the threading model works using MonoMac, and then pay for 
Xam.Mac when or if you need it.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] which confused about which mono

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Matt Calder
 
 Thanks for all the help. Elmar takes the prize, an alias apparently added in
 2011! was causing the problem. Years of install difficulties possibly 
 explained?
 Thanks again,

LOL, that is pleasing.  ;-)
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] which confused about which mono

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Martin Thwaites
 
 do you have a mono version in ~/tmp/mono? if so it will use that first, but i
 don;t think which takes into account your current directory.

I am also somewhat perplexed by the question - because which is supposed to 
follow your PATH environment variable exactly like your shell does. So if you 
have . on your PATH, then which and bash would both use it. Otherwise, they 
would both not use it.

The only difference between calling mono, and calling /usr/bin/mono, is the 
fact that you specified /usr/bin. And this difference is detectable by the mono 
runtime. Evidently, as surprising as it is, it seems something in the mono 
runtime is actually using that, and behaving differently as a result.

Matt, just for the heck of it, try this:

ls -ld /usr /usr/bin /usr/bin/mono

drwxr-xr-x 10 root root  4096 Oct 24  2013 /usr
drwxr-xr-x  2 root root 36864 Apr  9 15:27 /usr/bin
lrwxrwxrwx  1 root root 9 Apr 25  2014 /usr/bin/mono - mono-sgen

mono is normally a symlink pointing to mono-sgen. In fact, guess what? Some 
other symlinks may also point to mono-sgen, and the way mono-sgen figures out 
what it's supposed to do, is by looking at the name by which it was called. So 
it makes perfect sense that it will behave differently depending on how it's 
called... But I cannot explain the 3.2.7 vs 4.1.0 thing right now.

I suspect, something along the lines of ... mono-sgen thinks to itself, If I 
was called 'mono' then search for libraries on [some set] of directories. But 
if I was called '/usr/bin/mono' then search for libraries on [some other set] 
of directories.

You'll probably have the best luck asking in the mono-devel list.

Also, try repeating your test, when your PWD is some other directory. For 
example cd to your home directory, or cd /usr/bin, and see if the behavior 
changes.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] [mono][CPPSharp][GSoC'15] Introduction and asking for furthur guidance

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Abhinav Tripathi
 
         I am Abhinav Tripathi. I have been selected for CPPSharp - Inline C++
 Code Improvement project under Mono... I have a good C++ experience
 and am new to C#. I am a 2nd year B.Tech Student.
 I was looking for guidance on how to start the project and as a first step how
 to set-up my development environment (which tools will be
 preferred/required)!

Go get monodevelop, for whatever platform you're on (windows, linux, mac). If 
you're on windows, you should consider getting Visual Studio (they have some 
free versions).

Simple as that, go nuts. If you feel like it, google for some hello world 
projects, but it's really not needed - just click New Project, Console App or 
windows forms, or wpf, or monomac (xamarin.mac free), or whatever.

Yeah, on mac, I would recommend reading the Xamarin.Mac getting started guide. 
And I'm sure there's something similar for Gtk# for linux.

And just start reading everything everywhere.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Does Properties.Settings.Default.Save() work under Linux

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of ChrisD
 
 I am having problems saving user settings under Linux. Everything works fine
 if I run under Windows.
 
 On Linux, I copy the files appname.exe and appname-exe.config to appname
 directory and execute using

The first thing is, don't expect windows forms to be cross platform compatible. 
They're kinda sorta implemented in mono, but not good. The recommendation is to 
either design the business logic to be cross-platform, and then design the GUI 
separately for each platform (probably GTK# for linux), or use something that's 
intended to be cross-platform, such as Eto.Forms, or XWT.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] will this .NET project run with mono?

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of William Ivanski
 
 You can try to find these DLLs in Windows, put then in your bin folder, and
 reference them in your Mono project.

Pretty unlikely to work, given that MS didn't test on mono.  Also I wouldn't 
recommend distributing those dll's with your project due to license 
restrictions.  Sounds like a pretty unsustainable (and unlikely) solution at 
best.  If you have a .Net project that requires assemblies that don't exist in 
mono, your best bet is to search for alternative assemblies that can be used 
instead, which are cross-platform compatible.

But Tomasz - Did you check the mono compatibility guide and class status page?  
Why do you believe these are part of .Net and not part of Mono?  The easiest 
way to describe what Mono currently supports is:  Everything in .NET 4.5 except 
WPF, WWF, and with limited WCF and limited ASP.NET 4.5 async stack. 

I don't think the assemblies you've named are WPF, WWF, WCF or ASP.Net.  So I 
would expect *either* the stuff you're looking for is available, or it's from a 
3rd party other than Microsoft, and therefore actually pretty *likely* to work 
on mono.

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Is mono ready for backend deployment?

[Edward Ned Harvey (mono)]

 From: Gelin Yan [mailto:dynami...@gmail.com]
 
 Unfortunately, at the time, mono crashed each time after a few seconds of
 pressing tests. (IAsyncResult was slightly better,
 it lasted a bit longer).

Check the mono compatibility guide.  All the async stuff, except for ASP.Net, 
has stabilized and is well supported, since ... I'm not sure when ...  But I 
know it wasn't stable in 2.10 when you tested it, and it is stable now.  I also 
know if you had checked the compatibility guide in the days of 2.10, it would 
indicate async was not yet stable.  Familiarization with the compatibility 
guide and the class status guide is an important part of cross-platform 
development for .Net and mono.

http://www.mono-project.com/docs/about-mono/compatibility/
and
http://www.mono-project.com/docs/about-mono/class-status/ 


By the way, Do you have any info about tuning GC on mono?  When I
 searched mono, gc tuning on google,  only a few results came out and a
 little bit outdated.

I have not had any reason to tweak the GC, but if you post questions here about 
it (start a new thread) other people here are experts on GC and can answer your 
questions.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Is mono ready for backend deployment?

[Edward Ned Harvey (mono)]

 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of Gelin Yan
 
    A few years ago, I tried to port one of our server from .net to mono. At 
 the
 time. Mono 2.8 was just out. My server use socket (tcp almost)  thread
 pools heavily.

You're making a blanket statement, ready.   My blanket response is:  Yes.  
Mono is ready.*

* Going into a little more detail, no matter what, you must acknowledge that 
there are major architectural differences between Windows, BSD, Linux, etc.  
Mono and .Net are enormous, and there *are* differences, and there always will 
be.  So you can never say It's ready meaning 100% compatible and bug-free.  
(Guess what, in my experience, I've found about equal numbers of MS bugs and 
Mono bugs.)  What you can do instead, is to develop and test on multiple 
platforms, and anyplace where something is different, solve the problem.

I personally develop a commercial product, that has windows/mac/linux client 
and server components, doing a lot of SSL communications over unreliable 
network connections.  We develop code on .Net, test on mono, and for the 
non-GUI server backend stuff, around 99% of the code simply works without any 
modifications.  We run into occasional snags, like, managing the SSL certs 
differently on each platform, and privilege escalation to bind port 443, and 
stuff like that, which are intrinsically different on different platforms.  
FileSystemWatcher works perfectly on windows  linux, but the BSD 
implementation of kevent/kqueue is fundamentally flawed and will never work, so 
FSWatcher simply doesn't work (reliably) on macs.  We had to get Xam.Mac and 
use FSEvents.  Also, mutexes and inter-process signalling, and file locking - 
we've had to do work in order to support multi-platforms, due to fundamental 
differences in the different platforms.  It's impossible for mono (or anything 
not running on windows) to implement file locking as designed in the MS API.  
Differences of filesystem charset, path separator character, etc.  Dramatic 
difference in RSA key generation, and absent support for EC keys...  To name a 
few of the areas that are different between .Net and mono.

You might be like I was originally - assuming .Net was better - but I have 
found in many regards, neither .Net nor Mono is better.  They each are better 
in specific ways, and the number and severity of differences doesn't add up to 
a clear one is better.  For example, I found that .Net's implementation of 
RSA key generation greatly outperforms mono's implementation, but mono does a 
lazy key generation which means 99% of the time you can completely skip key 
generation (depending on your usage model).  And there's a huge list like that. 
 Dramatic performance differences in SHA and stuff.

We make heavy use of tcp sockets and threadpool, as well as manually managed 
threads.  Threadpool:  No issues whatsoever.  Tcp:  the timeout setting doesn't 
work unless you set it at the right time ... I forget ... after the connection 
is established?  I forget, but I could look it up.  We decided to manually 
manage the tcp timeouts.  (Not difficult; every time we create a TcpClient, 
create a timer, and when we receive bytes, consider resetting the timer).  
Whatever you do, frigging *don't* call Dispose on a SslStream.  On heavily used 
linux servers, we had to increase the number of tcp sockets in kernel - I could 
look up details if needed - 

So I would say ultimately, Tcp:  Barely any issues, which were easily managed.  
Unfortunately, SslStream was (and still is) not easily managed, if you happen 
to want a mono SslStream server.  But you didn't say SSL; you said TCP sockets. 
 ;-)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Mono in the mainstream

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Tony Gravagno
 
 run over CentOS or Ubuntu, Apache or Nginx. They're used to mod_perl and
 mod_php, but not mod_mono, and they may support FastCGI. But they

Right now, asp.net doesn't work out of the box on debian/redhat based distros 
that I'm aware of.  But hopefully this will be improving soon, because in fact 
it *does* work when you build from source, which is straightforward and easy.

I have also found, that there's almost no compatibility between MS asp.ent, and 
Mono asp.net.  Meaning - if you create an asp.net project in VS, or in XS/MD, 
and then try to run it on the other platform - there is almost no template that 
works on both, and the templates bear almost no semblance to each other.

For the time being, if you want to host asp.net, I would suggest:  This is 
something MS does extremely well on Azure.  You just go into VS, click New 
ASP.Net project, and then Publish using your Azure username  password.  
Nothing could possibly be simpler or more powerful...   This is assuming you 
have VS and Windows laying around to do development on...
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Generic class and mono_class_from_name

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of mimi
 
 public Dictionarystring,object DictionaryField;

Unrelated to your actual question, it's recommended that you make public things 
Properties instead of Fields.
public Dictionarystring,object FooDict { get; set; }

This is basically because if you later need to add something like a set 
accessor for data scrubbing or validation checking, by having a property, you 
have not changed your interface.  If you change a field to a property, it's 
considered a breaking change - meaning - all your code and all the code that 
depends on your code needs to be recompiled and the binaries are not compatible 
with each other.  If you want to know more, you can google for properties vs 
fields.  Lots of people have written things about it.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Setting up development enviroment for monodevelop

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Mohamed Alzaki
 
 I'm trying to set up my development enviroment and i've builed
 monodevelop successfully but when i mange to run using 'make run' it Fails
 and shows the following Error :-
 MonoDevelop failed to start

I've never heard of make run ... If you successfully built monodevelop, you 
should probably just launch the monodevelop binary directly.

That being said, here's the advice I would normally give you - Building 
monodevelop from source can be quite tricky, and I don't recommend it.  The 
easiest best thing to do, unless you have a reason not to, is to use a mac or a 
modern ubuntu desktop.  The mac version simply installs, no problem.  The 
ubuntu package repositories have a decent version of monodevelop included, so 
you can just simply install via apt or whatever.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] System.Net and SynchronizationContext

[Edward Ned Harvey (mono)]

 From: Federico Di Gregorio [mailto:f...@dndg.it]
 Sent: Friday, March 6, 2015 8:43 AM
 
 http://blogs.msdn.com/b/ericlippert/archive/2009/04/29/events-and-
 races.aspx

Good one, thanks.  :-)  If Eric Lippert says so, it is canonical.  The only 
reason the other pattern was used is because the person who wrote it didn't 
know at the time.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] System.Net and SynchronizationContext

[Edward Ned Harvey (mono)]

 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of Federico Di Gregorio
 
 I have discovered that the Mono implementation of WebClient doesn't
 behave as described in this MSDN article:

It seems, the class status page for WebClient indicates as you've said - is a 
known issue - Many of the Async methods are marked as broken or incomplete.
http://go-mono.com/status/status.aspx?reference=4.5profile=4.5assembly=System

So the solution is to workaround until it's fixed.


 I can probably provide some patches but I don't know if there are plans
 to replace that code with the one MS open sourced.

That is the big operative question.


 As a side note, inspecting the code I found that in quite a lot of
 places Mono doesn't implement the event handler pattern correctly doing:
 
 if (Event != null)
  Event(args);
 
 instead of:
 
 var e = Event;
 if (e != null)
  e(args);

I agree that the pattern you've suggested is the better pattern, to avoid 
NullReferenceException in a race condition.  I don't see anything official 
out there suggesting this pattern; in fact, all the example code I see from 
msdn and elsewhere uses the former pattern.  Your post is the first time I've 
heard of the new pattern, and I'm going to use it from now on.  Hopefully 
nobody objects to the suggested new pattern, and hopefully those changes are 
acceptable, but if not, maybe you can find something official suggesting the 
new pattern.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Native number types but not general number type?

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of Michael McGlothlin
 
 Likewise I'd like to more easily use lossless numbers of unlimited size,
 including fractional values, 

You might have better luck with a specific question, but in general, what 
you're asking is impossible.  For example, how can you losslessly represent 
1/3, or pi?

Well, if you're using base-3, you could losslessly represent 1/3 as 0.1, but in 
base-2 or base-10, it's an infinitely repeating number.  So let there be an 
arbitrary-base number system with arbitrary precision...  Now what if you take 
base-3 (0.1) and multiply it by base-7 (0.1), the lossless result is base-21 
(0.1).  Which brings up a new question - base-21 (0.1) multiplied by 20 is 
20/21, so how do you represent that?  For hex base-16, we can go up to F to 
represent 15, so I guess in base-21, we could go up to L, but for 
arbitrary-base, you could have infinite numbers to represent the first column.  
For example, the number 1,000,000 (decimal) could be equally represented as 
base-1,000,000 (1).  It would work (inefficiently, with lots of ambiguity and 
wrangling) as long as every number could be represented in rational form.  

So then you're stuck being unable to represent irrational numbers...  Such as e 
and pi
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Fasycopy in Mono

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of AniTa Wang
 
 I am doing an experiment to measure the performance improvement of
 Fasycopy function in Mono. The version I am testing is Mono 2.4. However, I
 have some difficulties in finding applications that use the Fastcopy function.
 Can anyone give me some guidance on how to trigger this function, or send
 me some programs that uses Fastcopy? Thanks in advance.

Can you post a link explaining what fastcopy is, and where you found it?  I 
have never heard of it, and searching for fastcopy on the internet doesn't 
produce a lot of mono-specific or .net-specific results.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Integration Tests

[Edward Ned Harvey (mono)]

 From: Miguel de Icaza [mailto:mig...@xamarin.com]
 
 • We are setting up a more comprehensive harness for SSL/TLS tests that do
 not depend on remote servers.

This is much appreciated, thank you very much.  There is one thing you didn't 
mention:

As far as I can tell, no mono developer has ever tested the real world use case 
of SslStream.AuthenticateAsServer with an intermediate cert connecting to 
SslStream.AuthenticateAsClient.  As far as I can tell, no mono developer has 
ever bothered to run the test I provided in the pull request.  The end result 
is that mono's implementation of SslStream.AuthenticateAsServer is simply 
broken, not usable, has never worked, still broken today.  I have a dirty 
hacked fork of mono that made it work, but those changes not suitable for pull 
into mono (see: dirty, hacked).

If it helps, I wrote a script that automates the creation of a root CA, 
intermediate, and signing of a server cert, suitable to be used in such a test. 
 Even if the script doesn't get run automatically in the build process, it's 
perfectly acceptable to generate certs in advance and hard-code them into the 
tests, as is done in existing pull-request test today.

The script is here:
https://github.com/rahvee/MonoSslStreamServerBug/blob/master/certs/junkca.sh

And having used the above script to generate some certs, a hard-coded result is 
stored here:
https://github.com/rahvee/mono/commit/02ae92b34f47779c1962d38ffdcf6e732f10b063#diff-05497f49a91426be05c25bbebc4e3a59R59

There is no reasonable reason to expect it to ever work, if it's not tested.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] Mono crashes on buttonpress

[Edward Ned Harvey (mono)]

 From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
 boun...@lists.ximian.com] On Behalf Of MonoLoG
 
 But, while i have the KeePass-window selected, as soon as i press the
 'windows button' mono crashes.

This is a question for the keepass developers.  Mono doesn't crash.  Mono is 
an implementation of the C# programming language (for all intents and purposes 
in this conversation.)  So if the application crashes, it's due to an error in 
the application.

If there is a problem in mono, the application developer (or anybody, really) 
would need to say The following class or method in mono is expected to perform 
X, but the actual result is Y, this is a bug, submit bug report, etc.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-dev] Integration Tests

[Edward Ned Harvey (mono)]

Does Mono have any sort of integration tests?  Maybe that's where this belongs? 
 I would like to make sure at some point, SslStream will be fixed, and the 
reason it hasn't happened so far was because nobody ever tested it with 
intermediate chain served by the server, which is of course the typical real 
world usage - I wrote a unit test for it, but have not had any progress getting 
it accepted, mono developers aloof and unresponsive, don't know why - I guess 
it's because it's more an integration test and not really a unit test - the 
inactive pull request is here:

https://github.com/mono/mono/pull/1490

I also have not been able to get any response from Martin Baulig, working on 
the updated TLS code, so it seems likely SslStream will continue to be useless 
as a server, unless something gives... 
https://trello.com/c/PvUaV89u/16-tls-stack

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] What will happen if Dispose() hangs?

[Edward Ned Harvey (mono)]

 From: Greg Najda [mailto:gregna...@gmail.com]
 
 Regarding the TcpClient timeouts, if you are setting the timeout before
 connecting, it is ignored. That is a bug. See
 https://bugzilla.xamarin.com/show_bug.cgi?id=25365. As a workaround you
 can set the timeout after connecting.

Client-side, indeed I was setting timeout before connecting - Thanks for the 
tip.
Server-side, I was setting the timeout on the TcpClient after 
TcpListener.EndAcceptTcpClient.

And the problem I'm observing is server-side.  So unfortunately this workaround 
doesn't work for me (for this situation).

The question still stands about what happens if Dispose() hangs during garbage 
collection...
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] What will happen if Dispose() hangs?

[Edward Ned Harvey (mono)]

 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of Robert Jordan
 
 You may want to look up how a sane IDisposable pattern has to be
 sensibly implemented in .NET. You'll find out that Dispose()
 shouldn't be called from a finalizer.

Uhmm...  You got that wrong.  Here is the recommended pattern:
https://msdn.microsoft.com/en-us/library/b1yfkh5e(v=vs.110).aspx

Basically, *always* call Dispose(false) from the finalizer, if present, but 
avoid having a finalizer unless you need one.

Fortunately, it looks like SslStream has no finalizer, so I guess the GC will 
never call any variant of SslStream.Dispose.  So I guess it's no problem.


 A blocking finalizer will hang the GC, but it looks like SslStream is
 implementing finalization correctly:

Finalization seems to be correct.  But Dispose hangs.  Doesn't seem to be the 
fault of SslStream, but one of the dispose methods that gets called, either 
directly or indirectly, from the SslStream Dispose method.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] What will happen if Dispose() hangs?

[Edward Ned Harvey (mono)]

When I call SslStream.Dispose(), the thread simply hangs indefinitely.  (Well, 
I didn't wait forever; only a few minutes, which is longer than the underlying 
TcpClient timeout periods.)

Obviously this is a bug, but my question is - What if I simply ignore the 
problem, and don't call Dispose, and just drop reference to the SslStream?  
Presumably the GC will call finalizer, which will then call Dispose().  Will 
the GC thread also hang?  Will it put mono into a bad state?  What could 
possibly go wrong?

Possibly related - I observed that when I set TcpClient read  write timeouts, 
they seem to have no effect.  Set to 6 (60sec), wait a few minutes on a 
Read or Write (actually BeginRead/EndRead, or synchronous Write) and nothing 
happens.  Thread just blocks indefinitely or the end method is never called.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Fork of certmgr - any ideas?

[Edward Ned Harvey (mono)]

 From: Arthur Peka [mailto:artur.p...@gmail.com]
 
 I don't see any solution files which can be easily
 built with xbuild/Monodevelop.

When you reply, please quote what you're responding to, and don't top post.  
Makes it hard to follow the conversation.  (Etiquette.)

You clearly have created solution  project files.  I don't know how difficult 
it was, but maybe you missed this comment?
http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042674.html

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] cert-sync

[Edward Ned Harvey (mono)]

 From: Sebastien Pouliot [mailto:sebastien.poul...@gmail.com]
 
 No. WebClient, HttpWebRequest, the default HttpClient handler... all uses
 SslStream which delegates the trust decision to the OS (on iOS, Android and
 Mac).

Wait - We've already established in this thread (see links below) that on Mac, 
SslStream.AuthenticateAsClient throws IOException if the Trust directories were 
empty or nonexistent, and SslStream.AuthenticateAsClient works fine if you've 
run mozroots, but on the same system with empty Trusts, 
WebClient.DownloadString works fine.  This suggested that WebClient delegated 
trust to the OS, while SslStream used the .Net trust store.

Are you saying that WebClient uses SslStream in some way different from using 
AuthenticateAsClient?

I tested OSX SslStream.AuthenticateAsClient without mozroots.  Failed.
http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042668.html

Alexander tested WebClient.DownloadString without mozroots.  Succeeded.
http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042672.html

Alexander confirmed my results.
http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042675.html


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Fork of certmgr - any ideas?

[Edward Ned Harvey (mono)]

 From: Arthur Peka [mailto:artur.p...@gmail.com]
 
 stores). I want to improve usability, e.g.
 * Listing certificates from all the stores (except Untrusted) when called 
 with -
 -list -c without specifying the store. Now it fails when no store specified. 
 Can
 be useful to get all trusted certs.
 * When importing some well-known certificates (e.g. some Nuget-related),
 certificate is claimed to be invalid. Needs investigation.
 * Unit/integration tests
 * Colouring output for readability?
 * Other?

Those sound like good improvements - but I don't see any reason they shouldn't 
be part of mono.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] cert-sync

[Edward Ned Harvey (mono)]

 From: Sebastien Pouliot [mailto:sebastien.poul...@gmail.com]
 
 Thanks - so it sounds like WebClient, on OSX, iOS, and Android, are wrapping
 around some API provided by the OS, correct?  Is the same true on linux?
 
 No, not for Linux. There is (or at least was) no OS API that provided that
 service and not every distro shipped/installed-by-default any library that
 could do this.

Thanks - so the present status is, WebClient should work on non-linux 
platforms, (at least OSX, iOS, and Android) even with an empty mono CA root 
store Trust.  On linux, the mono store Trust needs to be populated - but 
recently, the rpm  deb packages were improved to automatically populate via 
cert-sync.

Presumably there is no automated process to do this when built from source.  
Perhaps either the Makefile, or documentation should be updated to suggest 
running cert-sync on linux when built from source.

SslStream and other classes that rely on the .Net cert store management, are 
less fortunate - the mono CA store Trust must be populated.  This happens 
automatically when using the latest linux packages, but does not happen 
automatically for any other platforms, and not if built from source.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Fork of certmgr - any ideas?

[Edward Ned Harvey (mono)]

 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of Arthur Peka
 
 don't understand about what of kind of 'ethics' we can talk here.

Etiquette.  Not ethics.


 http://tirania.org/blog/archive/2010/Dec-31.html

Arthur, how about this:

Sometimes it may be true that it might be difficult to get changes pulled into 
mono source, but you haven't made a compelling case for certmgr to be separated 
out from mono source.  What exactly are the improvements you want to make, and 
why shouldn't they be part of mono source?  The changes that are in your fork 
seem to be all stylistic changes, refactoring variable names, changing 
whitespace, etc.

It's not clear right now, what the improvements are, or should be.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Fork of certmgr - any ideas? (Mono-devel-list Digest, Vol 117, Issue 32)

[Edward Ned Harvey (mono)]

 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of Jo Shields
 
 it's
 easier to work with a standalone MD project than the whole Mono tree,
 when doing breakpointing  object inspection

Something I've certainly done in the past to debug mono sources, was to create 
a MD/XS solution in the mono source dir locally on my system, with a really 
basic console application that referenced some mono classes, so I could then 
debug my console app  step through mono source in the IDE.  After doing stuff, 
I chose to commit mono source changes and discard the IDE scaffolding because 
it was trivial.

In the case of certmgr, was there any complexity in creating the solution in 
MD?  If it's trivial, it might be reasonable for people to just generate them 
when they need them.  If it's non-trivial, it might not be unreasonable to 
include those in the mono sources.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list