[Mono-dev] Exception with Mono reading application setting, not with .NET
Hi all, Trying a new application which has a setting file and which was running fine on .NET, I got the following exception when running it in Mono: System.Configuration.ConfigurationErrorsException: Unrecognized attribute 'xsi'. (/root/gwtest/PrivateLife.exe.config line 1) at System.Configuration.ConfigurationElement.DeserializeElement (System.Xml.XmlReader reader, Boolean serializeCollectionKey) [0x0] in filename unknown:0 at System.Configuration.ConfigurationSection.DoDeserializeSection (System.Xml.XmlReader reader) [0x0] in filename unknown:0 at System.Configuration.ConfigurationSection.DeserializeSection (System.Xml.XmlReader reader) [0x0] in filename unknown:0 at System.Configuration.Configuration.GetSectionInstance (System.Configuration.SectionInfo config, Boolean createDefaultInstance) [0x0] in filename unknown:0 at System.Configuration.ConfigurationSectionCollection.get_Item (System.String name) [0x0] in filename unknown:0 at System.Configuration.Configuration.GetSection (System.String path) [0x0] in filename unknown:0 at Yoono.Config.FileDataProvider.Initialize () [0x0] in filename unknown:0 Here is my .config file: ?xml version=1.0? configuration configSections section name=ServerConfiguration type=YooNo.Config.ServerConfigurationSection, YooNo/ /configSections ServerConfiguration xmlns=http://tempuri.org/YooNo.xsd; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=YooNo.xsd Website ... Actually, I've added to the .config file some attributes to specify a XSD for that .config (with intellisense, that really helps when manually modifying the .config). .NET accepts it without yelling, but it seems Mono doesn't. Any advice on how to do? Can I simply rewrite these two xmlns attributes differently? Should I remove them? ... or should I open a ticket in Mono bugtracker? Thanks in advance for your tips! Lionel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono's future
Are there any metrics on Mono usage? Number of end-users, developers, projects, companies, by platform, etc. etc.? (apart http://www.mono-project.com/Companies_Using_Mono ) (and, yes, we all hope Mono and Xamarin will blossom, not only on mobile platforms but also Linux, osx and windows with full compatibility with .NET) -Message d'origine- De : mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] De la part de Andrew Brehm Envoyé : mardi 5 juillet 2011 11:27 À : mono-devel-list@lists.ximian.com Objet : Re: [Mono-dev] Mono's future Robert Jordan wrote: On 01.07.2011 12:01, ah hatem wrote: What is the current status of mono after the layoff of the entire mono team? How will that affect mono on the short and long terms? How much of the mono The former Novell employees are now focused on product development for mobile platforms and their tooling. Parts of Mono/.NET framework unrelated to these platforms may become more or less abandoned, but they already were, so this is nothing new! I do hope that Xamarin will also offer Mono for Mac OS X, Linux and Windows like Novell did before. MonoMac is too good to give up! -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-s-future-tp3637865p3645514.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
[Mono-dev] TR: How to access XplatUI for custom controls?
To go a little further: many good .NET controls, opensource or not, use win32 calls. Many developpers I have met only know the win32 APIs and nor their equivalent in Linux. Typically, many well-known commercial GUI toolkits (componentOne, devexpress, infragistics, ...) use Win32 calls and so cannot run on Linux. If Mono was providing a class to interface/hide these platform-specific calls, that would drive people to port/create nice .NET controls, including all the commercial packages above, that could run on Mono/Linux. That would be a great result, wouldn't it? _ De : Lionel Cuir [mailto:lionel_em...@aulofee.com] Envoyé : vendredi 15 octobre 2010 08:45 À : 'Miguel de Icaza' Objet : RE: [Mono-dev] How to access XplatUI for custom controls? Right now, I'm using only a very limited subset: GetFocus, ResetMouseHover ScrollWindow So obviously, I could manage it manually. But I was thinking about porting various opensource controls, available on Internet and which uses GUI-related win32 calls (such as the ecellent DockPanel). As a lot of work has been within XplatUI and its drivers, I was looking at reusing them. My first idea was to ask about making all/some XplatUI's methods public. But maybe the easier way is to extract what's needed from these classes (easier but not smarter way though). _ De : miguel.nov...@gmail.com [mailto:miguel.nov...@gmail.com] De la part de Miguel de Icaza Envoyé : jeudi 14 octobre 2010 18:34 À : Lionel Cuir Cc : mono-devel-list@lists.ximian.com Objet : Re: [Mono-dev] How to access XplatUI for custom controls? Making it public would make your code not work on Windows's Windows.Forms. What exactly do you need from the XplatUI? On Thu, Oct 14, 2010 at 12:13 PM, Lionel Cuir lionel_em...@aulofee.com wrote: Hi all, I'm creating a custom control (a list view with extended functionalities) and would need to access some low-level GUI methods provided by the XplatUI class. This in order to access platform-specific actions (scroll window, mouse actions...) without to explicitly test the platform / call the right platform's API - and to avoid to redo what others have brilliantly done! Yet, XplatUI is defined as an internal class and so cannot be accessed directly. Is there another way to access it? Or could it be made public in a future version of Mono? Regards, Lionel ___ 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] TR: How to access XplatUI for custom controls?
To encapsulate common methods is exactly what I mean, and that's what provides XplatUT. Kind of things (GetFocus, Show/GetWindows, etc.) that so few .NET developpers know how to do on linux. So why not an external library giving access to some of XplatUI methods? -Message d'origine- De : mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] De la part de Stifu Envoyé : vendredi 15 octobre 2010 10:37 À : mono-devel-list@lists.ximian.com Objet : Re: [Mono-dev] TR: How to access XplatUI for custom controls? It's up to the developer to make his/her own interface for native calls. Or an external library could be made to encapsulate common methods, that would work too, and wouldn't break compatibility with .NET WinForms. At some point, there were also plans to turn native Windows calls into managed calls (M/Invoke), so that many more Windows apps would work with Mono, but that project never got anywhere. Lionel Cuir wrote: To go a little further: many good .NET controls, opensource or not, use win32 calls. Many developpers I have met only know the win32 APIs and nor their equivalent in Linux. Typically, many well-known commercial GUI toolkits (componentOne, devexpress, infragistics, ...) use Win32 calls and so cannot run on Linux. If Mono was providing a class to interface/hide these platform-specific calls, that would drive people to port/create nice .NET controls, including all the commercial packages above, that could run on Mono/Linux. That would be a great result, wouldn't it? _ De : Lionel Cuir [mailto:lionel_em...@aulofee.com] Envoyé : vendredi 15 octobre 2010 08:45 À : 'Miguel de Icaza' Objet : RE: [Mono-dev] How to access XplatUI for custom controls? Right now, I'm using only a very limited subset: GetFocus, ResetMouseHover ScrollWindow So obviously, I could manage it manually. But I was thinking about porting various opensource controls, available on Internet and which uses GUI-related win32 calls (such as the ecellent DockPanel). As a lot of work has been within XplatUI and its drivers, I was looking at reusing them. My first idea was to ask about making all/some XplatUI's methods public. But maybe the easier way is to extract what's needed from these classes (easier but not smarter way though). _ De : miguel.nov...@gmail.com [mailto:miguel.nov...@gmail.com] De la part de Miguel de Icaza Envoyé : jeudi 14 octobre 2010 18:34 À : Lionel Cuir Cc : mono-devel-list@lists.ximian.com Objet : Re: [Mono-dev] How to access XplatUI for custom controls? Making it public would make your code not work on Windows's Windows.Forms. What exactly do you need from the XplatUI? On Thu, Oct 14, 2010 at 12:13 PM, Lionel Cuir lionel_em...@aulofee.com wrote: Hi all, I'm creating a custom control (a list view with extended functionalities) and would need to access some low-level GUI methods provided by the XplatUI class. This in order to access platform-specific actions (scroll window, mouse actions...) without to explicitly test the platform / call the right platform's API - and to avoid to redo what others have brilliantly done! Yet, XplatUI is defined as an internal class and so cannot be accessed directly. Is there another way to access it? Or could it be made public in a future version of Mono? Regards, Lionel ___ 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 -- View this message in context: http://mono.1490590.n4.nabble.com/TR-How-to-access-XplatUI-for-custom-contro ls-tp2996592p2996695.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
[Mono-dev] Optimization for SystemResPool (managed windows form)
The SystemResPool class (in Theme.cs) is quite heavily used across managed
windows forms. Yet, it still use the old Hashtable (instead of Dictionary)
and mainly some of its internal caching dictionary uses strings as key (ex:
to get the cached pen for a given color, it converts the color to a string
rather than using its Argb as a key).
Here is the modified code (sorry, I'm sending this code on the fly as I'm
not on a computer right now, and so has no access to any diff program nor
can run the Mono's unit tests).
Note also that the CPColor (in Theme.cs) used as key of a
dictionary/hashtable in SystemResPool, should have its Equals and
GetHashCode overloaded, for better performance (if not, the methods of the
ValueType class are used, which use reflection).
Cheers,
Lionel
internal class SystemResPool
{
private Dictionaryint, Pen pens = new Dictionaryint, Pen();
private Dictionarylong, Pen dashpens = new Dictionarylong, Pen();
private Dictionarylong, Pen sizedpens = new Dictionarylong, Pen();
private Dictionaryint, SolidBrush solidbrushes = new Dictionaryint,
SolidBrush();
[...]
public Pen GetPen(Color color)
{
int hash = color.ToArgb();
lock (pens)
{
Pen res;
if (pens.TryGetValue(hash, out res))
return res;
Pen pen = new Pen(color);
pens.Add(hash, pen);
return pen;
}
}
public Pen GetDashPen(Color color, DashStyle dashStyle)
{
//string hash = color.ToString() + dashStyle;
long hash = color.ToArgb() 32 + (int)dashStyle;
lock (dashpens)
{
Pen res;
if (dashpens.TryGetValue(hash, out res))
return res;
Pen pen = new Pen(color);
pen.DashStyle = dashStyle;
dashpens[hash] = pen;
return pen;
}
}
public Pen GetSizedPen(Color color, int size)
{
//string hash = color.ToString() + size;
long hash = color.ToArgb() 32 + size;
lock (sizedpens)
{
Pen res;
if (sizedpens.TryGetValue(hash, out res))
return res;
Pen pen = new Pen(color, size);
sizedpens[hash] = pen;
return pen;
}
}
public SolidBrush GetSolidBrush(Color color)
{
int hash = color.ToArgb();
lock (solidbrushes)
{
SolidBrush res;
if (solidbrushes.TryGetValue(hash, out res))
return res;
SolidBrush brush = new SolidBrush(color);
solidbrushes.Add(hash, brush);
return brush;
}
}
[...]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] How to access XplatUI for custom controls?
Hi all, I'm creating a custom control (a list view with extended functionalities) and would need to access some low-level GUI methods provided by the XplatUI class. This in order to access platform-specific actions (scroll window, mouse actions...) without to explicitly test the platform / call the right platform's API - and to avoid to redo what others have brilliantly done! Yet, XplatUI is defined as an internal class and so cannot be accessed directly. Is there another way to access it? Or could it be made public in a future version of Mono? Regards, Lionel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on MIPS32
We compiled successfully Mono (2.4.2.3) as well as an early 2.6(taken from SVN) on openembedded. See with Cliff Brake from Bec Systems - he is the expert on this topic. On x86, the result is very nice: a dedicated linux box of 50 Mo with network support and the full Mono on it! Lionel -Message d'origine- De : mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] De la part de Rayson Ho Envoyé : samedi 15 mai 2010 18:14 À : Andrea Cc : Mono Development mailing list Objet : Re: [Mono-dev] Mono on MIPS32 On Sat, May 15, 2010 at 3:28 AM, Andrea serr...@gmail.com wrote: Yes, we tested your patch unsuccessfully. We use openembedded to crosscompile mono, we tested your patch with the last svn, but when we run mono to the target the only output is Segmentation fault. You are introducing too many variables by using the latest svn, openembedded to cross compile, a non-Loongson processor as your target. It would help if you can downgrade the Mono version to the latest 2.4, and introduce any possible source of failure one at a time. I am still waiting for the new MIPS port, so I am not going to touch the latest svn or even Mono 2.6 for a little while. Rayson We tested your patch also in svn r136576, but the compile process fails: | Compilation failed: 1 error(s), 19 warnings | make[7]: *** [../class/lib/basic/mcs.exe] Error 1 | make[7]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs/mcs' | make[6]: *** [do-all] Error 2 | make[6]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs/mcs' | make[5]: *** [all-recursive] Error 1 | make[5]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs' | make[4]: *** [profile-do--basic--all] Error 2 | make[4]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs' | make[3]: *** [profiles-do--all] Error 2 | make[3]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs' | make[2]: *** [all-local] Error 2 | make[2]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mono/runtime' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mono' | make: *** [all] Error 2 | FATAL: oe_runmake failed NOTE: Task failed: /home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-n ative-2.6.4+svnrr136576-r0/temp/log.do_compile.10933 any help is welcome! Thank you Andrea On Fri, May 14, 2010 at 5:37 PM, Lorenz Cuno Klopfenstein l...@klopfenstein.net wrote: Hello all, I am currently trying to get Mono to run on a little endian MIPS32 based board, but without much success. In fact, compiling Mono - using the same toolchain that worked for other apps - produces a whopping 8.5 megabytes mono executable. Attempting to run it (even launching mono --version or anything) returns a segmentation fault. It appears that the compilation produces a flawed executable, even if it succeeds. Does anybody have some suggestions on building Mono on a MIPS board? Thank you in advance for any help. -- Lorenz Cuno Klopfenstein l...@klopfenstein.net http://lorenz.klopfenstein.net ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Equivalent of DPAPI in Linux / Status of ProtectedData ?
Hello, In Windows/.NET, we can access the DPAPI via the ProtectedData class. According to http://www.mono-project.com/Cryptography, There is partial support for ProtectedData and ProtectedMemory on Mono. On Windows Mono will use DPAPI (Data Protection API) for increased interoperability, while it will use its own implementation on other operating systems. = Is it possible to have any details about this own implementation? How secure it is? On which mechanism/other software it relies in Linux? Many thanks in advance, Lionel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Getting the list of all AppDomains in a process
Hi All,
I need to get a list of all loaded AppDomains in the running process
(without asking developer to explicitely register them in a static hashtable
for instance). In .NET on Windows, I can use COM Interop (see code below).
But this is of course unlikely to run in Mono/Linux. Does anybody know how
to do?
Zoltan, I've read in http://www.mono-project.com/Todo that there would be a
appdomain ID-indexed tables = can it be used for this? Where is it?
thks in advance for your ideas
Lionel
Code to do this with COM Interop on Windows (coming from
http://weblogs.asp.net/nunitaddin/archive/2003/02/07/1992.aspx):
// Add the following as a COM reference...
// C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705\mscoree.tlb
using System;
using System.Collections;
using System.Runtime.InteropServices;
using mscoree;
public class AppDomainUtils
{
public static IList ListAppDomains()
{
CorRuntimeHostClass host = new CorRuntimeHostClass();
try
{
ArrayList list = new ArrayList();
IntPtr enumHandle;
host.EnumDomains(out enumHandle);
while(true)
{
object domain;
host.NextDomain(enumHandle, out domain);
if(domain == null) break;
list.Add((AppDomain)domain);
}
host.CloseEnum(enumHandle);
return list;
}
finally
{
Marshal.ReleaseComObject(host);
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Getting the list of all AppDomains in a process
Thank for the quick answer. Alas, the AppDomainManager is not a solution for us, as the assembly is not supposed to be in the GAC. -Message d'origine- De : mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] De la part de Robert Jordan Envoyé : vendredi 12 février 2010 11:20 À : mono-devel-list@lists.ximian.com Objet : Re: [Mono-dev] Getting the list of all AppDomains in a process On 12.02.2010 09:44, Lionel Cuir wrote: Hi All, I need to get a list of all loaded AppDomains in the running process (without asking developer to explicitely register them in a static hashtable for instance). In .NET on Windows, I can use COM Interop (see code below). But this is of course unlikely to run in Mono/Linux. Does anybody know how to do? There is no way to enum AppDomains in Mono. Even the embedding API (which is the counterpart of MS.NET's coree COM API) does not provide a complete API for AppDomain enumerations [1]. But once AppDomainManager[2] is implemented in Mono, you'll have a portable solution for domain enumerations. I don't know if this is in the work. Robert [1] since there is no MonoAppDomain* mono_appdomain_from_domain (MonoDomain *dom) accessor in the embedding API, mono_domain_foreach can't be used to enum MonoAppDomains. [2] see MSDN ___ 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-dev] Big performance gaps between .NET, Mono (Suse/Debian) ?
Hello,
Can anybody help me to understand why, on simple performance tests, I see so
different results between .NET and Mono on various Linux platforms? Are my
tests incorrect? Did I have no luck and simply fall on some
methods/functionality better implemented by MS? And why is there such a
difference between Suse and Debian for the IPAddress dictionary?
Any help appreciated (please, no trolling, no political debate - just ideas
about how to improve things or ideas to point out methodology errors I would
have made in my tests)
Regards,
Lionel
A few hints on how I did my tests:
- the OS are: a bare XP SP3, a bare OpenSuse (kernel 2.6.27), a Debian with
a lightened kernel (2.6.30) - bare = the OS is up-to-date but no other
software installed
- all OS were running as vmware guest (in vm workstation 6.5) with two
cpus (dual-core T7200) and 512Mo of RAM
- Mono version was 2.4.2.3 on Suse, and 2.5 (compiled from SVN r140059) on
Debian. .NET version is 3.5
- On Suse and Debian, I both run the tests with the exe compiled with csc
(.net) and with the exe compiled with gmcs - the results were the same.
You'll find attached the sample code I used - I test basically a dictionary
of int, a dictionary of IPAddress and the IPAddress.ToString method. The
duration of the test (in millisec are:
int32 Dictionary test
4812 DotNet
9493 Mono on light Debian
9815 Mono on Suse
IPAddress Dictionary test
13500 DotNet
29533 Mono on light Debian
41732 Mono on Suse
IPAddress.ToString test
2453 DotNet
16665 Mono on light Debian
17747 Mono on Suse
using System;
using System.Collections.Generic;
using System.Net;
namespace Test
{
public class Class1
{
static void Main(string[] args)
{
TestPerfOnDico();
TestPerfOnIpAddress();
}
static void TestPerfOnIpAddress()
{
Console.WriteLine(IPAddress.ToString test);
long sum = 0;
int count = (int)Math.Pow(10, 7);
Console.Write(Iterations (def={0:0,0})? , count);
string sChoice = Console.ReadLine();
if (!string.IsNullOrEmpty(sChoice))
count = int.Parse(sChoice);
IPAddress ip;
for (int i = 0; i 100; i++)
{
ip = new IPAddress(i);
sum += ip.ToString().Length;
}
Console.WriteLine(Dummy: + sum);
sum = 0;
DateTime start = DateTime.UtcNow;
for (int i = 0; i count; i++)
{
ip = new IPAddress(i);
sum += ip.ToString().Length;
}
TimeSpan duration = DateTime.UtcNow.Subtract(start);
Console.WriteLine(Total: + sum);
Console.WriteLine(Duration: +
duration.TotalMilliseconds);
}
static void TestPerfOnDico()
{
int count = (int)Math.Pow(10, 8);
Console.Write(Iterations (def={0:0,0})? , count);
string sChoice = Console.ReadLine();
if (!string.IsNullOrEmpty(sChoice))
count = int.Parse(sChoice);
Console.WriteLine(int32 Dictionary test);
DateTime start = DateTime.UtcNow;
int intDicoSizeMax = 1;
Dictionaryint, int dicoInt = new Dictionaryint,
int();
for (int i = 0; i count; i++)
{
int key = (int)long)i) * 5 + 11) %
intDicoSizeMax);
dicoInt[key] = i;
}
TimeSpan duration = DateTime.UtcNow.Subtract(start);
Console.WriteLine(Duration for int dico (in millisec):
+ duration.TotalMilliseconds);
Console.WriteLine(IPAddress Dictionary test);
start = DateTime.UtcNow;
int iPAddressDicoSizeMax = 1;
DictionaryIPAddress, IPAddress dicoIP = new
DictionaryIPAddress, IPAddress();
for (int i = 0; i count; i++)
{
long key = long)i) * 5 + 11) %
iPAddressDicoSizeMax);
IPAddress ip = new IPAddress(key);
dicoIP[ip] = ip;
}
duration = DateTime.UtcNow.Subtract(start);
Re: [Mono-dev] Big performance gaps between .NET, Mono (Suse/Debian) ?
Yes, the testing conditions were the same for all virtual machines (xp, suse, debian): nothing else was running (and only the base service/daemon - no web server, no database and so on: just the bare OS). Besides, I ran the tests several times and the figures were stable. _ De : mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] De la part de Euan MacInnes Envoyé : mardi 6 octobre 2009 12:32 À : mono-devel-list@lists.ximian.com Objet : Re: [Mono-dev] Big performance gaps between .NET, Mono (Suse/Debian) ? What is the background noise on the CPU load in the VMWare environments? Are all the CPUs running at the same spare capcity, and the same/similar CPU utilisation during the tests, or are tasks running in the background, system updates etc.. on the Linuxes that's eating resources? Cheers, Euan. _ Date: Tue, 6 Oct 2009 12:27:12 +0200 From: skol...@gmail.com To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Big performance gaps between .NET, Mono (Suse/Debian) ? On Tue, Oct 6, 2009 at 12:15 PM, Robert Jordan robe...@gmx.net wrote: Lionel Cuir wrote: A few hints on how I did my tests: - the OS are: a bare XP SP3, a bare OpenSuse (kernel 2.6.27), a Debian with a lightened kernel (2.6.30) - bare = the OS is up-to-date but no other software installed - all OS were running as vmware guest (in vm workstation 6.5) with two cpus (dual-core T7200) and 512Mo of RAM - Mono version was 2.4.2.3 on Suse, and 2.5 (compiled from SVN r140059) on Debian. .NET version is 3.5 - On Suse and Debian, I both run the tests with the exe compiled with csc (.net) and with the exe compiled with gmcs - the results were the same. You're benching different Mono versions. Mono 2.4 was branched in January, whereas r140059 is pretty up-to-date. Besides, while measuring DictionaryT, K performance has some relation to actual program performance, I doubt whether anyone will call IPAdress.ToString() often enough to even notice the speed difference... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Big performance gaps between .NET, Mono (Suse/Debian) ?
Thanks for the answers
Interesting remarks. I voluntarily added the allocation of objects within
the mesurable time, to have an overall picture (and I was not aware of the
mono GC's relative slowness).
I modified my tests as you advised but the results still show a big
difference between .net and mono. Could it be that the measuring window
still include GC work? Could you have a look at my code (see attached file)
to see if we agree on what should be preallocated in order to put apart the
GC? Apart for the int32 preallocation (I don't know if preallocating value
type can be meaningful), the code is supposed to preallocate both
dictionaries + the IPAddresses.
Here are the results with preallocation (again, what's matter is not the
exact value but the magnitude):
Preallocated int32 Dictionary test
4937 DotNet
9856 Mono on light Debian
9554 Mono on Suse
Preallocated IPAddress Dictionary test
8375 DotNet
16414 Mono on light Debian
17084 Mono on Suse
Lionel
_
De : Alan McGovern [mailto:alan.mcgov...@gmail.com]
Envoyé : mardi 6 octobre 2009 12:46
À : Lionel Cuir
Cc : mono-devel-list@lists.ximian.com
Objet : Re: [Mono-dev] Big performance gaps between .NET, Mono (Suse/Debian)
?
Calling 'ToString' is just a GC benchmark. Yes, the current mono GC is
slower than the .NET GC in this scenario. Your other tests also do a fair
bit of allocating, so it's quite possible the entire performance loss you're
seeing is just from the GC kicking in. If you want to test how fast you can
add elements to a Dictionary, pre-allocate all the objects first and then
time just the addition.
Alan.
On Tue, Oct 6, 2009 at 10:15 AM, Lionel Cuir lionel_em...@aulofee.com
wrote:
Hello,
Can anybody help me to understand why, on simple performance tests, I see so
different results between .NET and Mono on various Linux platforms? Are my
tests incorrect? Did I have no luck and simply fall on some
methods/functionality better implemented by MS? And why is there such a
difference between Suse and Debian for the IPAddress dictionary?
Any help appreciated (please, no trolling, no political debate - just ideas
about how to improve things or ideas to point out methodology errors I would
have made in my tests)
Regards,
Lionel
A few hints on how I did my tests:
- the OS are: a bare XP SP3, a bare OpenSuse (kernel 2.6.27), a Debian with
a lightened kernel (2.6.30) - bare = the OS is up-to-date but no other
software installed
- all OS were running as vmware guest (in vm workstation 6.5) with two
cpus (dual-core T7200) and 512Mo of RAM
- Mono version was 2.4.2.3 on Suse, and 2.5 (compiled from SVN r140059) on
Debian. .NET version is 3.5
- On Suse and Debian, I both run the tests with the exe compiled with csc
(.net) and with the exe compiled with gmcs - the results were the same.
You'll find attached the sample code I used - I test basically a dictionary
of int, a dictionary of IPAddress and the IPAddress.ToString method. The
duration of the test (in millisec are:
int32 Dictionary test
4812 DotNet
9493 Mono on light Debian
9815 Mono on Suse
IPAddress Dictionary test
13500 DotNet
29533 Mono on light Debian
41732 Mono on Suse
IPAddress.ToString test
2453 DotNet
16665 Mono on light Debian
17747 Mono on Suse
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
using System;
using System.Collections.Generic;
using System.Net;
namespace Test
{
public class Class1
{
static void Main(string[] args)
{
TestPerfOnPreAllocatedDico();
}
static void TestPerfOnPreAllocatedDico()
{
int count = (int)Math.Pow(10, 8);
Console.Write(Iterations (def={0:0,0})? , count);
string sChoice = Console.ReadLine();
if (!string.IsNullOrEmpty(sChoice))
count = int.Parse(sChoice);
Console.WriteLine(Preallocated int32 Dictionary test);
// Let's preallocate all our objects first. Is
preallocation possible/meaningful for value types (the int32)?
int intDicoSizeMax = 1;
Dictionaryint, int dicoInt = new Dictionaryint,
int(intDicoSizeMax);
// Now we run the test.
DateTime start = DateTime.UtcNow;
for (int i = 0; i count; i++)
{
int key = (int)long)i) * 5 + 11) %
intDicoSizeMax);
dicoInt[key] = i;
}
TimeSpan duration = DateTime.UtcNow.Subtract(start);
Console.WriteLine(Duration for Preallocated int dico
(in millisec
Re: [Mono-dev] Compiling Mono v2.4 RC2 (Solaris 10 SPARCv9)
Hello Timothy, A nice how-to would be 100% welcomed. If you could find the time to write down the info you gather over the net on that subject, I (and surely many others) would really appreciate. Unless such a how-to already exists and I miss it? Best regards, Lionel -Message d'origine- De : mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] De la part de Elamide Envoyé : vendredi 31 juillet 2009 14:48 À : mono-devel-list@lists.ximian.com Objet : Re: [Mono-dev] Compiling Mono v2.4 RC2 (Solaris 10 SPARCv9) I will check the SVN head, it still exists in 2.4.2.3. vargaz wrote: Hi, On Mon, Jul 27, 2009 at 2:44 PM, Elamide timothy.l.sm...@accenture.comwrote: After reading this thread and others about building 2.4 on Solaris, I think I almost have 2.4.2.2 ready. The build succeeds, the problem is that the 'make check' fails in mini with: ** (process:13102): WARNING **: unknown opcode int_rem_un_imm in mono_arch_output_basic_block() ** ERROR **: file mini-sparc.c: line 3694 (mono_arch_output_basic_block): should not be reached aborting... This should now be fixed in mono SVN HEAD and the 2.4 branch. Zoltan -- View this message in context: http://www.nabble.com/Compiling-Mono-v2.4-RC2-%28Solaris-10-SPARCv9%29-tp225 87130p24755834.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
[Mono-dev] 3 patches for Mono.CodeGeneration
Hello all,
Thanks for the quick reply on where the latest Mono.CodeGeneration code had
been moved in svn.
Here are 3 patches - pitfully without unit test (as our own library has been
heavily customized and it'd take time to rewrite them).
The bugs fixed are nevetheless quite obvious:
- CoreOrcs and CoreAnd.cs: in the Generate method, the first expression had
it IL generated twice = 1 line removed for each class.
- CodeLiteral.cs: the fact that the value was boxed was not taken into
account and was crashing if the value was not an int (ex: object value =
(byte)1; int i = (int)value = exception thrown)
Regards
Lionel
http://www.aulofee.com
--- CodeOr.cs 2008-09-29 08:57:34.28125 +0200
+++ ..\Mono.CodeGeneration patched/CodeOr.cs2008-09-29 09:23:14.328125000
+0200
@@ -69,7 +69,6 @@
public override void GenerateForBranch(ILGenerator gen, Label
label, bool branchCase)
{
Label endLabel = gen.DefineLabel();
- exp1.Generate(gen);
if (exp1 is CodeConditionExpression)
{
--- CodeAnd.cs 2008-09-29 08:58:01.75000 +0200
+++ ..\Mono.CodeGeneration patched/CodeAnd.cs 2008-09-29 09:22:28.31250
+0200
@@ -70,7 +70,6 @@
public override void GenerateForBranch(ILGenerator gen, Label
label, bool branchCase)
{
Label endLabel = gen.DefineLabel();
- exp1.Generate(gen);
if (exp1 is CodeConditionExpression)
{
--- CodeLiteral.cs 2008-09-29 08:57:40.25000 +0200
+++ ..\Mono.CodeGeneration patched/CodeLiteral.cs 2008-09-29
09:24:22.515625000 +0200
@@ -82,7 +82,7 @@
case TypeCode.UInt16:
case TypeCode.Int32:
case TypeCode.UInt32:
- int i = (int)value;
+ int i = Convert.ToInt(value); // Old
code was (int)value; and was crashing when value was boxed.
switch (i)
{
case 0:
gen.Emit(OpCodes.Ldc_I4_0); break;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Need advice for bug 325067 (DateTime binary serialization incompatible with MS.NET 2.0)
Hello All,
I'm having a look at bug 325067 as it's still a major issue for my company.
- I've reread the whole thread and must say I'm not sure to understand
its current status. If I'm not wrong, the open issue relates to the
direct serialization of a DateTime (ie with a DateTime as the top of the
serialization tree), and the question for this is to know who is going
to be binary compatible with whom (ie Mono CLR v2 binary compatible with
either MS .Net 2.x or with Mono CLR v1). Has anything been decided for
this ? Could someone kindly advise me ?
- Additionally, it's said in the post that when Mono and MS .Net would
be binary compatible for DateTime when a DateTime is not a the top of
the serialization tree or when using the To/FromBinary methods. I've
just tested this and found anomalies, where the deserialized DateTime is
not the expected ones in Mono when the DateTimeKind of the date is
LocalTime (if the date is in UTC, that's ok). Before to call it a bug,
could anybody tell me if I'm not making a dummy mistake?
To reproduce it:
1. Serialize a DateTime into a file in MS.Net:
DateTime testDate = new DateTime(1975, 8, 14, 14, 0, 0,
DateTimeKind.Local);
using (FileStream fs = File.Create(myfile.bin))
bf.Serialize(fs, new KeyValuePairstring,
DateTime(dummytxt, testDate));
2. Deserialize it in MS.Net (Windows) and Mono (Linux)
using (FileStream fs = File.OpenRead(myfile.bin))
{
KeyValuePairstring, DateTime kvp =
(KeyValuePairstring, DateTime)bf.Deserialize(fs);
Console.WriteLine(Date read: + kvp.Value +
+ kvp.Value.Kind);
Console.WriteLine(in UTC: +
kvp.Value.ToUniversalTime().ToString());
}
In windows, I get what's expected:
Date read: 14/8/1975 14h Local time
in UTC: 14/08/1975 12:00:00
In Debian, I get wrong results:
Date read: 14/8/1975 15h Local time
in UTC: 14/08/1975 14:00:00
It seems that the DateTimeKind has not been taken into account.
Isn't it a bug?
(Note: both Windows and Debian are set to Europe/Paris (UTC+2)
time zone)
Even worst, if I use ToBinary/FromBinary to exchange the
DateTime between Windows/.Net and Linux/Mono, I get another
different result in Linux:
Date read: 14/8/1975 13h Local time
in UTC: 14/08/1975 12:00:00
= UTC time is correct, but the local time is only UTC+1 whereas
my Debian is in UTC+2 (date = mercredi 7 mai 2008, 16:21:03
(UTC+0200) )
Life is a long quiet river...
Thanks for the help
Lionel
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono, zedgraph and System.Drawing
Bonjour, In our applications which have to run on both Windows and Linux, we've been testing for a few weeks various graph libraries. Many if not all show minor differences between Windows and Linux, notably due to the different fonts used on both platforms. Zedgraph, that we tested, had a couple of issues on Mono. We did not solve them as we had to drop Zedgraph for its lack of 2,5D 3D capabilities. The solution we're likely to take is a commercial one, NetAdvantage, whose graphs look very close on both platforms (it's quite cheap but its drawback is that the designer itself only runs on Windows). Cordialement, Lionel Cuir ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Remoting with DateTime
Hello all,
I've taken some time to dig again into this issue and tried to answer
some points mentioned in the thread (please correct me if I'm wrong!).
Attached are the patch for DateTime.cs (nothing really changed since
March) and the unit test.
- DateTime managed as a PrimitiveType by the BinaryFormatter?
I've not seen any indication on the fact .NET2.0's BinaryFormatter
would not manage DateTime as a ISerializable but as a PrimitiveType.
When you look at the binary array generated by the BinaryFormatter, you
do have a two int64: the ticks and a int64 in which you have both the
ticks and the kind (as used in my patch).
- How .NET 2.0 stores DateTime internally?
To quote MSDN's page on DateTime:
Version Considerations
Prior to the .NET Framework version 2.0, the DateTime
structure contains a 64-bit field composed of an unused 2-bit field
concatenated with a private Ticks field, which is a 62-bit unsigned
field that contains the number of ticks that represent the date and
time. The value of the Ticks field can be obtained with the Ticks property.
Starting with the .NET Framework 2.0, the DateTime
structure contains a 64-bit field composed of a private Kind field
concatenated with the Ticks field. The Kind field is a 2-bit field that
indicates whether the DateTime structure represents a local
time, a Coordinated Universal Time (UTC), or whether UTC or local time
is not specified. The Kind field is used to handle conversions between
local and UTC time, but not time comparisons or arithmetic. The value
of the Kind field can be obtained with the Kind property.
If you want more details, see the #region ISerializable at the bottom
of DateTime.cs - it's commented there.
- Version compatibility
"Will this break with older Mono implementations, say with data that
was stored with old versions? It seems like you put some effort on not
breaking."
No that won't break. My patch ensure backward compatibility, namely:
Mono CLR 1.1 is not concerned by my patch (it could be) and
remains not compatible with MS .NET 1.1 and 2.x
Mono CLR 2.x not patched
is not compatible with MS .NET 2.x (in both ways)
is not able to deserialize data serialized with Mono CLR 2.x
patched (since the latter serializes its data by using MS .NET 2.x
format)
Mono for CLR 2.x patched
serializes its data by using MS .NET 2.x format
is able to read DateTime serialized with MS .NET 1.1 and 2.x
formats (MS .NET 2.x has the same backward compatibility)
is able to read DateTime serialized with Mono for CLR 1.x not
patched and 2.x not patched
- Unit test
"Would you mind providing NUnit test cases that would exercise the
various binary formats? You could bundle the stuff as a binary blob in
an array and test the various code paths."
Done. See DataTimeTest.cs
- Soap issue
My hack works but it should be considered as temporary, as long as the
issue in the Soap Serializer itself has not been solved. I'm missing
both time and knowledge of the Soap serialization's internal mechanism
to handle this...
Regards,
Lionel
--- DateTime 20070821.cs 2007-08-10 07:08:10.0 +0200
+++ DateTime 20070821 patched.cs 2007-08-29 14:56:36.0 +0200
@@ -1,3 +1,5 @@
+#define HACK_FOR_SOAP_FORMATTER_BUG
+
//
// System.DateTime.cs
//
@@ -33,6 +35,7 @@
using System.Globalization;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
+using System.Runtime.Serialization;
using System.Text;
namespace System
@@ -46,7 +49,7 @@
[StructLayout (LayoutKind.Auto)]
public struct DateTime : IFormattable, IConvertible, IComparable
#if NET_2_0
- , IComparableDateTime, IEquatable DateTime
+ , IComparableDateTime, IEquatableDateTime, ISerializable
#endif
{
private TimeSpan ticks;
@@ -2259,5 +2262,166 @@
{
throw new InvalidCastException();
}
+
+#if NET_2_0 // ISerializable Members
+
+ private DateTime(SerializationInfo info, StreamingContext context)
+ {
+ this.kind = DateTimeKind.Unspecified;
+ this.ticks = TimeSpan.MinValue;
+
+ if (info == null)
+ throw new ArgumentNullException(info);
+
+ /*
+ * Mono and .Net have different 'signatures' for their SerializationInfo's content:
+ *
+ * Mono uses:
+ * - ticks, a TimeSpan
+ * - kind, a DateTimeKind (only on .NET 2.0)
+ *
+ * And .Net uses:
+ * - in v1.0:
+ * - in v1.1: ticks, a long
+ * - in v2.0: ticks (a long) and dateData (a ulong) with the first end being the kind and the right end the ticks
+ *
+ * So we first enumerate the available field names types, and then decide what to do on that basis.
+ * If the kind is not present, it shoud be considered as equal to 0 (Unspecified).
+ */
+
+ SerializationInfoEnumerator serializedFieldEnum = info.GetEnumerator();
+ int fieldCount = info.MemberCount;
+ string serializedFieldName;
+ Type serializedFieldType;
+
+ if (fieldCount == 1)
+ {
+#region This DateTime
[Mono-dev] Release date for next version (1.2.5)?
Hello All, I've looked at the Mono roadmap which gives no information on the release date for the next release (1.2.5?). Would it be possible, at this stage, to have some indications, even rough ones? Regards, Lionel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.2.4, preparation rituals.
What's about including the fix for DateTime serialization bug I
provided? I've got no reply from Miguel regarding my last email (for
memo, the bug you pointed out, Miguel, was no related to DateTime but
to soap serialization - and the patch I provided currently circumvents
it and so works for both binary soap serialization).
Hope this fix can be included this time (our clients are waiting for
it, and we've been running with our patch applied on our devtest
platform for a couple of months now)
Best regards,
Lionel
Message original
Sujet:
[Fwd: Re: [Mono-dev] Patch status]
Date:
Wed, 28 Mar 2007 19:22:00 +0200
De:
Lionel Cuir [EMAIL PROTECTED]
Organisation:
Aulofe
Pour:
Miguel de Icaza [EMAIL PROTECTED]
Hello Miguel,
Sorry to raise this issue again. Did you have time having a look to my
analysis of the bug? Do you agree with it?
Thanks for your time,
Lionel
Message original
Sujet:
Re: [Mono-dev] Patch status
Date:
Sun, 18 Mar 2007 10:49:30 +0100
De:
Lionel Cuir [EMAIL PROTECTED]
Organisation:
Aulofe
Pour:
Miguel de Icaza [EMAIL PROTECTED]
Copie:
mono-devel-list@lists.ximian.com
Rfrences:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Hi Miguel,
It seems that you have actually discovered an issue (a bug?) in Mono's
Soap serialization, and that my patch for DateTime was correct.
Explanation:
I was a little surprised by your return as we had tested our code before
to provide it (both for serialization and deserialization on same
platform (Unix or Windows), and serialization on one platform then
deserialization on the other platform), but these tests were all done
using the BinaryFormatter.
So, if I create a DataTime and use a BinaryFormatter to serialize and
deserialize it, it works. But if I do the same with a SoapFormatter, it
crashes.
Going deeper into the code (see the few lines of code below), the
problem comes from the fact that, with Soap formatting, the
SerializationInfo.AddValue(string, XXX) will box the value types XXX
into objects - this happens at least for both long and ulong.
I didn't have time to explore the problem within the soap formatting
process but, in the meantime, to temporarily circumvent this problem,
I've added a hack into the DateTime serialization code (activated with a
#define HACK_FOR_SOAP_FORMATTER_BUG at the beginning of the file) so
that DateTime's serialization works in all cases (binary soap
formatting). This hack is tested and works well.
Code where the soap formatting problem may be observed:
void ISerializable.GetObjectData(SerializationInfo info,
StreamingContext context)
{
if (info == null)
throw new System.ArgumentNullException("info");
// ** BUG ***
// With a BinaryFormatter, this value is considered correctly
as a long
// But the SoapFormatter will box it into an object... Or at
least it's what we see at deserialization time.
// This is the same below for the ulong, boxed into an object
when doing soap-based serialization.
info.AddValue("ticks", this.ticks.Ticks);
// We serialize the DateTime the .Net 2.x way.
// Let's store the kind into the left part of dateData, and
the ticks into the right part.
ulong dateData = (ulong) long) kind) 0x3e) |
ticks.Ticks);
info.AddValue("dateData", dateData);
}
I've attached the updated DateTime and the diff, with the hack included.
I also change the error message that you got earlier to highlight the
fact the long and ulong values had been boxed into objects with Soap
formatting. Thanks to update SVN with it.
Regards,
Lionel
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Assembly.Load fails when specifying multiple directories in AppDomainSetup.PrivateBinPath
When I create an AppDomain by specifying a single subdirectory in the
AppDomainSetup.PrivateBinPath, an Assembly.Load works well in both Mono
and .Net and is able to load any assembly located in that directory.
But if I'm specifying two subdirectories, Mono will fail loading any
assembly from any of these two subdirectories, while .Net will succeed
(with the same code - see below).
Can anybody tell me if I'm doing things correctly? If that's a bug in
Mono, could you tell me to which file I should look at so that I can
try to patch the problem?
Regards,
Lionel
To reproduce the problem:
1. Use the code below to create a main application and compile it into
/home/myapp for instance.
using System;
using System.Reflection;
class MainClass : MarshalByRefObject
{
static int Main()
{
AppDomainSetup domainSetup = new AppDomainSetup();
domainSetup.ApplicationBase =
AppDomain.CurrentDomain.BaseDirectory;
domainSetup.ConfigurationFile =
AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
domainSetup.PrivateBinPath = "solution";
AppDomain _secondaryDomain =
AppDomain.CreateDomain("SecondaryDomain",
AppDomain.CurrentDomain.Evidence, domainSetup);
MainClass _secondDomainHost =
(MainClass)_secondaryDomain.CreateInstanceFromAndUnwrap(
typeof(MainClass).Assembly.Location,
typeof(MainClass).FullName);
_secondDomainHost.Run();
Console.WriteLine("Press a key to continue...");
Console.ReadKey();
return 0;
}
void Run()
{
Assembly ass = Assembly.Load("test");
Console.WriteLine("Loaded:");
Console.WriteLine(ass.FullName);
Console.WriteLine("from: " + ass.Location);
}
}
2. Create the directory /home/myapp/solution
3. Use the code below to create the assembly test.dll and compile it
into /home/myapp/solution
using System;
namespace Test
{
public class TestClass
{
}
}
4. Run the main app - it works
5. Now create the directory /home/myapp/function and change the main
application 's AppDomainSetup.PrivateBinPath statement into:
domainSetup.PrivateBinPath = "solution;function"; //
This does not work with Mono
// domainSetup.PrivateBinPath = "solution"; // Old
line - it was working
== Now, Assembly.Load throws an exception:
System.IO.FileNotFoundException: Could not load
file or assembly 'test' or one of its dependencies. The system cannot
find the file specified.
File name: 'test'
at (wrapper xdomain-invoke) MainClass:Run (string[])
at (wrapper remoting-invoke-with-check) MainClass:Run
(string[])
at MainClass.Main (System.String[] args) [0x0]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch status
Hello all, I've sent in mid-February some patches for DateTime, QueueT and StackT (for the compatibility of their serialization between Mono and .Net), and I was wondering what their status were as they've not been included into SVN. Can anybody tell me if there were issues with them? Lionel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for QueueT and StackT
As requested, the diff files created with 'diff -u'.
--- Queue.cs 2006-10-03 07:00:40.0 +0200
+++ mono-1.2.3.20070215/mcs/class/System/System.Collections.Generic/Queue.cs 2007-02-15 22:08:39.0 +0100
@@ -41,18 +41,18 @@
[Serializable]
public class QueueT : IEnumerable T, ICollection, IEnumerable
{
- T [] data;
- int head;
- int tail;
- int size;
- int version;
- int defaultCapacity;
+ T [] _array;
+ int _head;
+ int _tail;
+ int _size;
+ int _version;
+ //int defaultCapacity; // Useless as it was introducing breaking change with .NET
- private readonly static int INITIAL_SIZE = 16;
+ // private readonly static int INITIAL_SIZE = 16; // Useless as it was introducing breaking change with .NET
public Queue ()
{
- defaultCapacity = INITIAL_SIZE;
+ //defaultCapacity = INITIAL_SIZE;
}
public Queue (int count)
@@ -60,8 +60,8 @@
if (count 0)
throw new ArgumentOutOfRangeException (count);
- defaultCapacity = count;
- data = new T [count];
+ //defaultCapacity = count;
+ _array = new T [count];
}
public Queue (IEnumerable T collection)
@@ -71,15 +71,15 @@
foreach (T t in collection)
Enqueue (t);
- defaultCapacity = size;
+ //defaultCapacity = _size;
}
public void Clear ()
{
- if (data != null)
-Array.Clear (data, 0, data.Length);
+ if (_array != null)
+Array.Clear (_array, 0, _array.Length);
- head = tail = size = 0;
+ _head = _tail = _size = 0;
}
public bool Contains (T item)
@@ -105,20 +105,20 @@
if ((uint) idx (uint) array.Length)
throw new ArgumentOutOfRangeException ();
- if (array.Length - idx size)
+ if (array.Length - idx _size)
throw new ArgumentOutOfRangeException ();
- if (size == 0)
+ if (_size == 0)
return;
- int contents_length = data.Length;
- int length_from_head = contents_length - head;
+ int contents_length = _array.Length;
+ int length_from_head = contents_length - _head;
- Array.Copy (data, head, array, idx, Math.Min (size, length_from_head));
- if (size length_from_head)
-Array.Copy (data, 0, array,
+ Array.Copy (_array, _head, array, idx, Math.Min (_size, length_from_head));
+ if (_size length_from_head)
+Array.Copy (_array, 0, array,
idx + length_from_head,
- size - length_from_head);
+ _size - length_from_head);
}
@@ -130,21 +130,21 @@
if ((uint) idx (uint) array.Length)
throw new ArgumentOutOfRangeException ();
- if (array.Length - idx size)
+ if (array.Length - idx _size)
throw new ArgumentOutOfRangeException ();
- if (size == 0)
+ if (_size == 0)
return;
try {
-int contents_length = data.Length;
-int length_from_head = contents_length - head;
+int contents_length = _array.Length;
+int length_from_head = contents_length - _head;
-Array.Copy (data, head, array, idx, Math.Min (size, length_from_head));
-if (size length_from_head)
- Array.Copy (data, 0, array,
+Array.Copy (_array, _head, array, idx, Math.Min (_size, length_from_head));
+if (_size length_from_head)
+ Array.Copy (_array, 0, array,
idx + length_from_head,
- size - length_from_head);
+ _size - length_from_head);
} catch (ArrayTypeMismatchException) {
throw new ArgumentException ();
}
@@ -155,71 +155,78 @@
T ret = Peek ();
// clear stuff out to make the GC happy
- data [head] = default (T);
+ _array [_head] = default (T);
- if (++head == data.Length)
-head = 0;
- size --;
- version ++;
+ if (++_head == _array.Length)
+_head = 0;
+ _size --;
+ _version ++;
return ret;
}
public T Peek ()
{
- if (size == 0)
+ if (_size == 0)
throw new InvalidOperationException ();
- return data [head];
+ return _array [_head];
}
public void Enqueue (T item)
{
- if (data == null || size == data.Length)
-SetCapacity (Math.Max (size * 2, 4));
+ if (_array == null || _size == _array.Length)
+SetCapacity (Math.Max (_size * 2, 4));
- data [tail] = item;
+ _array [_tail] = item;
- if (++tail == data.Length)
-tail = 0;
+ if (++_tail == _array.Length)
+_tail = 0;
- size ++;
- version ++;
+ _size ++;
+ _version ++;
}
public T [] ToArray ()
{
- T [] t = new T [size];
+ T [] t = new T [_size];
CopyTo (t, 0);
return t;
}
public void TrimExcess ()
{
- if (data != null (size data.Length * 0.9))
-Array.Resize T (ref data, size == 0 ? defaultCapacity : size);
+ if (_array != null (_size _array.Length * 0.9))
+// Aulofee customization - start
+// This 'optimization' could make an application running under Mono behave differently from running .NET.
+// Moreover, it was not increasing the 'version' field, was not changing the head and tail...
+// I replaced
Re: [Mono-dev] A significant number of Mono classes are not (binary) compatible with their .Net equivalents?
Thanks all for the constructive debate. I didn't remember having seen the point in the FAQ in the past, but it's clear anyway. I would add two elements to go forward: - regarding .NET, I may be wrong but the MSDN specifies that 2.0 is backward compatible with 1.x (ie objects binary serialized under 1.1 can be deserialized with 2.0 even if new fields have been added in 2.0). In the opposite direction, MS provides a patch for 1.x to let 1.x use types serialized by 2.0 (you've to ask it to MS support, it's not available on the web directly). - regarding Mono, there are at least some +/- very usefull types concerned by the binary serialization compatibility. For these, may we propose our own versions (through the patch procedure)? They are: DateTime, DataSet (but DataTable is fine), Decimal, DictionaryEntry, DictionaryTK, TV (that one for another reason), QueueT, Stack, StackT, SortedList Finally, even if I fully understand why Mono developpers do not access .Net sources (even through Reflector), the situation is quite regrettable for the difficulties it creates as soon as systems work in a heterogeneous environment (.Net+Windows and Mono+Linux). Does anyone know how Java is for this? Cheers, Lionel -- Lionel Cuir, Associate *Aulofee Supervision Systems (http://www.aulofee.com)* * Security Log correlation * real-time Inventory Detection of software hardware * Reporting * Network Cartography ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 'sizeof' returns different results between .NET and Mono/Linux: a bug?
Happy New Year all!
Porting our software to Mono/Linux, we're facing a strange situation
with pointers on Mono/Linux. I would call it a bug, but before to post
it on bugzilla, I would have liked to have the opportunity to discuss
about it...
My app uses a serialization mechanism based on pointers (and not on
Marshal.Copy, notably for performance reasons). This works well in .NET
but, when sending the byte array over the network and trying to
deserialize it on Mono/Linux, that crashes.
Trying to understand what was wrong, I discovered that a given struct
has not the same size for .NET and for Mono / Linux, even when playing
with the Pack args. That seems very surprising... and I would it a bug
of Mono on Linux. Any advice on this?
To demonstrate it, I just created a simple dummy console application
which basically defines a structure and then does
"Console.Writeline(sizeof(myStruct))" (see code below) . If you run
this
application first in .NET / Windows, then on Mono / Linux, it gives two
different results, respectively 32 bytes for the serialized struct in
.NET/Windows and 48 for Mono / Linux. Once again, I've played with the
Pack args as you can see from the
sample code (I had tried with 0 (system-defined) then with 1), but this
has no impact on the fact I still had different results between .NET
/Windows and Mono / Linux.
Any help appreciated!
Regards,
Lionel Cuir,
Associate
Aulofee Supervision Systems
(http://www.aulofee.com)
* Security Log correlation
* real-time Inventory Detection of software hardware
* Reporting
* Network Cartography
Sample code to demonstrate the problem:
using System;
using System.Runtime.InteropServices;
namespace ConsoleApplication1
{
class Program
{
unsafe static void Main(string[] args)
{
Console.WriteLine(sizeof(InternalStructSvcMsg));
Console.ReadLine();
}
}
[StructLayout(LayoutKind.Sequential, Pack = 0)]
struct InternalStructSvcMsg
{
public int CallerID;
public DateTime DateOfCreation;
public int From;
public int FromFunctionID;
public int To;
public int ToFunctionID;
public bool ToKeep;
public InternalStructSvcMsg(int i)
{
CallerID = i;
DateOfCreation = DateTime.MinValue;
From = 0;
FromFunctionID = 0;
To = 0;
ToFunctionID = 0;
ToKeep = true;
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
