Re: [Mono-dev] XmlException : DocumentType cannot be imported.
Hi Not even time to create the bug report ! Thanks a lot Vincent Le 19/05/11 06:18, Atsushi Eno a écrit : Hello, importNode() on DocumentType is invalid in DOM Level 2 Core specification[*1], that's why it had been rejected. It can be now imported in git (master and mono-2-10). [*1] http://www.w3.org/TR/DOM-Level-2-Core/core.html#i-Document Atsushi Eno (2011/05/18 21:05), Vincent DARON wrote: HI all, I've problem while cloning XmlDocument containing a DocumentType. Code to reproduce the error : //Sample file can be found at : http://www.recordare.com/sites/default/files/MozaVeilSample.xml XmlDocument doc = new XmlDocument(); doc.Load(MozaVeilSample.xml); XmlNode d2 = doc.CloneNode(true); It works under MS Framework.NET 4. My mono setup: Mono JIT compiler version 2.10.2 (tarball Wed Apr 27 09:16:42 UTC 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC:Included Boehm (with typed GC and Parallel Mark) Any help welcome ! Regards, Vincent ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] compiling (2.10.2) on a beagleboard-xm running Ubuntu
Hello Dennis, this week, I tried to compile the mono runtime 2.10.2 for a proprietary linux platform. The runtime itself was running (at least I could run mono --help), but, I have not been able to run .NET programs. The program crashed before reaching the actual .NET code. I also tried mono 2.10.1, no success. Finally, I used 2.8.2 and everything was fine. I couldn't figure out why 2.8.2 is running and 2.10.1 and 2.10.2 are failing. Regards, Florian -- View this message in context: http://mono.1490590.n4.nabble.com/compiling-2-10-2-on-a-beagleboard-xm-running-Ubuntu-tp3527139p3535230.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Platform independence of mono assemblies
The perfect is the enemy of the good
- Voltaire
On May 18, 2011, at 5:53 PM, Christian Krause wrote:
In Fedora, the assemblies are treated as architecture-dependent and so
they (including the GAC) are put into %{_libdir} which is /usr/lib64 on
x86_64 systems.
However, it seems to be the standard for mono to place the assemblies
under %{_prefix}/lib/, regardless of the architecture.
As far as I know this decision was based on a statement from the mono
developers ([1]), that although the C# assemblies are currently
architecture independent, it can not be guaranteed that they will be
forever. That is why Fedora treats C# assemblies as arch-dependent files
and so they are installed on multi-arch x86_64 systems into /usr/lib64.
Not exactly. As Miguel mentioned, mono at the time required that AOT-compiled
shared libraries be placed next to the assembly, e.g. for mscorlib.dll the
AOT-compiled mscorlib.dll.so must be in the same directory.
However, no Linux distribution actually uses AOT-compiled assemblies (that I
know of, anyway). Hence my quote: the feature is there, but it's rarely
(never?) used, so using this as a reason to be different from openSUSE, Debian,
Ubuntu, and the default build setup seems like chasing the perfect at the
expense of the good.
This is also somewhat moot as Mono no longer requires that the AOT-compiled .so
be next to the assembly, as it can instead look for assemblies in
~/.mono/aot-cache if the MONO_AOT_CACHE environment variable is set; see
mini/aot-runtime.c!load_aot_module_from_cache [0].
A proper fix would likely involve altering the runtime so that other well
defined platform-specific directories are checked for AOT .so's before JITing
the assembly, but this apparently hasn't been important enough for anyone to
actually implement (the above nobody uses AOT argument).
As far as I know, the C# assemblies are indeed architecture independent
(as defined by the CIL standard). There may be some corner cases where
it is possible to explicitly write arch-dependent code, but these may be
treated as bugs in the projects.
It _is_ possible to have platform specific assemblies. Not because the IL is
platform specific (as you note), but because of Platform Invoke [1], which
allows ~direct invocation of native code. Managed code may thus embody platform
specific assumptions. For example, consider nanosleep(2) [2]:
struct timespec {
time_t tv_sec;
long tv_nsec;
};
int nanosleep(const struct timespec* req, struct timespec *rem);
What's `time_t`? That can vary amongst POSIX implementations. What's `long`?
That can (and will!) vary between ILP32 (32-bit linux; 32-bits), LP64 (64-bit
Linux; 64-bits), and P64 (Win64; 32-bits) platforms.
A naive P/Invoke would be:
struct Timespec {
public int tv_sec;
public int tv_nsec;
}
class NativeMethods {
[DllImport (libc.so)]
public static extern int nanosleep (ref Timespec req, out
Timespec rem);
}
This is naive because it assumes that time_t is 32-bits in size, and `long` is
also 32-bits in size; in short, this will only work on 32-bit platforms, and
will fail in weird ways on 64-bit platforms.
This can be fixed, and as such treating the declaration as a bug to be fixed is
valid:
struct Timespec {
public IntPtr tv_spec;
public IntPtr tv_nsec;
}
Using `IntPtr` instead of `int` results in the use of 32-bit values on 32-bit
platforms, and 64-bit values on 64-bit platforms. This is thus portable between
ILP32 and LP64 Linux platforms...and thus breaks on Win64. In this case we can
declare that Windows is unsupported (which makes sense as Windows doesn't
provide nanosleep(2) anyway, unless you use cygwin.dll).
However, we're still assuming that `time_t` is an integral value, which is
valid on Linux but is not required by the standard [3]:
time_t and clock_t shall be integer or real-floating types.
In this case it still might not matter...as long as we have the size correct (a
32-bit float can still be read as a 32-bit int, it'll just look weird), but
nothing stops some bizarre 32-bit POSIX platform from using a 64-bit double for
time_t, which would invalidate the Timespec declaration.
Again, we can declare that the perfect is the enemy of the good and leave it as
is...or we can involve native code to do the type conversions for us, which is
what Mono.Posix.dll and libMonoPosixHelper.so do.
- Jon
[0] https://github.com/mono/mono/blob/master/mono/mini/aot-runtime.c#L843
[1] http://mono-project.com/Dllimport
[2] http://linux.die.net/man/2/nanosleep
[2] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Re: [Mono-dev] Using SslStream
Sorry for revive this thread, but I'm having the same problem. I'm using CentOS with mono 2.10.2 as server and Windows XP as client. My Code Socket socket = tcp.AcceptSocket(); X509Certificate certificado = X509Certificate.CreateFromCertFile(dg1.cer); ns = new SslStream(new NetworkStream(socket)); ns.AuthenticateAsServer(certificado); When the service is going Authenticate it throws the same exception of Richter's code. System.IO.IOException: The authentication or decryption has failed. --- Mono.Security.Protocol.Tls.TlsException: Server certificate Private Key I created a certificate by Apple KeyChain but didn't work, after read a lot, I created a certificate by Mono makecert and I added the certificate to mono certmgr trust store, but didn't work too. I don't know what can I do to solve my problem. Thanks in advance, João Paulo Ros -- View this message in context: http://mono.1490590.n4.nabble.com/Using-SslStream-tp1745666p3535805.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Using SslStream
On Thu, 2011-05-19 at 07:12 -0700, jpros wrote: Sorry for revive this thread, but I'm having the same problem. I'm using CentOS with mono 2.10.2 as server and Windows XP as client. My Code Socket socket = tcp.AcceptSocket(); X509Certificate certificado = X509Certificate.CreateFromCertFile(dg1.cer); ns = new SslStream(new NetworkStream(socket)); ns.AuthenticateAsServer(certificado); When the service is going Authenticate it throws the same exception of Richter's code. System.IO.IOException: The authentication or decryption has failed. --- Mono.Security.Protocol.Tls.TlsException: Server certificate Private Key I created a certificate by Apple KeyChain but didn't work, after read a lot, I created a certificate by Mono makecert and I added the certificate to mono certmgr trust store, but didn't work too. I don't know what can I do to solve my problem. You are confusing issues. The common trust issue is (mostly) a client issue, i.e. the client must trust the certificate that a server is using in order for SSL to be useful. Now your client is on Windows XP (not sure it's running Mono or not [1]). Your code is server code (which is executed on centos, right?) and the exception you're seeing is about the (missing) private key (not a trust issue) [2]. This happens because the .cer file (that you're feeding to your server) is *only* a certificate. A X.509 certificate includes the public key (good enough for the client in this case) but does *NOT* include the private key, which the server requires to establish a secure channel with the client. One way to solve this is using Mono's makecert and generate a pkcs#12 file (i.e. which includes both the certificate(s) and the private key) and use this in your server code. A recent thread [3] includes more details Sebastien [1] when asking for help please provide all details, e.g. .net runtime used (e.g. on windows), mono versions [2] googling Mono AuthenticateAsServer would have pointed this out [3] http://comments.gmane.org/gmane.comp.gnome.mono.general/42060 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] compiling (2.10.2) on a beagleboard-xm running Ubuntu
Maybe I will try 2.8.2 again... I was running into compile issues (think it was my sandbox config) and gave up on it and instead moved to 2.10.2 where I was having better luck getting it at least compiled and built. My problem is identical to yours... I can run mono (mono --help) with no help but when I try a .NET program the whole thing just chokes. I know that it can't be the .NET programs because they run fine with 2.6.2 on the same platform. Thanks, Dennis -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of FlorianWagner Sent: Thursday, May 19, 2011 2:30 AM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] compiling (2.10.2) on a beagleboard-xm running Ubuntu Hello Dennis, this week, I tried to compile the mono runtime 2.10.2 for a proprietary linux platform. The runtime itself was running (at least I could run mono --help), but, I have not been able to run .NET programs. The program crashed before reaching the actual .NET code. I also tried mono 2.10.1, no success. Finally, I used 2.8.2 and everything was fine. I couldn't figure out why 2.8.2 is running and 2.10.1 and 2.10.2 are failing. Regards, Florian -- View this message in context: http://mono.1490590.n4.nabble.com/compiling-2-10-2-on-a-beagleboard-xm-r unning-Ubuntu-tp3527139p3535230.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ 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] Platform independence of mono assemblies
Hi Jonathan, thank you very much for the answer! Here are a couple of follow-up questions: On 05/19/2011 03:46 PM, Jonathan Pryor wrote: On May 18, 2011, at 5:53 PM, Christian Krause wrote: As far as I know this decision was based on a statement from the mono developers ([1]), that although the C# assemblies are currently architecture independent, it can not be guaranteed that they will be forever. That is why Fedora treats C# assemblies as arch-dependent files and so they are installed on multi-arch x86_64 systems into /usr/lib64. Not exactly. As Miguel mentioned, mono at the time required that AOT-compiled shared libraries be placed next to the assembly, e.g. for mscorlib.dll the AOT-compiled mscorlib.dll.so must be in the same directory. So to summarize: - C# / CLI assemblies are itself platform independent - the pre-compiled AOT ELF binaries are platform dependent (but are not in wide-spread use and there may be other options where to place them in the future) - interfacing native code can be done platform dependent or independent (see below) However, no Linux distribution actually uses AOT-compiled assemblies (that I know of, anyway). Hence my quote: the feature is there, but it's rarely (never?) used, so using this as a reason to be different from openSUSE, Debian, Ubuntu, and the default build setup seems like chasing the perfect at the expense of the good. ;-) Just to remove all uncertainties: Is it the view of the mono developers, that the standard libraries from the mono project interfacing the native libraries in an platform-independent way? If there would be a platform dependency left by accident, would this be considered a valid bug report? Would you also agree, that if 3rd party projects use platform-dependent assemblies this should be treated as a bug which has to be fixed? As far as I know, the C# assemblies are indeed architecture independent (as defined by the CIL standard). There may be some corner cases where it is possible to explicitly write arch-dependent code, but these may be treated as bugs in the projects. It _is_ possible to have platform specific assemblies. Not because the IL is platform specific (as you note), but because of Platform Invoke [1], which allows ~direct invocation of native code. Managed code may thus embody platform specific assumptions. For example, consider nanosleep(2) [2]: Yes, that's aligned with my understanding of the various ways to interface native code ( http://www.mono-project.com/Interop_with_Native_Libraries ) and their respective levels of architecture independence. Best regards, Christian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WebConnectionStream.Read() timeout downloading large files with Mono 2.10.1
One other note: I was also able to reproduce this on using the latest tarball of Mono 2.10.2 on a quad-core Xeon running Windows 7, but only 1 out of 4 attempts. From: Tom Philpot tom.phil...@logos.commailto:tom.phil...@logos.com Date: Thu, 19 May 2011 08:50:27 -0700 To: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] WebConnectionStream.Read() timeout downloading large files with Mono 2.10.1 So, after running an automated git bisect, it turns out that commit 50a295ac1be (https://github.com/mono/mono/commit/50a295ac1becc5c0927917644a1b246b4c8e945b#mcs/class/System/System.Net.Sockets/Socket_2_1.cs) caused the breakage on the dual-core Macs we're using. Unfortunately, fixing it is not as simple as git revert 50a295ac1be as there are some conflicts and once those are resolved, Socket.EndReceive ends up getting called twice. Any thoughts? From: Tom Philpot tom.phil...@logos.commailto:tom.phil...@logos.com Date: Tue, 17 May 2011 12:16:10 -0700 To: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: WebConnectionStream.Read() timeout downloading large files with Mono 2.10.1 Since switching to 2.10.1 for our app, we're seeing a lot more Read() timeouts when downloading large files (greater than 50 MB or so). I've created a small test program that reproduces the behavior. We've noticed that this bug is that it is more likely to happen on users systems who only have 2 cores. On machines with 4 or more cores, bug does not manifest itself as much. Running the test program under 2.6.x works fine, but under 2.10.1 it fails more often than not for me when I run on my MacBook. It runs fine on my MacPro whether I use 2.6.x or 2.10.1 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
