Re: [Mono-dev] XSP Problem : System.Exception: Error reading headers.
Ok, most of problems seems to be solved thanks to Miguel BUT when i've seen the changelog : * image.c (full_path): A new method used to obtain the actual path of an assembly even in the presence of symbolic links. This is necessary for the case where we are running a binary that has been GACed, but we are using the published path name ($prefix/mono/1.0/blah.exe) which happens to point to the real file in the GAC. This was the source of the failure for the `xsp' command with the recent AppDomain changes, as far as the runtime was concerned, there were two different assemblies: $prefix/mono/1.0/blah.exe and $prefix/mono/gac/blah/version/blah.exe. and this cause many problems with my applications... Because many of them use the same libraries and I use symbolic links in the /bin directory to share them... I don't want to use the Gac because many of them are not strong signed! Now i've this error when I launch my application : Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error. Error message: (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.Shared.v6.1.dll' (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll' In fact there's a symbolic link /home/hubert/applications/IntranetAdmin/bin/Infragistics.WebUI.Shared.v6.1.dll that point to /home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll !!! It used to work well... Symbolic link are an important feature of UNIX Le jeudi 17 aot 2006 11:04 -0500, Brian Crowell a crit : Robert Jordan wrote: This is related to this bugfix: http://bugzilla.ximian.com/show_bug.cgi?id=76757 http://bugzilla.ximian.com/showattachment.cgi?attach_id=17200 You guys might want to look at the part of this patch that applies to the class libraries, as I found some really silly things going on in there. --Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Problem with ASP.NET Symbolic link
Ok, most of problems seems to be solved thanks to Miguel BUT when i've seen the changelog : * image.c (full_path): A new method used to obtain the actual path of an assembly even in the presence of symbolic links. This is necessary for the case where we are running a binary that has been GACed, but we are using the published path name ($prefix/mono/1.0/blah.exe) which happens to point to the real file in the GAC. This was the source of the failure for the `xsp' command with the recent AppDomain changes, as far as the runtime was concerned, there were two different assemblies: $prefix/mono/1.0/blah.exe and $prefix/mono/gac/blah/version/blah.exe. and this cause many problems with my applications... Because many of them use the same libraries and I use symbolic links in the /bin directory to share them... I don't want to use the Gac because many of them are not strong signed! Now i've this error when I launch my application : Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error. Error message: (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.Shared.v6.1.dll' (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll' In fact there's a symbolic link /home/hubert/applications/IntranetAdmin/bin/Infragistics.WebUI.Shared.v6.1.dll that point to /home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll !!! It used to work well... Symbolic link are an important feature of UNIX Or tell me what other way to deal with shared dll... ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] local file based EventLog implementation
That would be great, but we still need to wait for approval from Miguel first. You can make sure that nothing will be approved until 1.1.17 is released so you don't have to hurry. And it's much easier to get approval for a properly working, complete patch than a partial one. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] local file based EventLog implementation
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Kornél Pál Sent: vrijdag 18 augustus 2006 10:45 To: Gert Driesen Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] local file based EventLog implementation That would be great, but we still need to wait for approval from Miguel first. You can make sure that nothing will be approved until 1.1.17 is released so you don't have to hurry. And it's much easier to get approval for a properly working, complete patch than a partial one. I'm not requesting commit approval for the patch, I'm waiting for approval on the design so I can continue working on it. Both the win32 and local file implementation are complete (and fully covered by unit tests) except for the message resource stuff. But that is not critical as it only affects reading of eventlog entries, not writing. Meaning, we will not break any of the eventlog messages that are written by improving support for reading them. Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Random CIL generator
Can anyone point me to a random CIL generator? As far as I can tell from Google, no one has written one yet. I ask because I don't want to go around considering how to write one if one already exists. It would be useful to do testing on CIL-based tools as described at http://testingsoftware.blogspot.com/2005/10/testing-for-zero-bugs_31.html Regards Bjarke Roune ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Problem with call of stored procedure in Oracle
Hello. Something strange happens with types when calling stored procedure in Oracle. Procedure looks like: createorreplaceproceduretest_int(p1innumber, p2outnumber)is begin p2 := p1; endtest_int; Putting trace option on we can see that mono oracle client passes parameter of wrong type: bind 0: dty=1 (varchar2) value="1000" bind 1: dty=96 (char) The same code in .net works well. (Types aredty=2 (number).) This strange behavior cause problems with value of out parameter. According to class status ofSystem.Data.OracleClientnamespace it should be rather stable, but it doesn't seem to be so. (There are also problems with Blobs, etc.) Are any ongoing improvements of it? -- Thanks, Sergey ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] XSP/mod_mono installation
RedHat Enterprise 4 i686 Installed: mono-core mono-data mono-web xsp mod_mono When trying to load mod_mono.so in httpd.conf i get error pachectl configtest restart Syntax error on line 228 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/lib/httpd/modules/mod_mono.so into server: /usr/lib/httpd/modules/mod_mono.so: undefined symbol: apr_pool_cleanup_null /usr/sbin/httpd restart: configuration broken, ignoring restart ldd -d mod_mono.so undefined symbol: apr_pool_cleanup_null (./mod_mono.so) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x003db000) libc.so.6 = /lib/tls/libc.so.6 (0x00111000) /lib/ld-linux.so.2 (0x00939000) rpm -aq | grep httpd httpd-2.0.52-22.ent rpm -aq | grep mono mono-core-1.1.16.1-0.novell mono-web-1.1.16.1-0.novell mod_mono-1.1.16.1-0.rhel4.novell mono-data-1.1.16.1-0.novell rpm -aq | grep xsp xsp-1.1.16.1-0.novell Installation is made from rpm-s http://www.go-mono.com/download-latest/rhel-4-i386/ How to get it work ? Regards Sven ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Random CIL generator
Hello Bjarke, On Fri, 2006-08-18 at 11:48 +0200, Bjarke Hammersholt Roune wrote: Can anyone point me to a random CIL generator? As far as I can tell from Google, no one has written one yet. I had never seen one, but it would be a very useful tool to test the runtime. Another variation would be a tool that modify a few bits of an existing (known to be valid, signed or not) assembly and see how the runtimes* reacts to this changes. * not just mono ;-) I ask because I don't want to go around considering how to write one if one already exists. That would be a nice contribution to Mono! It would be useful to do testing on CIL-based tools as described at http://testingsoftware.blogspot.com/2005/10/testing-for-zero-bugs_31.html Regards Bjarke Roune ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Building Mono from Source
Hi All, I had previously written about a problem compiling Mono from source on Gentoo. I didn't get any responses, but I did come across the following posting: http://lists.ximian.com/pipermail/mono-devel-list/2005-November/015886.html which said to go into the libgc directory and run autogen. I did, but I got the message: configure: error: This module is now part of `mono' and can't be built as a stand-alone module any longer. I tried running autogen back on the mono directory again anyway, and it didn't change anything, so I'm hoping someone else has some insight into what the next steps would be. Thanks! -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] local file based EventLog implementation
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Gert Driesen Sent: vrijdag 18 augustus 2006 11:26 To: 'Kornél Pál' Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] local file based EventLog implementation -Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Kornél Pál Sent: vrijdag 18 augustus 2006 10:45 To: Gert Driesen Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] local file based EventLog implementation That would be great, but we still need to wait for approval from Miguel first. You can make sure that nothing will be approved until 1.1.17 is released so you don't have to hurry. And it's much easier to get approval for a properly working, complete patch than a partial one. I'm not requesting commit approval for the patch, I'm waiting for approval on the design so I can continue working on it. Both the win32 and local file implementation are complete (and fully covered by unit tests) except for the message resource stuff. But that is not critical as it only affects reading of eventlog entries, not writing. Meaning, we will not break any of the eventlog messages that are written by improving support for reading them. Reading eventlog entries on win32 with message resource support is now also done, making the win32 implementation feature complete. Now, all we need is approval from Miguel for: a) continueing to work on it (mostly for the unix message resource stuff) b) adding EventLogMessages.dll to the binary distributions (for win32, and linux too) If we do not get approval for (b) (not sure why, but could be ofcourse), then we could still embed the dll into the System assembly and extract it at runtime (if it doesn't exist yet). But I'd rather avoid this. In what form should EventLogMessage.dll added to svn (and the source distributions) ? Can we juist include it as is, or do we need to build it at compile time ? Gert ___ 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 from Source
Hi, This should be fixed in SVN. In the meantime, try deleting libgc/libtool.m4 and rerunning autogen.sh. Zoltan On 8/18/06, Cory Foy [EMAIL PROTECTED] wrote: Hi All, I had previously written about a problem compiling Mono from source on Gentoo. I didn't get any responses, but I did come across the following posting: http://lists.ximian.com/pipermail/mono-devel-list/2005-November/015886.html which said to go into the libgc directory and run autogen. I did, but I got the message: configure: error: This module is now part of `mono' and can't be built as a stand-alone module any longer. I tried running autogen back on the mono directory again anyway, and it didn't change anything, so I'm hoping someone else has some insight into what the next steps would be. Thanks! -- Cory Foy http://www.cornetdesign.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] Embedded Mono/Program freezes
Hey, Why do I have to deduce from other of your posts what you're trying to do? :-) Please try to be more detailed. I understand you have a server app which embeds mono (under Windows) and which sometimes acts as a *WebService client*. At least I can deduce this from the trace and from your previous mails. Now to the bug: Web servers usually deny more then 2 open connections from a specific client. Since your server acts on behalf of its clients, you're probably somehow reaching the limit. Robert Janne Rantala wrote: Hi everyone! We have client-server application where Mono is embedded on server side, and the idea is that clients can create and run Mono programs there. Any calls from unmanaged code to managed is handled with mono_runtime_exec_managed_code, and before that mono_thread_attach() is called. I've run simple web service for testing purposes and everything works fine at first run, but when I try to run same program, it just freezes. It doesn't matter if I run it second time from same client or completely different. Some debug messages from assembly is printed but when web service is supposed to start nothing happens. At the end of this mail is last of the verbose messages I got out. And if I remove that web service call, both clients work ok. They don't do much but still everything that is supposed to. Is this web service issue or something else? Help is much appreciated! Cheers, Janne Method System.Net.ServicePoint:get_AvailableForRecycling () emitted at 06325ED0 to 06325FB2 (code length 226) [WSTest.exe] Method System.Net.ServicePoint:get_CurrentConnections () emitted at 06325FB8 to 06326004 (code length 76) [WSTest.exe] Method System.Net.ServicePoint:get_IdleSince () emitted at 06326008 to 0632608E (code length 134) [WSTest.exe] Method System.DateTime:AddMilliseconds (double) emitted at 06326090 to 06326197 (code length 263) [WSTest.exe] Method System.WeakReference:get_Target () emitted at 06326198 to 063261AF (code length 23) [WSTest.exe] Method System.Runtime.InteropServices.GCHandle:get_Target () emitted at 063261C0 to 063261D0 (code length 16) [WSTest.exe] Method (wrapper managed-to-native) System.Runtime.InteropServices.GCHandle:GetTa rget (int) emitted at 063261E8 to 0632623E (code length 86) [WSTest.exe] Method System.Net.WebConnection:get_Busy () emitted at 06326240 to 06326299 (cod e length 89) [ WSTest.exe] Method System.Net.Sockets.Socket:get_Connected () emitted at 063262A0 to 063262A C (code length 12) [WSTest.exe] Method System.Net.WebConnection:CanReuse () emitted at 063262B0 to 063262E6 (cod e length 54) [ WSTest.exe] Method System.Net.Sockets.Socket:Poll (int,System.Net.Sockets.SelectMode) emitte d at 063262F8 to 063263F8 (code length 256) [WSTest.exe] Method (wrapper managed-to-native) System.Net.Sockets.Socket:Poll_internal (intp tr,System.Net.Sockets.SelectMode,int,int) emitted at 06326410 to 0632647E (code length 110) [WSTest.exe] Method System.Net.WebConnection:CompleteChunkedRead () emitted at 06326480 to 06 32650A (code length 138) [ WSTest.exe] Method System.Version:op_LessThan (System.Version,System.Version) emitted at 063 26520 to 06326545 (code length 37) [WSTest.exe] Method System.Version:CompareTo (System.Version) emitted at 06326548 to 06326602 (code length 186) [WSTest.exe] Method SocketAsyncResult:get_AsyncWaitHandle () emitted at 06326608 to 06326678 (code length 112) [WSTest.exe] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Where clause on generic delegates
Please file a bug report.
Thanks,
On 8/17/06, Michał Ziemski [EMAIL PROTECTED] wrote:
Hi!
GMCS crashes when a where clause is used on a generic delegate.
I am using
Mono C# compiler version 1.1.16.1 on FC4
Should I file a bug for this one?
I would be grateful for assistance as this hinders my work :(
Compiling
public interface IReplaceableT
{
bool Valid { get; }
}
public class NalBase
{
private delegate void AddAlgStrDelegateT(T als)
where T : IReplaceableT;
}
Crashes with:
Unhandled Exception: System.ArgumentNullException: null key
Parameter name: key
at System.Collections.Hashtable.get_Item (System.Object key) [0x0]
at Mono.CSharp.AttributeTester.GetObsoleteAttribute (System.Type type)
[0x0]
at Mono.CSharp.Expression.ResolveAsTypeTerminal (IResolveContext ec,
Boolean silent) [0x0]
at Mono.CSharp.TypeArguments.Resolve (IResolveContext ec) [0x0]
at Mono.CSharp.ConstructedType.DoResolveType (IResolveContext ec)
[0x0]
at Mono.CSharp.ConstructedType.ResolveConstructedType (IResolveContext
ec) [0x0]
at Mono.CSharp.ConstructedType.DoResolveAsTypeStep (IResolveContext
ec) [0x0]
at Mono.CSharp.TypeExpr.ResolveAsTypeStep (IResolveContext ec, Boolean
silent) [0x0]
at Mono.CSharp.SimpleName.ResolveAsTypeStep (IResolveContext ec,
Boolean silent) [0x0]
at Mono.CSharp.Constraints.Resolve (IResolveContext ec) [0x0]
at Mono.CSharp.TypeParameter.Resolve (Mono.CSharp.DeclSpace ds) [0x0]
at Mono.CSharp.Delegate.DefineType () [0x0]
at Mono.CSharp.TypeContainer.DefineNestedTypes () [0x0]
at Mono.CSharp.TypeContainer.DefineType () [0x0]
at Mono.CSharp.Class.DefineType () [0x0]
at Mono.CSharp.RootContext.ResolveTree () [0x0]
at Mono.CSharp.Driver.MainDriver (System.String[] args) [0x0]
at Mono.CSharp.Driver.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
--
Rafael Monoman Teixeira
---
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. George Bernard Shaw
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ComponentDesigner implementation patch
Fantastic job, Ivan. I hope you get quick approval for commit. On 8/17/06, Ivan N. Zlatev [EMAIL PROTECTED] wrote: Hello! The attached ComponentDesigner.patch.tar.gz is a complete implementation of the 1.1 and 2.0 System.ComponentModel.Design.ComponentDesigner. I have successfully hosted components which use this implementation for their designer in Visual Studio.Net 2005. I am also reposting a few trivial patches all in the System.ComponentModel.* namespaces: * DesignerTransactionCloseEventArgs.diff, SelectionTypes_net_2_0.diff, ViewTechnology_Update.diff, ServiceContainer.diff. - update a few signatures and enums to .Net 2.0 * Container_and_Test.diff - Fixes incorrect behaviour, updates to .Net 2.0. Includes a test case. Please someone review these patches and apply them. P.S: I've posted on this list earlier this summer that I am working on some of the Design-Time stuff (System.ComponentModel(.Design.*)). I have completed the DesignSurface (http://msdn2.microsoft.com/en-us/library/system.componentmodel.design.designsurface.aspx) implementation and managed to load MS's WinForm designers in my own host. I am doing extensive testing - hosting MS's designers in my host, hosting my designers in their host, etc. I am hoping to get back to you soon with an extremly basic winforms designer :) ... and may be one day have a very cut-down version of SD running... ;) Cheers, -- Ivan N. Zlatev Web: http://www.i-nZ.net GPG Key: http://files.i-nZ.net/i-nZ.asc It's all some kind of whacked out conspiracy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with ASP.NET Symbolic link
The bug is reported with a simple test case (easy to reproduce) http://bugzilla.ximian.com/show_bug.cgi?id=79103 Le vendredi 18 aot 2006 10:24 +0200, Hubert FONGARNAND a crit : Ok, most of problems seems to be solved thanks to Miguel BUT when i've seen the changelog : * image.c (full_path): A new method used to obtain the actual path of an assembly even in the presence of symbolic links. This is necessary for the case where we are running a binary that has been GACed, but we are using the published path name ($prefix/mono/1.0/blah.exe) which happens to point to the real file in the GAC. This was the source of the failure for the `xsp' command with the recent AppDomain changes, as far as the runtime was concerned, there were two different assemblies: $prefix/mono/1.0/blah.exe and $prefix/mono/gac/blah/version/blah.exe. and this cause many problems with my applications... Because many of them use the same libraries and I use symbolic links in the /bin directory to share them... I don't want to use the Gac because many of them are not strong signed! Now i've this error when I launch my application : Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error. Error message: (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.Shared.v6.1.dll' (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll' In fact there's a symbolic link /home/hubert/applications/IntranetAdmin/bin/Infragistics.WebUI.Shared.v6.1.dll that point to /home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll !!! It used to work well... Symbolic link are an important feature of UNIX Or tell me what other way to deal with shared dll... ___ Ce message et les ventuels documents joints peuvent contenir des informations confidentielles. Au cas o il ne vous serait pas destin, nous vous remercions de bien vouloir le supprimer et en aviser immbdiatement l'expditeur. Toute utilisation de ce message non conforme m sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'tant pas stcurises, l'intdgrit de ce message n'est pas assur1e et la socitn mettrice ne peut ;tre tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] local file based EventLog implementation
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Robert Jordan Sent: vrijdag 18 augustus 2006 16:19 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] local file based EventLog implementation Gert Driesen wrote: b) adding EventLogMessages.dll to the binary distributions (for win32, and linux too) If we do not get approval for (b) (not sure why, but could be ofcourse), then we could still embed the dll into the System assembly and extract it at runtime (if it doesn't exist yet). But I'd rather avoid this. The Debian folks usually don't accept binaries. I wish you good luck to explain them the difference between a managed DLL, an unmanaged DLL and an unmanaged DLL consisting of just one PE resource :-) I think it would indeed be better to either build it at compile time, or if is too difficult to achieve (especially on linux) that we can always embed it. Or as a (very) last resort, do not register one for event sources created from Mono. In what form should EventLogMessage.dll added to svn (and the source distributions) ? Can we juist include it as is, or do we need to build it at compile time ? Please excuse my ignorance, but why on earth do we need EventLogMessage.dll with its PE resources under Unix? It's definitely not needed, but Kornél proposed to use it on unix too. IT would be nice to have, but not necessary. On Windows, I think we should definitely use it. But there it's also not strictly necessary (but more than one unix). I understand why it's needed for Win32 and even why Win32 demands it (performance and log file size optimization), but since MS.NET installs EventLogMessage.dll, no one will ever use resource DLLs with .NET, IMO. No one wants to deal with MC and RC just for eventlogging's sake. In .NET 2.0, MS provided better support for using message resource dll's, so I'm pretty sure its usage will pick up. Reading event entries created by event sources that use a message resource has already been implemented (for the win32 implementation). Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] How to use GTK Theme Selector on Windows
Legal Notice | intervate.com | +27 11 236-3860 Hi, What is the process to install new GTK Themes on Windows? Regards, Jacques du Preez Software Developer This e-mail is subject to our legal notice, to view click here. ___ 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
matt westerburg wrote: I am new to Mono, but not C#. I have installed mono a couple of times and messed around with it on a few distros. But I have never gotten the System.Net library. I am just inquiring to whether there is a working version of the class library? There is no library with this name. The *namespace* System.Net is implemented in the System assembly. Robert ___ 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
Please reply on the list. matt westerburg wrote: So if I had code that utilized System.Net and I just leave it with using System; Would it be compatible or would methods and classes be different? Like in MS.NET, System.Net is a namespace which happens to be implemented in the System assembly. With using you're importing namespaces and not assemblies. Assemblies are referenced using compiler options: mcs -r:System.dll or mcs -pkg:dotnet ... The latter references the same assemblies as csc does. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XSP Problem : System.Exception: Error reading headers.
On Fri, 2006-08-18 at 10:21 +0200, Hubert FONGARNAND wrote: Ok, most of problems seems to be solved thanks to Miguel [...] Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error. Error message: (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.Shared.v6.1.dll' (0,0) : error CS0006: Cannot find assembly `/home/hubert/applications/IntranetAdmin/bin/home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll' In fact there's a symbolic link /home/hubert/applications/IntranetAdmin/bin/Infragistics.WebUI.Shared.v6.1.dll that point to /home/hubert/applications/Librairies/Infragistics.WebUI.UltraWebNavigator.v6.1.dll !!! This is now fixed in svn. Well, it's more of a workaround for the weekend, as on Monday we'll do the real fix. Thanks for testing. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XSP/mod_mono installation
On Fri, 2006-08-18 at 13:44 +0300, Sven wrote: RedHat Enterprise 4 i686 Installed: mono-core mono-data mono-web xsp mod_mono When trying to load mod_mono.so in httpd.conf i get error pachectl configtest restart Syntax error on line 228 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/lib/httpd/modules/mod_mono.so into server: /usr/lib/httpd/modules/mod_mono.so: undefined symbol: apr_pool_cleanup_null /usr/sbin/httpd restart: configuration broken, ignoring restart ldd -d mod_mono.so undefined symbol: apr_pool_cleanup_null (./mod_mono.so) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x003db000) libc.so.6 = /lib/tls/libc.so.6 (0x00111000) /lib/ld-linux.so.2 (0x00939000) rpm -aq | grep httpd httpd-2.0.52-22.ent [...] You probably need a newer libapr. Or if you feel like doing it, add a test for that function in configure.in and an implementation to mod_mono.c in case it does not exist. I'd appreciate the patch. -Gonzalo ___ 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 from Source
Zoltan Varga wrote: This should be fixed in SVN. In the meantime, try deleting libgc/libtool.m4 and rerunning autogen.sh. Aha! Yep, that fixed it exactly. Thanks! -- Cory Foy http://www.cornetdesign.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedded Mono/Program freezes
Hi! 2006/8/18, Robert Jordan [EMAIL PROTECTED]: Hey, Why do I have to deduce from other of your posts what you're trying to do? :-) Please try to be more detailed. Sorry about that, you did fine job crawling those posts though :) I understand you have a server app which embeds mono (under Windows) and which sometimes acts as a *WebService client*. At least I can deduce this from the trace and from your previous mails. That is correct. That's also almost the same text I wrote in my previous post :) Now to the bug: Web servers usually deny more then 2 open connections from a specific client. Since your server acts on behalf of its clients, you're probably somehow reaching the limit. After reading your reply I thought that this must have been the reason. So I set up a web server to my machine and tried accessing one service from there. First went ok, but second attempt gave The request timed out message. First and successful attempt was logged in web server but there was no trace of the second one. I think that the reason I thought that program froze earlier was because I tried accessing public server and it just kept waiting so long. But it definitely looks like Mono is trying to do something but fails? Robert Janne ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedded Mono/Program freezes
Hi, Janne Rantala wrote: Now to the bug: Web servers usually deny more then 2 open connections from a specific client. Since your server acts on behalf of its clients, you're probably somehow reaching the limit. After reading your reply I thought that this must have been the reason. So I set up a web server to my machine and tried accessing one service from there. First went ok, but second attempt gave The request timed out message. First and successful attempt was logged in web server but there was no trace of the second one. I think that the reason I thought that program froze earlier was because I tried accessing public server and it just kept waiting so long. But it definitely looks like Mono is trying to do something but fails? Indeed, the parallel connections are probably not (yet) the problem. You wrote that you're using mono_runtime_exec_managed_code (). If I understand the code correctly, the function will shutdown the runtime after the callback terminates. That's probably not what you expect, isn't it? Try mono_thread_attach () instead of *_exec_managed_code (). Note that runtime must reside in a DLL, otherwise mono_thread_attach () would fail under Windows. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
