Re: [Mono-dev] Bug preserving stack trace
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
[Mono-dev] Bug preserving stack trace
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
> 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
> 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
> 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-dev] Unix Signal in 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-dev] Which mono libraries should be packed along with the mac app ?
> 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
> 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-dev] Data protection failed exception
> 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-dev] Debugging Mono applications under GDB
> 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?
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)
> 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
[Mono-dev] Buggered yum repo
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&search=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-dev] Compiling 64-bit windows mono-2.0 library with Visual Studio
> 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
[Mono-dev] Unexpected binary element
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
> 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
> 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
Re: [Mono-dev] SslStream X509 certificate
> 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
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
[Mono-dev] Class built by mono throws FileNotFoundException when run on windows
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-dev] Mono/Windows Services
> 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-dev] NullReferenceException in Mono.Security.X509.X509Certificate.Hash and IsSelfSigned
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
Re: [Mono-dev] NullReferenceException in Mono.Security.X509.X509Certificate.Hash and IsSelfSigned
The NullReference problem seems to be Xam.Mac specific. The problem doesn't happen in a console application, or even if I create a new Xam.Mac project. But my old Xam.Mac project has the problem - and I can't make any sense of it. I've trimmed down everything I can, to this example project. Simply make sure you have no mozroots rm -rf ~/.config/.mono/certs and launch the application in debug mode. https://github.com/rahvee/monobug_nullreference ___ 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
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-dev] ECDSA support
> 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
> 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-dev] Is mono ready for backend deployment?
> 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?
> 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-dev] System.Net and SynchronizationContext
> 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
> 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.5&profile=4.5&assembly=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-dev] Integration Tests
> 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
[Mono-dev] Integration Tests
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?
> 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
Re: [Mono-dev] What will happen if Dispose() hangs?
> 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
[Mono-dev] What will happen if Dispose() hangs?
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] cert-sync
> 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?
> 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
> 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?
> 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
> From: Sebastien Pouliot [mailto:sebastien.poul...@gmail.com] > > In such case OSX (and iOS and Android) are > delegating the trust decision to the operating system _without_ accessing > any mono stores. IOW you should get the same decision from Mono that > Safari would have. > > If you use the .NET API, like X509Chain, then it will still be using Mono's > managed implementation - which depends on mono's certificate stores (and > tools). 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? ___ 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)
> 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
Re: [Mono-dev] cert-sync
> From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com]
> Sent: Thursday, January 22, 2015 7:16 AM
>
> I just tested as well and was able to run a simple new
> WebClient().DownloadString("https://www.google.com";); without issues
> after a fresh install of the Mono MDK on OSX, so I'm not sure why it only
> works after running mozroots for you?
Interesting. Have a look in these directories:
~/.config/.mono/certs/Trust
/usr/share/.mono/certs/Trust
If you have stuff there, it must have been populated by mozroots, or something.
I understand that the latest packages distributed by mono repositories have
automated cert-sync in linux during package installation, but that's not yet
present on OSX. So on OSX, mozroots or something is necessary to populate the
root Trust.
If you don't have those directories - or if they're empty - it will raise new
questions about differences between WebClient().DownloadString() versus
SslStream.AuthenticateAsClient(). I am using the latter, on mono 3.12 MRE for
OSX.
___
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?
> 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] cert-sync
> From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com] > > I always thought OSX used the system cert store anyway and this was just a > Linux "issue"? Nope. I just tested to make sure, and OSX uses .config/.mono/certs just like linux. (Must run mozroots) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] cert-sync
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Jo Shields > > Mono 3.12 will ship with a new tool, cert-sync, > which populates the root CA store from a static concatenated file. > This will be executed on package install on Linux Thanks Jo, It looks like it does the same job as mozroots, but pulls from the concatenated file instead of downloading from mozilla. That file should be available on most (if not all) linuxes, but ... Any plans to support OSX? And/or mobile devices? If the presence of root certs is not automated on *all* platforms running mono, then the application developer is still required to programatically run mozroots anyway. Automating the process into the installation package is a really nice improvement. Even if cert-sync won't work on OSX due to having no concatenated file available, can mozroots be automated into the OSX mono installer? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] If you accept pull requests on Mono's github
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono) > > Pull Request: > https://github.com/mono/mono/pull/1490 Keepalive... No responses for a week... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Request for comments: mozroots, msroots, X509Chain
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono) > > To validate this concept, I'd like to point out that Microsoft ships Windows > with a list of roots *and* a list of intermediates populated by default. Bah. I made a mistake. The fact of the matter is, MS and Firefox (and probably others) ship with roots only, and no intermediates. They automatically store any intermediates they receive from servers during normal usage, which can cover up problems if later connections fail to provide a valid chain. I was misinformed because I looked at the intermediates list of a system that had been used to browse a lot of internet, but today I looked at a pristine windows installation and confirmed the intermediate list was empty. Also, I found a mozilla support article where they explicitly say "Firefox automatically stores intermediate certificates that servers send in the Certificate Manager for future usage. If a server doesn't send a full certificate chain then you won't get an untrusted error when Firefox has stored missing intermediate certificates from visiting a server in the past that has send it, but you do get an untrusted error if this intermediate certificate isn't stored yet." So my long email is moot except for two points: The root certs need to be automated, and mono SslStream.AuthenticateAsServer() needs to be fixed because it doesn't send the chain. (The problem is underlying; not actually a flaw in SslStream itself.) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Request for comments: mozroots, msroots, X509Chain (Mono-devel-list Digest, Vol 117, Issue 10)
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Jo Shields > > Extremely related: Mono 3.12 will ship with a new tool, cert-sync, > which populates the root CA store from a static concatenated file. > This will be executed on package install on Linux (on our > mono-project.com packages, Debian/Ubuntu derivatives once 3.12 enters > them, and hopefully other community distros), using the distro cert > store as input. That's /etc/ssl/certs/ca-certificates.crt on Debian > derivatives, and /usr/share/pki/ca-trust-source/ca-bundle.trust.crt on > Red Hat derivatives > > tl;dr: Anyone installing or upgrading mono 3.12 from our packages will > get a populated CA cert store by default. No intermediates, since > that's not how these facilities are provided. It looks like it does the same job as mozroots, but pulls from the concatenated file instead of downloading from mozilla. That file should be available on most (if not all) linuxes, but ... Any plans to support OSX? And/or mobile devices? Automating the process into the installation package is a really nice improvement. Even if cert-sync won't work on OSX due to having no concatenated file available, can mozroots be automated into the OSX mono installer? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > > Martin is creating the branch now where we bring the Microsoft SslStream > into Mono as well as his crypto stack. > > For details see: > > https://trello.com/c/PvUaV89u/16-tls-stack Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Request for comments: mozroots, msroots, X509Chain
Is Sebastien on this list? I'm just guessing he'll have an opinion, or at least a passing interest. I guess Miguel, too. When a client application makes a SSL/TLS connection to a server, the application must validate the server cert, validate any chain of intermediate signing certs, and conclude by validating a trusted CA root cert that terminates the chain, or else the connection is considered untrusted/insecure. No matter what, the server cert (leaf cert) is provided by the server. No matter what, the root cert must exist in a predefined list of roots trusted by the client. This leaves a little bit of ambiguity around the process of building the chain of intermediates - The server may send the chain to the client, or the client may construct a chain any way it can, but if it fails to build a valid chain, the connection is considered untrusted/insecure. It is well known that mono ships with no trusted CA roots. If a user wants to use a mono-based application to connect to any type of SSL/TLS server (including https), they are typically required to use the "mozroots" command (part of mono) to populate the root list. There are several things wrong with this - #1, it's not user friendly to require users to manually run a command on the terminal before they can use standard internet resources. #2, application developers are very likely to automate the mozroots process into their applications (I know I do). This is cumbersome to developers, particularly because mozroots is a console application, not a class that can be called programatically. #3, Although people generally know about the empty mono root CA list, most people don't know there is a separate list of intermediates (also empty). Both lists are empty by default, but mozroots populates the root list by downloading from mozilla. The intermediate list remains empty. There is nothing strictly *wrong* with populating the root list and leaving the intermediate list empty, but it means the mono client is fragile. If the SSL server fails to send the chain to the client for any reason, then the client has no other recourse, and will fail to construct a chain. The client could be more robust, if the intermediate list were populated too. Then, the client could usually build a valid chain, even if the server fails to send the chain. To validate this concept, I'd like to point out that Microsoft ships Windows with a list of roots *and* a list of intermediates populated by default. There is a bug in mono that prevents a mono server from sending the chain to the client. This bug is being worked on independently of this email. Since a mono client has no intermediates, it means a mono client is doomed whenever it tries to connect to a mono server signed by an intermediate, which is unfortunately the real world norm. Interestingly, if you run a .Net client and mono server, then the connection succeeds because the client is able to construct the chain from the MS list of intermediates. Also, if you run a .Net server and mono client, the connection succeeds because the .Net server successfully sends the chain to the client. The incompatibility problem occurs strictly when a mono client connects to a mono server signed by intermediate. This lends even more validity to the concept of populating a list of intermediates on the client, to make the client more robust. As a final piece of background information here, I need to point out that mono X509Chain currently does not attempt to use the intermediate store to build a chain. So even if the intermediate list were populated, the mono client would still fail to build the chain. So finally, I get to the meat of this email: 1- I would like to introduce a new way of populating the root list. I would like to create a new MSRoots class, and corresponding "msroots" wrapper console application, that can be used instead of, or in addition to mozroots. Users can run msroots from the terminal, just as they are accustomed to do with mozroots. But application developers can also use the MSRoots class to perform the same job programatically - very easy. MSRoots will follow the Microsoft practice of populating roots and intermediates, instead of following the mozilla practice of populating roots without intermediates. Also, MSRoots will follow the MS selection of roots (currently 43 roots) and will not follow the mozilla list (currently over 140 roots). Copyright and license terms are a sticky subject when distributing CA certs. To avoid any difficulty, I support the current approach of *not* distributing certs, but instead, automating the download. It is absolutely legal (fair use) to distribute URL's that refer to potentially copyrighted material; since the URL is only a reference, the URL is legal to distribute under fair use. I hereby volunteer to maintain a list of references, and to automate the process of updating that list, so any ra
Re: [Mono-dev] X509Chain
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > > I do not believe we have made changes to X509Chain. Ok, thank you. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] X509Chain
Miguel, you said > We have implemented TLS 1.1 and 1.2 on top of the not yet open sourced > networking stack and will be publishing it as soon as Microsoft open sources > the .NET networking stack. Have there been unpublished changes to Mono.Security.X509.X509Chain? Something I think I could reasonably do, if it's not a waste of time, is to improve the Build() method, so it will build a chain using both the roots store, and the intermediates store. And come up with a way of populating the intermediates store. (Such as improvement on mozroots.) I wouldn't want to work on that, if it's obsoleted by code that will hopefully be published soon... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Posix Cross Compiling
> From: Dave Curylo [mailto:dacur...@gmail.com] On Behalf Of David Curylo > > You're right.I didn't realize that was what's going on. It looks like > conditional > references need some hand holding like this: > > > > > > > > Very nice. I'm going to start using that. Previously, you had a value 'Windows_NT' and now you have a value 'Unix' in there. How do you figure out what values are valid? I presume there's no such thing as setting a breakpoint inside the .csproj file to see what the variable is set to... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Posix Cross Compiling
> From: Dave Curylo [mailto:dacur...@gmail.com] On Behalf Of David Curylo > > You have to use conditional compilation for the code that uses the > conditional reference, in this case Mono.Posix. The reference appears with a > warning in Visual Studio and you get a compiler warning, "The referenced > component 'Mono.Posix' could not be found" but this is to be expected on > Windows/.NET. This may be an annoyance, but it allows developers to be > productive developers on either platform, so I consider this to be a > functional > solution. > > I created an example here on github: > https://github.com/ninjarobot/MonoConditionalReference > > This builds fine on Xamarin Studio on OS X and Visual Studio on Windows, > although given the conditional compilation, the resulting assembly is > different. We take this approach in my organization so that some developers > can work on Windows with Visual Studio and other developers work entirely > on mono (our target platform). That's cool, but - You don't need to add the "Conditional" clause to the tag of the csproj. I just checked out your project, and got rid of the conditional clause in the csproj, so the reference to Mono.Posix is unconditional. The behavior is the same. It compiles fine and gives warning about the unused and broken reference. The reason it works is because of the #if __MonoCS__ which eliminates any calls to the missing assembly. As long as you can eliminate any calls to the missing assembly via #if or [Conditional], then you don't actually need the assembly and it's ok to ignore the warning about broken reference, missing assembly. The time when a real problem occurs is when you actually *do* need the assembly. For example, if I copy Mono.Security.dll over to windows, and create a project that uses it in both windows & mono, then I have something like this in the windows csproj: ..\..\libs\mono\Mono.Security.dll Which will not compile on mono. So in mono, I have to modify the csproj to be like this: Which will not compile on Windows. As far as I can tell, any attempt to use Conditional property in the tag is simply ignored. So I settle on using the kludgy hack of using different csproj files on windows & mono. It works so I didn't spend more time on it - but if there's a more elegant solution, I'd like to know. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Posix Cross Compiling
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of David Curylo > > If you edit the .csproj file, you can have a platform-specific reference > Mono.Posix like this: > > I've never gotten this to work before. Moments ago, I pasted the above into a test project, just to see if the above would work - and it didn't. The reference is still present, and still broken, if I open a project with the above line in Visual Studio. Fortunately as long as you don't use anything from the missing assembly, the project still builds, so in some cases you can ignore the broken reference by using [Conditional] and/or #if to wrap around all the things that actually use something from that assembly... The workaround I've always settled on was to make multiple versions of the .sln and .csproj files if I need different assemblies referenced on .Net and mono. (Which is usually the case, because of NUnit and Mono.Security, which I use a lot.) If you find a way to make the conditional reference functional, please post. I'd love to know. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > > We have implemented TLS 1.1 and 1.2 on top of the not yet open sourced > networking stack and will be publishing it as soon as Microsoft open sources > the .NET networking stack. Have there been unpublished changes to Mono.Security.X509.X509Chain? Something I think I could reasonably do, if it's not a waste of time, is to improve the Build() method, so it will build a chain using both the roots store, and the intermediates store. And come up with a way of populating the intermediates store. (Such as improvement on mozroots.) I wouldn't want to work on that, if it's obsoleted by code that will hopefully be published soon... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] If you accept pull requests on Mono's github
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Andres G. Aragoneses
>
> If it fails, you can decorate it with the attribute
> [Category("NotWorking")], but AFAICT contributing a failing test doesn't
> increase the chances of finding a contributor that has the time to fix it.
Got it. Thanks.
Pull Request:
https://github.com/mono/mono/pull/1490
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] If you accept pull requests on Mono's github
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Miguel de Icaza > > If you are accepting pull requests on Mono's github, please request that pull > requests that were iterated multiple-times have their multiple commits > squashed into one. I consolidated a couple of commits into a single commit - Which is here: https://github.com/rahvee/mono/commit/d684a099ba9e3bae1cb941523c0c978b16480ed4 Should I submit a pull request for this? This test is known to succeed on .Net and fail on mono. I don't know if you want tests that are known to fail. The root cause is that the mono SslStream server, upon construction of the X509Certificate, strips the intermediate chain, so of course it cannot send the chain to a client, and the client cannot construct a chain. Additionally, when the client attempts to construct a chain, X509Chain.Build() does not use the Intermediate store (which would be empty by default anyway) so the mono client is unable to compensate for the shortcoming of the server. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
bump > From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono) > > I was able to trim this down to a specific subset and make a unit test out of > it. > Although SslStream has compatibility problems communicating with other > implementations (such as .Net), mono SslStream also has a problem talking > to *itself*. The root causes are the same for both the internal compatibility > problem, and the external problems. So the internal problem is > demonstrated in the SslStreamTest here: > https://github.com/rahvee/mono/commit/b0362fe70fb445f90197eab712b8d > 995f88d78e1 > > Should I submit a pull request? Note: This test currently passes on .Net, > and > fails on mono. I don't know if you guys want me submitting a test that is > known to fail on mono. > > Should I file a bug in bugzilla? (I'm not sure if I have sufficient > permission). > > And as a matter of style, in the above commit I needed to use some classes > that weren't available in the MonoTest namespace, so I used > "global::System." in several places. Is this the correct and/or best way > to > deal with it? Or is there a better way to handle that? > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
I was able to trim this down to a specific subset and make a unit test out of it. Although SslStream has compatibility problems communicating with other implementations (such as .Net), mono SslStream also has a problem talking to *itself*. The root causes are the same for both the internal compatibility problem, and the external problems. So the internal problem is demonstrated in the SslStreamTest here: https://github.com/rahvee/mono/commit/b0362fe70fb445f90197eab712b8d995f88d78e1 Should I submit a pull request? Note: This test currently passes on .Net, and fails on mono. I don't know if you guys want me submitting a test that is known to fail on mono. Should I file a bug in bugzilla? (I'm not sure if I have sufficient permission). And as a matter of style, in the above commit I needed to use some classes that weren't available in the MonoTest namespace, so I used "global::System." in several places. Is this the correct and/or best way to deal with it? Or is there a better way to handle that? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono) > > > From: Miguel de Icaza [mailto:mig...@xamarin.com] > > > > We would love a test case to add to the test suite. > > > > We are building a new test suite as part of this work anyways. > > This is almost done. Granted it is microscopic in scope - the test I've > written > tests only for the case that I know fails; it's far from being a generalized > test > for the SslStream class as a whole. Well, this grew up more than expected. I started writing a unit test, and discovered the behavior is variable based on the existence or non-existence of intermediates and roots on *both* the client and server... Which means in order to test it thoroughly, the client & server cannot be on the same machine... So it's really not a unit test. Even more dramatically, the behavior depends on whether the server & client are windows or mono. So ultimately this test requires 4 machines (2 windows and 2 mono) with 16 tests run on each combination. I wrote a compatibility testing project. https://github.com/rahvee/MonoSslStreamServerBug In this project, I created a junk root CA, an junk intermediate CA, and a junk server cert, suitable for publishing and testing. I also tested, offline, pasting some real root CA, intermediate, and real commercially signed certs, and found the behavior of real certs from real CA's to be consistent with the results of these generated junk certs. There are ultimately 2 bugs causing mono to fail - (1) The server doesn't send the chain to the client. And (2) the client fails to build a chain from available certs, even if all the necessary certs are available to the client. I noticed "mcs/class/Mono.Security/Mono.Security.X509/X509Chain.cs" doesn't use the intermediate store at all, when using the "Build()" method to build a chain. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com] > > We can add it to the website, do you have a suggestion on which page it > makes the most sense? On the FAQ pages perhaps? I don't have any suggestion better than FAQ. It's unlikely that a person like me will find it all by themselves - but if it appears in a google search, that would be an improvement. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Eberhard Beilharz > > Wouldn't > #if __MonoCS__ > do what you want? Yeah, that works. Thanks! It's funny though, as I search around for __MonoCS__, there's little if any mention of it on any official documentation - it seems to be all institutional knowledge passed down on StackOverflow. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com] > > I'm curious: why do you need it to compile with MS.NET if you're testing > Mono stuff? This particular test fails on current mono. So it's not sufficient to just see it fail on mono - to have any value it has to demonstrate failure on mono and success on .Net. I'll look into __MonoCS__ to see if it does what I'm looking for. And if not, I'll just comment out mono stuff to test on .Net. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com]
>
> You can find out if you run on Mono by checking if Type.GetType
> ("Mono.Runtime") != null.
That's helpful, but doesn't quite solve it, because compilation will fail on
windows ...
I'm looking for something like this...
#ifdef MONO
Mono.Security.X509.X509StoreManager.CurrentUser.TrustedRoot.Import(junkRootCert);
try
{
#endif
DoStuff();
#ifdef MONO
}
finally
{
Mono.Security.X509.X509StoreManager.CurrentUser.TrustedRoot.Remove(junkRootCert);
}
#endif
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: mar...@my2cents.co.uk [mailto:mar...@my2cents.co.uk] On Behalf > Of Martin Thwaites > > Do we not have a flag for if it's compiled for tests, rather than release? I don't need a flag to distinguish between tests & release - I need one to determine if the test is being run on mono or windows. For now, I'm just commenting out mono-only sections when I run the test on windows. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > > We would love a test case to add to the test suite. > > We are building a new test suite as part of this work anyways. This is almost done. Granted it is microscopic in scope - the test I've written tests only for the case that I know fails; it's far from being a generalized test for the SslStream class as a whole. Quick question: I'd like to make the behavior different on mono and .Net. Particularly, I've generated a junk root CA, and on mono I'd like to use Mono.Security.X509.X509StoreManager.CurrentUser.TrustedRoot.Import(junkRootCert); To programatically import that cert momentarily for the scope of the test (and subsequently remove it). Obviously, this doesn't exist in .Net. And as far as I know there is no way to programatically import a root CA in .Net. So is there some #ifdef clause I can use to detect if this is mono or .Net? I searched the other test classes, and there's RUN_ONDOTNET, but I'm not certain it's the right thing for the job. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] I would like to contribute to mono however it seems things are in flux due to the integration of .NET Core and .NET Framework; where to start?
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Bernie Schoch > > I guess I'm saying, where would I be most useful say with contributing 20+ > hours a week in the near term (I'm between contract/jobs right now) Huh. I'm surprised nobody answered - If you haven't already, please be sure to see http://www.mono-project.com/community And in particular http://www.mono-project.com/community/contributing Amongst other things, the above tells you where the unit tests are, and bugzilla. It's probably best to develop on mac or linux. Personally I think, that since the latest ubuntu includes a recent-ish version of mono and monodevelop, that's the easiest way to get setup. (But I loves me some sourcetree, so I prefer to work on the mac instead, despite a little more effort required to build.) The source is on github. Fork & pull request. Discuss stuff on this mailing list first, so as to avoid wasted effort. Thanks for offering to help. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > > .NET's implementation of the TLS stack is built on top of native code, so it > wont work on Mono. > > We have implemented TLS 1.1 and 1.2 on top of the not yet open sourced > networking stack and will be publishing it as soon as Microsoft open sources > the .NET networking stack. Great news, thank you! A follow-up question: In the current released version of mono SslStream, if the server uses a cert that is signed by an intermediate chain, *and* a mono SslStream client connects, then the client rejects the cert. The root cause is because the server does not send the intermediate chain to the client, and the client fails to construct the chain. The behavior is specifically a mono-mono incompatibility - If either the server or the client is .Net, then the problem does not occur, because a windows server sends the chain to the client, and a windows client performs guerilla tactics to construct an incomplete chain. So the question is, how could it be possible to add a test for this behavior, presuming it will some day get fixed and then we don't want it to happen again? I can easily enough write example code to demonstrate the problem. But then there's a question about what cert to use for demonstration purposes - it's probably best to create a junk CA with intermediate cert, and some junk server cert. I could easily enough publish those certs somewhere and/or hard-code them into the demonstration code, with something like 30 year validity. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Open source .Net, and TLS 1.1 & 1.2
Does anybody know if support for TLS 1.1 & 1.2 will be released, and if so, going to be integrated into mono? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Daniel Morgan > > We could also save space in the installer if we only include the latest 4.5 > profile. Another words, remove 2.0, 3.5, and 4.0.. Wed Oct 22, 2014: "Heads up: Elimination of the 2.0 and 4.0 profiles" http://lists.ximian.com/pipermail/mono-devel-list/2014-October/042145.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Daniel Morgan
>
> I see the latest version of Mono's Windows installer is 3.2.3. Can this be
> used
> to build the latest from git?
>
> I see a link for binaries for 3.4.0, but they are not official binaries.
>
> I am going to try build Mono on Windows using Cygwin. Not sure how web
> the visual studio stuff works.
Search this list for Appveyor. I know Alex Lennon was putting some effort in,
and I think got to the point of having a reliable automated build process - but
check with folks to be sure (I haven't followed very closely and I could be
wrong). At some point, Miguel pulled Duncan Mak into the conversation, so I
would guess maybe Duncan is involved with distributing windows builds... All
of this occurred within the last ~ 1 month or so.
> Also, what is the best Linux distro to build mono? OpenSUSE? Debian,
> Ubuntu? It has been awhile for me. Not starting a flame war here - just
> wanting the easiest route to get the dependencies on linux in order to build
> the latest mono from git.
On basically any system I've seen so far, building is easy. The basic process
of "./configure && make && make install" usually works. If it doesn't, then
add "make get-monolite-latest" before "make EXTERNAL_MCS=..." as below...
On every redhat-based or debian-based (or even mac) system I've ever used, one
of these two variants has always worked.
OSX
export BUILDDIR=/Users/whatever/Projects/mono-build
export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p
$BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no
&& make -j $NUMPROC && make install && echo "" && echo "Done" && echo "")
Ubuntu 14.04
export BUILDDIR=/home/whatever/Projects/mono-build
export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p
$BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no
&& make get-monolite-latest && make -j $NUMPROC
EXTERNAL_MCS="${PWD}/mcs/class/lib/monolite/gmcs.exe" && make install && echo
"" && echo "Done" && echo "")
> And I want to play with MonoDevelop too, but Mono comes first.
Building monodevelop is more difficult. I've never succeeded - but I never
spent a boat load of time on it either. You can install MonoDevelop on the
mac, no problem (they distribute a pre-built binary). Also, the latest ubuntu
includes a recent build of monodevelop. I personally use VS on windows, XS on
mac, and MD on ubuntu 14.04 desktop x86_64.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] What's the most efficient way to do XOR two byte arrays?
Obviously, I could just use a for-loop. But then my code is theoretically telling the system to XOR each byte individually, wasting most of the CPU on each instruction. I wrote unsafe code to do this with 32-bit and 64-bit int pointers. Surprisingly they both performed about the same (I guess, at least on my system, 64bit instructions take longer to execute, effectively eliminating most of the gains of the wider bus). Unsurprisingly, they greatly outperformed the unoptimized for-loop. Surprisingly, the difference between the optimized unsafe code and the optimized for-loop suggested it was a waste of effort. (Only marginally faster.) I don't know what kind of optimizations the compilers are able to perform on this code: for (int i=0; i___ 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 GUI Tookit
> From: Brandon Perry [mailto:bperry.volat...@gmail.com] > > Xwt aims to be a solution to this. > https://github.com/mono/xwt Thanks for the suggestion. > Sent from a computer No way...;-) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Cross-Platform GUI Tookit
I'm aware of Xamarin.Forms, but apparently only for iOS, Android, Windows Mobile. Does something similar exist for Mac OSX, Windows Desktop, Linux? I stumbled upon this: https://github.com/picoe/Eto Haven't tried it yet. Maybe it's great, maybe not. Are there some additional competing alternatives out there? Thanks... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] Open source .NET and Mono.
> From: mono-list-boun...@lists.ximian.com [mailto:mono-list- > boun...@lists.ximian.com] On Behalf Of Miguel de Icaza > > Hey guys, > > I posted details about the open sourcing of .NET and Mono on my blog. > > We have already started the work to integrate the .NET Framework code, > and once I get back to Boston after the event we will check in the > results. That is the reason we did not want to take the large #ifdef patch > removal a couple of weeks ago. > > http://tirania.org/blog/archive/2014/Nov-12.html WAA - HOO!!! :-D Awesome, awesome. Thank you. :-D ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] InvalidCastException - which makes no sense
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > > What happens is this. The value returned from ExecuteScalar is boxed. This Got it, thanks. In fact, I simplified to this: Object foo = (Int64)0; Int64 foo64 = (Int64)foo; Int32 foo6432 = (Int32)(Int64)foo; Int32 foo32 = (Int32)foo; // Throws InvalidCastException And I confirmed the behavior is the same in .Net and Mono. So everything makes sense; it's just something I didn't know before. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] InvalidCastException - which makes no sense
This is a fun one. I'd love it if anyone could explain this to me.
using (var command = new SqliteCommand(@"SELECT COUNT(*) FROM someTable WHERE
someColumn = @someValue ", dbConn))
{
command.Parameters.Add(new SqliteParameter("someValue", "foobar"));
object scalar = command.ExecuteScalar();// object returned has type
Int64
Int64 count64 = (Int64)(scalar); // works
fine. Value is 0
Int32 count32 = (Int32)(Int64)(scalar);// works fine.
Value is 0
Int32 count = (Int32)(scalar); // throws
InvalidCastException
...
}
In the above, scalar is obviously an object, but the object returned by
ExecuteScalar() is of type Int64. The value is 0.
This works fine:
Int64 count64 = (Int64)(scalar);
This works fine:
Int32 count32 = (Int32)(Int64)(scalar);
This throws InvalidCastException:
Int32 count = (Int32)(scalar);
The best I can gather, the object needs to be cast to Int64 before it can be
cast to Int32. Which makes no sense to me, but that's the way it is.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unit Testing process: Community Contributions
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > > I have not seen you discuss any pull requests on the mailing list. Did I miss > something? In order to respond to this question, I just reviewed all the history of my pull request, but there was a lot of volume in disjoint places (github, bugzilla, this mailing list, xamarin support, xamarin forums, stackoverflow, etc). By going through all that review myself, I concluded that there's no need to rehash it in detail. This is the conclusion: Back in April, I discussed the details of the bug on this list, with Sebastien (Xamarin employee and mono contributor). Amidst my discussions with Sebastien, I asked what process to follow. Rolf (Xamarin employee, mono contributor) said "The standard way is to fork on github, then send a pull request." So that's what I did. A week or two later, having received no reply, I emailed the list asking about status and referencing the pull request. A week or two later, Miguel you assigned to @spoulliot, but you did not reply back to the list. A month later, jstedfast (Xamarin employee, mono contributor) poked @spoulliot on github, but not on the mailing list. At least one other user watching the pull request poked it trying to get attention to no avail. Eventually, in September, I just kept whining on the list and the pull request was finally reviewed. (Unfortunately, it was reviewed and rejected by Sebastien, without discussing on the list what's wrong, or how we could make progress and move it forward from this point - but that's a separate issue, that I can work through if I want to.) So the conclusion is this: In the past, as recently as September, it has not been clear what path to follow. Even Xamarin employees and mono contributors (and even Miguel) didn't have any organized approach or good understanding of what path to follow. So moving forward, what we all need to do is as Miguel says now: Keep the discussion alive on the list, before, during, and after the pull request. This is a clear direction, applying now and to the future, not in the past. Xamarin employees who are mono contributors - Please spread this knowledge to other Xamarin employees & mono contributors. If you guys don't spread it amongst yourselves, we'll have more problems like the one described above. As to the non-connection between Xamarin and Mono support: Got it. Point taken. In the past, there was something somewhere on mono-project.com suggesting that mono support could be obtained via Xamarin, but nothing of the sort seems to exist now. Ok, no problem. Can deal. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unit Testing process: Community Contributions
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > > There is no need to presume, the actual issue was just articulated on a > thread, please read it. > > Pull requests do not work well with Mono. They need to be discussed in the > mailing list Did I miss something? Do you not recognize that there's a problem here? What are we supposed to do when we do all that stuff - discuss in mailing list, pay for Xamarin, contact Xamarin support, file or find bug in bugzilla, and even write our own patches and submit pull request to solve our own problems, and then *still* nothing happens? Surely you are aware that the community in general is feeling discouraged about the state of contributions to mono, and the ability to get support for mono? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unit Testing process: Community Contributions
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > > The build bot does some of this work when you submit a pull request. It > does not cover all platforms, nor all configurations, but it is a good first > step. > > But this is not a problem. Not every patch affects all systems, and most of > the code is cross platform, so testing on one is enough. Can you please provide a better response? The underlying question is, "How can we improve the state of affairs and allow a better sense of open source community involvement and contribution?" The presumption so far has been, the enormous backlog of pull requests and ignored bugfixes is caused by the necessity to test and review them, for fear that the community contributions will break stuff. But if the test process is fully automated, I guess that's not really the issue. As a business owner who has staked the success of his entire company on the use and adoption of mono and Xamarin, and as a software developer, I am constantly asked by others to review my experience, and assess whether or not I would advocate those decisions to others, or regret my decisions. It is extremely difficult to justify these decisions if it is impossible to get either free or commercial support for a core technology, *and* even if you fix some bug yourself you still can't submit or get any review or any type of resolution to the problem. The sense of community contributions and bugfixes going unresolved hurts the community and hurts adoption / advocacy for mono. Here's hoping we can overcome that problem. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Unit Testing process: Community Contributions
This might have gotten buried in the other thread. So here's a new thread to bring it up to attention. Miguel, this question is probably for you. (And by the way, thank you for everything, and especially thank you for participating here.) The bottleneck that's preventing much community contribution is *primarily* the fear of community contributions breaking other things. So this sounds like an area that is actually *feasible* to really make a huge improvement on: Can we please, formally adopt a process that community contributors can follow, and reasonably expect (a) that their contributions won't break anything, and (b) that their contributions will consequently be reviewed in a reasonable timeframe? One thing in particular that's missing is a formal definition of how the community contributors should run unit tests. It doesn't necessarily need to be easy - As we all know, mono is a huge complex and awesome project. If it's absolutely necessary to run unit tests on 7 versions of linux, OSX, android and iOS, then so be it. While none of us are prepared to run those kinds of tests right now, you put the target up in the air and tell the community "Figure out some way community contributors can regularly and habitually run these tests before submitting code" and we'll be energized as a result of having a clear *direction* and I'm certain we'll find a way to hit that target. I know there's lots of work on the platter, but this in particular is something I think you can afford to do, with huge implications of community good will, and long-term growth and adoption. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono) > > Getting reviewed is one thing. (Difficult enough.) Getting approved is a > completely different thing - even more perilous. > > ... etc etc yadda yadda ... Actually, I'm frustrated with MYSELF over this message, and thinking some more about what message the message sends. As I said, I try to restrain myself and letting my jadedness come through. But I obviously failed and let it through in that message. (I'm choking and swallowing my pride and apologizing for not being more productive.) As David said, I love .Net and C# and I invest time (me too) advocating it to colleagues and peers, but some parts (like my own email a moment ago) give me pause and make me hesitate and reflect. So here's the deal. Mono is huge and complex, and awesome too. We don't have somebody the size of Microsoft supporting it. If you go to mono-project.com and try to figure out, "How can I get support for mono" I forget exactly what you see, but it effectively says try the community, and consider paying Xamarin. So we work with the community to encounter roadblocks and we pay Xamarin and still get no support for mono. This is both a barrier to advocacy, and also a barrier to businesses who want to stake their business core on mono. As a consistent advocate for mono and Xamarin over the last 2-3 years, I am constantly questioned by peers and constantly question myself, whether or not I regret my decisions to base my company on mono and Xamarin. The question is still up in the air, but I weakly think I still agree with myself. I know it costs money to support & develop mono. I know none of the answers are easy. Miguel, this is probably a question for you. (And by the way, thank you for everything, and especially thank you for participating here.) I don't want to use the linux kernel development cycle as the model we should be following, but I do want to point out one thing: They do indeed take lots and lots of contributions from hugely varied groups of diverse and disperse individuals. Here, my patch that got rejected, said it would break some other class or something that I never heard of before. If that's true, it would only seem natural, that if I had run unit tests after making my patch, I would have discovered that before submitting the pull request. Likewise, the bottleneck that's preventing much community contribution is *primarily* the fear of community contributions breaking other things. My case is the poster child. So this sounds like an area that is actually *feasible* to really make a huge improvement on: Can we please, formally adopt a process that community contributors can follow, and reasonably expect (a) that their contributions won't break anything, and (b) that their contributions will consequently be reviewed in a reasonable timeframe? One thing in particular that's missing is a formal definition of how the community contributors should run unit tests. It doesn't necessarily need to be easy - As we all know, mono is a huge complex and awesome project. If it's absolutely necessary to run unit tests on 7 versions of linux, OSX, android and iOS, then so be it. While none of us are prepared to run those kinds of tests right now, you put the target up in the air and tell the community "Figure out some way community contributors can regularly and habitually run these tests before submitting code" and we'll be energized as a result of having a clear *direction* and I'm certain we'll find a way to hit that target. I know there's lots of work on the platter, but this in particular is something I think you can afford to do, with huge implications of community good will, and long-term growth and adoption. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Pull Requests
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Martin Thwaites > > Just to give my2cents on this. > I would just like to know that things will get looked at approved at some > point. Getting reviewed is one thing. (Difficult enough.) Getting approved is a completely different thing - even more perilous. Here's my example: Mono SslStream, when used as a server, is simply incompatible with mono SslStream when used as a client. Mono clients can talk to windows servers, and windows servers can talk to mono clients, and windows clients can talk to windows servers. The only incompatibility is Mono server & Mono client. There was a bug report. It was marked as fixed, and closed, even though it wasn't fixed (obviously nobody tested, or didn't care that the test failed or something). I dug into it, patched it, submitted pull request, and we are now shipping product that requires customers to install our customized version of mono. We are paying Xamarin customers. For months, I tried to get attention amongst mono developers to review the pull request, and then - After I finally made enough noise, what happened was this: Patch was reviewed and rejected. Period. No discussion, no attempt to create a new fix, no nothing. It was the effective equivalent of telling me to shut up and go away. (That happened like 3 weeks ago or so). I am obviously left feeling extremely jaded. I know for damn sure I'm not going to bother submitting any patches any time soon, and I have to restrain myself every time I hear other people on this list thinking they're going to submit patches or help improve mono. Cuz I don't want to be the guy who just bitches and complains all the time. I remain hopeful this can change someday, but I'm pretty badly burned at the moment. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Windows builds
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Bryan Crotaz > > Who's with me? FWIW, the state of mono for windows is really really bad, but it's not great for rhel or ubuntu either. I agree *enormously* that there's a big benefit to improving the state of all these. So FWIW I agree with you. But I don't have time to contribute. (tangent) The issue with the rhel/ubuntu setup is this: As long as you build from source, it's pretty straightforward and reliable. But as bugfixes and security patches get released, nobody will make a habit of literally building every time there's an update, in order to keep their systems up to date. There needs to be officially maintained yum & apt repos - which there are - but that's the problem. The yum & apt repos seem to be in a perpetual state of brokenness. When we ask about it here, the answer is always "just wait a few hours or a day and try again," which doesn't seem to work, and doesn't really help IT people out there maintain their systems anyway. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building mono on Windows issues.
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Bryan Crotaz > > Basically if we could persuade Xamarin to get mono building on Windows and > VS users able to debug Mono, suddenly there would be a lot more > developers able to contribute without having to learn a whole new stack > first. As discussed previously on this list in other threads, the barrier to contribution to the mono code base is not a lack of developers - there are plenty of people willing and able to work with XS or MD on mac and linux. The problem is bottleneck of Xam employees to review and test code submissions. There is already a huge backlog of pull requests; they just don't have enough human resource to handle it. The community isn't pouring forth with experienced volunteer maintainers to step into that role either. And it takes quite an investment to get all the build & test VM's up to run a full fledged test environment anyway, which is necessary to pass before pull requests can be accepted. Hopefully this can improve someday. For now, community contribution is sparse. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building mono on Windows issues.
> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk] > > We use Visual Studio (plus Resharper as Bryan so rightly says - couldn't > get along without it) as we find this to be a productive development > environment. +1 > In addition there is a lot of development resource out there with people > who know and are qualified on the VS toolchain. +1 again > From a productivity perspective and for risk management for testing and > deployment I wish to be able to develop and debug under Visual Studio > with Mono as a framework option. > > I'd like to be able to do that with Mono on Windows as a check that no > issues come up between running on the .NET framework and running on > Mono. You can do that. Don't need to build mono on windows - just do a normal mono-for-windows install - I haven't done it in a while, but there's a plugin to run your code against the mono runtime instead of .Net. I'm pretty sure it's free - might even be a standard extension you can find with the Extension manager. > In addition I'd like to be able to remote debug to Embedded Linux with > Visual Studio - which I used to be able to do with Xamarin's Monotools > Server before it disappeared. Again, you don't need to build mono to do this. But this feature I'm sure, is not free. It's included in Xamarin Business. They offer Visual Studio support as one of the features of Xam Bus. It allows you to do remote debugging with VS running a mono app on some remote mac or linux mono machine. > I'm currently investigating a VS plugin to replace Monotools Server > which I've not had much luck with yet, but I'm optimistic: > https://github.com/DynamicDevices/monodebugvs Interesting. I guess I have to take back what I just said about "I'm sure it's not free." ;-) Should revise: I'm sure Xam offers a commercial solution, and apparently there is also some hope for a free alternative. So all the above boils down to ... As I said, the only reason I know you need to build mono on windows is if you want to step through the *mono* code, not just your own code. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building mono on Windows issues.
> From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk] > >> Generally >> speaking, the only reasons to build on windows are because you want to >> debug the code, which is generally better done on mac/linux. Or you're >> trying to accomplish something else, like obtain a specific DLL (such as >> Mono.Data.Sqlite)... Which usually you can obtain some other way such as >> building on linux and then copying the DLL over to windows. > > Agreed, but the the other reason is that you want to use a current Mono > yet nobody has gotten around to an official release of Mono for WIndows > since 3.2.3. Agreed, but that's the point - Why would you want to use Mono on windows? The only reasons I know of are (a) you wish to debug the mono sources using Visual Studio, or (b) you wish to use one of Mono's assemblies in windows, such as Mono.Security, Mono.Data.Sqlite, etc. For case (a), at least for me, it's been easier to transition to Xamarin Studio or Monodevelop on mac/linux. For case (b) I was able to brainlessly copy Mono.Security.dll, and I struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few tries, managed to get it right more easily than getting it to build natively on windows. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building mono on Windows issues.
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Chris Eelmaa > > I have question regarding building mono on windows, > namely I've tried a lot of times, and had a lot of different Many venture into the waters of mono build on windows. Few live to tell the tale;-) The honest truth is, many of us have sunk hours or days into trying to get it to work. Many of us (including me) strike out and eventually give up. Occasionally, people come to this mailing list and post a procedure that worked for them. I've never seen the same procedure twice, I always try, and it's never worked for me. Your best bet is to search this mailing list archive for the most recent posts of people succeeding, and see if that's able to help you along. Your *other* best bet, is to ask yourself "Why, God, Why?" As I have done, and others like me who were also lost in the battle. Generally speaking, the only reasons to build on windows are because you want to debug the code, which is generally better done on mac/linux. Or you're trying to accomplish something else, like obtain a specific DLL (such as Mono.Data.Sqlite)... Which usually you can obtain some other way such as building on linux and then copying the DLL over to windows. So if you don't succeed at building on windows, then ask yourself (and this list) if there's another way to accomplish whatever you're actually trying to accomplish. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] apt-get update checksum error
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of spiko > > This problem has been resolved for me. Running apt-get update today > successfully got the repository details and I was able to install > mono-complete v3.10.0 Nope, I'm stilling seeing same error: sudo rm -rf /var/lib/apt/lists/* sudo apt-get update W: Failed to fetch http://download.mono-project.com/repo/debian/dists/wheezy/main/binary-amd64/Packages Hash Sum mismatch W: Failed to fetch http://download.mono-project.com/repo/debian/dists/wheezy/main/binary-i386/Packages Hash Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] apt-get update checksum error
Trying to run on ubuntu: apt-get update Gives me this error: W: Failed to fetch http://download.mono-project.com/repo/debian/dists/wheezy/main/binary-amd64/Packages Hash Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. Does this mean somebody just neglected to update a checksum file? I have already rm -rf /var/lib/apt/lists/* And then repeated "apt-get update" but still got the same error. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Json string handling
> From: Miguel de Icaza [mailto:mig...@xamarin.com] > Sent: Monday, September 22, 2014 9:50 AM > >> We've had a pull request outstanding >> since April https://github.com/mono/mono/pull/1004 > > Perhaps the best thing to do is to file a companion bug, and raise the > priority > of that bug to "major" whenever a patch is available, to trigger a review. This one has been sitting around since April. I don't have access to raise the priority. https://bugzilla.xamarin.com/show_bug.cgi?id=19274 We had to implement a workaround into our product for customer release, to workaround this issue. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Json string handling
> From: mar...@my2cents.co.uk [mailto:mar...@my2cents.co.uk] On Behalf > Of Martin Thwaites > Agreed on all counts. I agree, as Miguel mentioned, that it's necessary to have quality control in place before accepting commits. As Martin says, don't let something get worse as a result of supposed improvements being committed. Well understood that the constraints we live in are: Xamarin is a commercial entity supporting an open source product that extends far beyond the scope of what's useful to Xamarin. Xamarin's resources are not infinite. The mono community will grow more healthfully, and more rapidly, if Xamarin can nourish community contributions more. Some efforts are already under weigh (or already completed?) to improve the mono source build process. Making it easier to build and/or debug the source. The source is easily accessible and easily forkable on github. Build documentation has been greatly improved within the last year. Binary distributables greatly improved. Even the redhat roadblock has effectively been handled - circumventing the archaic crap in epel by adding a new yum repo. Really the one part that's still a huge inhibitor to community involvement is just this one thing - even as paying Xamarin customers, you can't get support for mono bugs - even if you write patches yourself and try to contribute them, even as Xamarin customers you can't get anyone to review your patches. For the time being, any bug or deficiency in mono is "take it or leave." And hopefully this cycle can be broken. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Json string handling
> From: Edward Ned Harvey (mono) > > even as Xamarin customers you can't get anyone to review your > patches. As a tiny little baby step in the right direction, I think Xamarin could at least promise to review pull requests submitted by customers paying for support. (This is a little bit shy of fully supporting mono, which would be even better.) Right now, even if you're willing to pay for it, there is no such thing as mono support. It's tough to get businesses developing applications on mono, staking the core of their business on mono development, with this kind of limitation. I know I made this commitment, starting my business, before I knew any better, and now that we're fully entrenched, people ask me in retrospect, did I make the right decision? And the answers I provide are a big resounding "Maybe?" ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Json string handling
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono) > > Tru dat. However, I guess I'm actually trying to say two separate things: * When broken stuff doesn't get fixed, it's a disincentive for usage adoption. and * When pull requests get ignored, it is a disincentive to contributors trying to contribute anymore (fixing things). This is an unfortunate positive feedback loop, which can hopefully be broken some day. I know based on my experience here so far, I'm not going to bother trying to fix anything anymore. My time would have been better spent, finding an alternative to mono SslStream instead of trying to contribute the fix to make mono SslStream operational. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Json string handling
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Miguel de Icaza > > It is not easy to add people. We can only add people that have shown the > practices and skills that come with reviewing patches and working through > the system. > > If we had more of those, we would add them. Tru dat. However, when broken stuff doesn't get fixed, it drives users away. I'll cite myself as an example: We've had a pull request outstanding since April https://github.com/mono/mono/pull/1004, prior to which, SslStream is simply unusable (mono SslStream server is incompatible with mono SslStream client). So we have to distribute our product using *only* our custom patched version of mono, cannot tell our customers to use any standard mono version, and since it's been ignored so long, the decision is long since concluded that we must bite the bullet and find some other SSL package. It's too late for us - even if that pull request were to be merged today, the lack of attention demonstrates that those classes are poorly maintained, and we have to assume, possibly unstable or insecure in ways that we haven't yet discovered. So for us the decision to get off is already done. Hopefully the train won't keep its momentum in this direction. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to find extern definition for MonoIO void Lock(
> From: Rodrigo Kumpera [mailto:kump...@gmail.com] > > See icall-def.h Thanks. How did you know that? Since I look in there, I can very clearly see a matching method definition, and what it's connected to, and I was then able to find the implementation in source and get all the answers I was looking for - But the method definition I was looking for was "Lock" which is quite a generic search term in hundreds of locations. I'd like to know how I can find that again next time I need it. Especially if it's some completely unrelated application (not mono source) where memorization isn't going to help me. When an "extern" specifies the dll it comes from, that makes it completely obvious where to look. But lots of times "extern"s don't specify a dll, and my best guess after that, is that the compiler / linker / something in Makefile or the csproj must be including it, which could be a horrible pain to track down. I'm hoping there's an easier or better way... Thanks again. Helped a bunch this time. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] How to find extern definition for MonoIO void Lock(
I am trying to find the definition for this: mcs/class/corlib/System.IO/MonoIO.cs: public extern static void Lock (...) I'd like to know how the Lock() method is implemented, so I can understand the valid parameters. (I know the two ints must be >= 0, but I'd like to know what else. And generally speaking, know how it's implemented so I can know its limitations). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Version metadata - reflection?
In Visual Studio, you right-click a project, properties, application, assembly information, and set the version, which corresponds to AssemblyVersion and AssemblyFileVersion in AssemblyInfo.cs, and it can be detected at runtime via System.Reflection.Assembly.GetEntryAssembly().GetName().Version. However, in Xamarin Studio or MonoDevelop, you right-click a project, options, main settings, and set version... It doesn't change AssemblyInfo.cs. Instead, it modifies the csproj. I'm not sure how/if this metadata can be accessed at runtime. Can it? Or better yet, does Xam Studio and/or Monodevelop have some interface that allows easy editing of AssemblyInfo.cs as VS does? I can edit the file by double clicking it and editing text manually, I just wonder if that's what people are intended to do. (I am surprised to see a completely separate and completely analogous and confusing redundant project "Version" metadata setting which is unrelated to the version inside AssemblyInfo.cs). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Performance tests/benchmarks for mono
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Liwei Peng > > I am evaluating mono for Linux (Ubuntu). One of my plans is to evaluate > mono CLR perf compared with Windows .NET CLR perf. Before you get into it, you should know a few things - Everything, literally everything, is variable. Meaning, you'll write some code that uses some class method, and you run it on Windows, with optimizations, and then run again without optimizations, and then run on some version of mono with and without optimizations, and then run on a different version of mono with and without optimizations, and then run on a different platform (windows vs mac vs linux vs etc) with and without optimizations, and then run on a different class of hardware including or not including some hardware optimizations, and in every one of those situations, the performance varies. Sometimes windows is faster for some things. Sometimes mono is faster for other things. Sometimes the .NET api provides different implementations to the same interface or abstract class - and sometimes mono ignores that and implements them the same behind the scenes just because that's what's available. For example, some RSACryptoServiceProvider, and RSAManaged, and RSAWhatever ... All functionally equivalent with different performance characteristics on windows relative to each other, but then in mono, they all map to the same RSAManaged. (I'm speaking vaguely for example, maybe it's RSA or AES or other classes, I forget, I assume there are a bunch of things like this.) The behavior is not always exactly the same - for example, in .NET you create an instance of RSA with RSA.Create(), and it not only gives you an object, it actually generates keys for you. But in mono, they don't bother creating keys for you until you do some operation that requires the existence of keys within the RSA object. So if you just measured the time to create an instance of RSA, you would be inaccurate in measuring the actual work time. And guess what, .NET recently changed its behavior to be like mono. Lazy RSA key generation. So those performance measurements, once again, have changed. Moving target. And I have reason to believe that windows pre-generates a cache of keys to be available upon user request, so it might perform really well for a number of keys and then suddenly drop to normal mono-like performance for sustained repeated key generation. And the windows keys apparently aren't made to the same quality specification. Etc etc etc etc. You write some really simple code just to test the performance of calling methods recursively or something like that. Compile it on windows, whose compiler will have some set of compiler optimizations, then run it on windows and on mono, where the JIT compiler will apply a second set of optimizations. Now compile it on mono, whose compiler will have a different set of compiler optimizations. Again, run it on mono and windows for another set of JIT optimizations. Yet another variable in the performance characteristics. Perform an AOT compilation. Yet another variable. There is only one possible conclusion you can reach (I've done a lot of this myself): Some things are faster in windows, others are faster in mono. If you pick one specific thing and dig into it you can then explain the difference for that specific thing. But you cannot draw any generalization. You can only create a meaningful summary of performance comparison for a specific application. And it will change over time, because of changes in both Windows and in Mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
