Re: [Mono-list] ASP.NET from CVS very difficult to use

2004-04-09 Thread Jaroslaw Kowalski
Thanks Lluis. It worked.

Jarek
- Original Message - 
From: Lluis Sanchez [EMAIL PROTECTED]
To: Jaroslaw Kowalski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, April 08, 2004 10:16 PM
Subject: Re: [Mono-list] ASP.NET from CVS very difficult to use


 Hi,

 Make sure you mscorlib is up to date (mcs CVS module). I commited a fix
 for this yesterday.

 Lluis.

 On dj, 2004-04-08 at 21:42, Jaroslaw Kowalski wrote:
  I'm getting an error every time I update one of the source files in my
  ASP.NET application. The error seems to be related to the
FileSystemWatcher.
  This makes developing with mod_mono very difficult since I have to
restart
  mod-mono-server.exe every time.
 
  My config:
 
  Fedora Core 1/athlon
  httpd-2.0.48-1.2
  mod_mono - installed from CVS today
  mono - installed from CVS today:
 
  Mono JIT compiler version 0.31.99, (C) 2002-2004 Novell, Inc and
  Contributors. www.go-mono.com
  TLS:   NPTL
  GC:Included Boehm (with typed GC)
  SIGSEGV  : altstack
  Globalization: none
 
  Is this a bug or my mis-configuration?
  Error message follows.
 
  Jarek
 
  Unhandled Exception: System.Reflection.TargetInvocationException:
Exception
  has been thrown by the target of an invocation. ---
  System.ApplicationException: Timeout expited
  in 0x000ac System.Threading.ReaderWriterLock:AcquireReaderLock
(int,int)
  in 0x00016 System.Threading.ReaderWriterLock:AcquireReaderLock (int)
  in 0x0001d System.Web.Caching.CacheEntry:TestFlag
  (System.Web.Caching.CacheEntry/Flags)
  in 0x00034 System.Web.Caching.CacheEntry:Close
  (System.Web.Caching.CacheItemRemovedReason)
  in 0x00467 System.Web.Caching.Cache:UpdateCache
 
(string,System.Web.Caching.CacheEntry,bool,System.Web.Caching.CacheItemRemov
  edReason)
  in 0x00035 System.Web.Caching.Cache:Remove
  (string,System.Web.Caching.CacheItemRemovedReason)
  in 0x0001f System.Web.Caching.CacheEntry:OnChanged
  (object,System.Web.Caching.CacheDependencyChangedArgs)
  in 0x0005a (wrapper delegate-invoke)
  System.MulticastDelegate:invoke_void_object_CacheDependencyChangedArgs
  (object,System.Web.Caching.CacheDependencyChangedArgs)
  in 0x00081 System.Web.Caching.CacheDependency:OnChanged
  (object,System.EventArgs)
  in 0x00014 System.Web.Caching.CacheDependency:OnFileChanged
  (object,System.IO.FileSystemEventArgs)
  in (unmanaged) /opt/mono/lib/libmono.so.0 [0x3b6c3f]
  in (unmanaged) /opt/mono/lib/libmono.so.0(mono_runtime_invoke+0x23)
  [0x3f467b]
  in (unmanaged)
/opt/mono/lib/libmono.so.0(mono_runtime_invoke_array+0x11d)
  [0x3f5399]
  in (unmanaged) /opt/mono/lib/libmono.so.0 [0x3fb5b8]
  in 0x00098 System.Reflection.MonoMethod:Invoke
 
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],Sys
  tem.Globalization.CultureInfo)
  --- End of inner exception stack trace ---
 
  in 0x000ff System.Reflection.MonoMethod:Invoke
 
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],Sys
  tem.Globalization.CultureInfo)
  in 0x00021 System.Reflection.MethodBase:Invoke (object,object[])
  in 0x000cc System.Delegate:DynamicInvokeImpl (object[])
  in 0x00048 System.MulticastDelegate:DynamicInvokeImpl (object[])
  in 0xf System.Delegate:DynamicInvoke (object[])
  in 0x0008b System.IO.FileSystemWatcher:RaiseEvent
  (System.Delegate,System.EventArgs)
  in 0x00069 (wrapper remoting-invoke-with-check)
  System.IO.FileSystemWatcher:RaiseEvent
(System.Delegate,System.EventArgs)
  in 0x00017 System.IO.FileSystemWatcher:OnChanged
  (System.IO.FileSystemEventArgs)
  in 0x00056 (wrapper remoting-invoke-with-check)
  System.IO.FileSystemWatcher:OnChanged (System.IO.FileSystemEventArgs)
  in 0x00193 System.IO.FileSystemWatcher:DispatchEvents
  (System.IO.FileAction,string,System.IO.RenamedEventArgs)
  in 0x00077 (wrapper remoting-invoke-with-check)
  System.IO.FileSystemWatcher:DispatchEvents
  (System.IO.FileAction,string,System.IO.RenamedEventArgs)
  in 0x00047 System.IO.DefaultWatcher:DispatchEvents
  (System.IO.FileSystemWatcher,System.IO.FileAction,string)
  in 0x009ef System.IO.DefaultWatcher:DoFiles
  (System.IO.DefaultWatcherData,string,string,bool)
  in 0x00114 System.IO.DefaultWatcher:UpdateDataAndDispatch
  (System.IO.DefaultWatcherData,bool)
  in 0x00122 System.IO.DefaultWatcher:Monitor ()
  in 0x00044 (wrapper delegate-invoke)
System.MulticastDelegate:invoke_void
  ()
 
 
  ___
  Mono-list maillist  -  [EMAIL PROTECTED]
  http://lists.ximian.com/mailman/listinfo/mono-list

 ___
 Mono-list maillist  -  [EMAIL PROTECTED]
 http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] xsp Web Service support

2004-04-09 Thread Lluis Sanchez
On dv, 2004-04-09 at 01:51, Chris List Recipient wrote:
 Does xsp support web services? 

Yes.

 I am running xsp 0.9 and I get back an
 error indicating the asmx file is not found:
 
 Not Found
 The requested URL /ConfigFiles.asmx was not found on this server. 

If the file is there (with that exact case) and the web service is fully
implemented in the asmx file or in a class compiled in an assembly
located in the bin directory, this must work. If all of this is true and
still doesn't work, please file a bug report in bugzilla wiht a small
test case.

Lluis.

 
 aspx and html files serve up fine.
 
 -Chris
 ___
 Mono-list maillist  -  [EMAIL PROTECTED]
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [DotGNU]Re: [Mono-list] I give up

2004-04-09 Thread Norbert Bollow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joop [EMAIL PROTECTED] wrote:

 Hi lists, (hope this does not get mis-understood... I'm not subscribed 
 to any of the non-mono-lists :-( although I maybe should be)
 this problem I have seen with Mono and the other .NET implementations is 
 just the problem the original poster poses. There is not real 
 commitment to/clear road-a-head for/direction in supporting the GUI 
 side of things.

A quick correction here.  The DotGNU project definately has a clear
real commitment to/clear road-a-head for/direction in supporting
the GUI side of things.  Our focus in this area is on the DotGNU
Portable.NET System.Windows.Forms (WinForms) implementation.

I'm in contact with an industry sponsor who is going to fund the
necessary development work for allowing them to run their GUI stuff on
DotGNU.

(I do think that having Qt / KDE bindings from C# is very important too
for strategic reasons.  Hence, even though we don't currently have the
manpower to work on this, I want to strongly encourage all efforts in
this direction, be it by helping marcusU on Qt# or by independant
efforts.)

Greetings, Norbert.

- -- 
Founder  Steering Committee member of DotGNU, see http://dotgnu.org/
Free Software Business Strategy Guide   ---  http://FreeStrategy.info
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59Fax +41 1 972 20 69   http://norbert.ch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAdnaMoYIVvXUl7DIRAhacAJ9fE5lfsTxWbQ9mCBRZLPpaMx+TMgCfevLP
Bw5pyouSFS3iDCZBwLb5bnE=
=fOs7
-END PGP SIGNATURE-
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] I give up

2004-04-09 Thread Joseph Bennie
 Remember to the rest of us who are just looking
to be productive, we don't want to have to learn new tricks if we 
don't have to
With kindness
Well, I have to say that this is possibly why there are so many poor
windows applications that just don't understand the whole concept of
multi-user.  WordPerfect used to get it right, MS-Office didn't, 
neither
did Mavis Beacon and an entire range of software developed for Windows.
It is getting better but any time any company developed for multiple
platforms and included Unix usually had a clue.  Please DO take the 
time
to learn new tricks.


jokingly
do you want slapped.
Platforms don't make bad programmers, bad programmers make bad 
applications.
;)

--
George Farris [EMAIL PROTECTED]
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


RE: Re: [Mono-list] I give up / Mac OS X PPC support

2004-04-09 Thread Robert Isaacs

-Original Message-
From: Steve Mentzer [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 09, 2004 1:07 AM
To: [EMAIL PROTECTED]
Subject: RE: Re: [Mono-list] I give up / Mac OS X PPC support


snip

On x86 hardware, I prefer windows xp/2003. Sorry, I love *nix, but linux
doesn't do much for me on x86, especially when x86/windows offers 100%
compatibility and killer dev tools. Frankly, there is no real reason to
host asp.net apps under apache, when my XP box does better after locking
it down. No religion here folks, just reality.

snip


Hi Steve,

I just wanted to mention that saving many thousands of dollars is a
real reason for many of us.

No religion.  Just reality.

Robert
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


[Mono-list] System.Data.OracleClient - RAW support

2004-04-09 Thread eda
Hi,

I added support for basic RAW data type in System.Data.OracleClient library.
If is someone responsible for this library please add attached patch to
CVS tree.
Copy this patch to mcs directory and type:

patch p1  Systen.Data.OracleClinet-raw_support.diff

Eduard

--- mcs/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDefineHandle.cs 
 Sat Apr  3 17:19:03 2004
+++ 
mcs-my/class/System.Data.OracleClient/System.Data.OracleClient.Oci/OciDefineHandle.cs  
 Thu Apr  8 11:38:14 2004
@@ -110,6 +110,9 @@
definedSize = -1;
DefineLob (position, definedType);
return;
+case OciDataType.Raw:
+DefineRaw( position);
+return;
default:
DefineChar (position); // HANDLE ALL OTHERS AS CHAR 
FOR NOW
return;
@@ -205,6 +208,32 @@
}
}
 
+void DefineRaw( int position)
+{
+   ociType = OciDataType.Raw;
+   
+   value = Marshal.AllocHGlobal (definedSize);
+
+   int status = 0;
+
+   status = OciCalls.OCIDefineByPos (Parent,
+   out handle,
+   ErrorHandle,
+   position + 1,
+   value,
+   definedSize * 2,
+   ociType,
+   ref indicator,
+   ref rlenp,
+   IntPtr.Zero,
+   0);
+
+   if (status != 0) {
+   OciErrorInfo info = ErrorHandle.HandleError ();
+   throw new OracleException (info.ErrorCode, 
info.ErrorMessage);
+   }
+}
+
protected override void Dispose (bool disposing) 
{
if (!disposed) {
@@ -259,6 +288,12 @@
break;
case OciDataType.Date:
return UnpackDate ();
+case OciDataType.Raw:
+byte[] raw_buffer = new byte [Size];
+
+Marshal.Copy (Value, raw_buffer, 0, Size);
+
+return raw_buffer;
}
 
return DBNull.Value;



RE: [Mono-list] Mono trust stire location

2004-04-09 Thread Sunil Kumar
Is there any API's available in mono to Read the trust root certificates
from a Trusted root store created using certmgr?


Sunil.

 Sebastien Pouliot [EMAIL PROTECTED] 4/8/2004 3:42:07 PM 
Sunil,

Is it possible that we can speicfy the location where we want to
 create the trust store.

Maybe ;-) It's all depend on *why* the location needs to be specified,
like:

- changing the directory name isn't hard (e.g. ~/.mono/certificates/...
or
something more fd.org-friendly);
- having a different directory structure per user requires to add
configuration files (and tools/documentation/...) but makes it harder
to
change the implementation later. For example a later Mono release could
use
an implementation not based on a file system (a database, a directory,
a
smartcard ...).

Problem is that if/when application depends on a specific directory
then we
have conflict problems. That's why I said it's better to use certmgr to
do
the job.

Note that the same pattern holds true for key pairs and the GAC - you
shouldn't depend on their location but use the supplied tools to
manipulate
them.

In this case (trusted certificates being used for SSL/TLS) it's also
possible to add application specific code (in the validation callback)
to
check for untrusted certificates and then search another (application
specific) location for roots (but that would be in addition to the
existing
roots).

Sebastien Pouliot
http://pages.infinit.net/ctech/poupou.html 

-Original Message-
From: Sunil Kumar [mailto:[EMAIL PROTECTED] 
Sent: 8 avril 2004 16:57
To: [EMAIL PROTECTED]; [EMAIL PROTECTED] 
Subject: RE: [Mono-list] Mono trust stire location


Hi Sebastie,
Is it possible that we can speicfy the location where we want to
create the trust store.

SUnil.

 Sebastien Pouliot [EMAIL PROTECTED] 4/8/2004 2:50:22 PM 
Hello Sunil,

All user certificate stores are located under
~/.mono/certs/

The trusted store is
~/.mono/certs/Trust/

But this could change between release, so it's better to use certmgr
to
add/remove certificates.

Sebastien Pouliot
http://pages.infinit.net/ctech/poupou.html 


-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] Behalf Of Sunil Kumar
Sent: 8 avril 2004 16:42
To: [EMAIL PROTECTED] 
Subject: [Mono-list] Mono trust stire location


Hi ,
   Does anyone Knows the location of the mono trust store? i.e when I
add a certificate using   certmgr add -c Trust
TrustRootCertificate
where does my TrustRootCertificate gets added.

Regards,
Sunil.
___
Mono-list maillist  -  [EMAIL PROTECTED] 
http://lists.ximian.com/mailman/listinfo/mono-list 

___
Mono-list maillist  -  [EMAIL PROTECTED] 
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] I give up / Mac OS X PPC support

2004-04-09 Thread Miguel de Icaza
Hello,

  Yes, Mono on MacOS X is not ready.  We will have a proper announcement
  when it is ready for consumption.
 
  We are aware of the bugs, and the problems on the engine, you will do
  yourself a service by just waiting at this point, trying to compile 
  Mono
  on MacOS is only frustrating at this time.
 
 I wish I heard the above statement two months ago ;)
 
 It's not so much that it isn't ready, it more of the goose chase I felt 
 I was on.  I kept finding little scraps of information about compiling 
 Mono/PPC.  A lot of 'Try XXX, it worked for me'.
 
 If someone or some documentation simply stated that Mono/PPC wasn't 
 ready for developers to compile, i would have switched modes from 
 trying to use it to trying to help fix it.

There were a number of factors:

* The Mono PPC at one point was self-hosting, but we found a few
  problems that lead to some rearchitecting of the code, and 
  which partially lead to the current situation.

* Today, given all the problems people are having, and the
  little or no experience in PPC from the community, there are
  very few fixes or debugging capability.

Given that the experience that most people with PPC is close to zero, at
this point its best to recommend people to just wait for us to be
finished. 

 I will keep following the development, and I hope to contribute some 
 day.  One question I do have for everyone is who owns the Mono/PPC 
 port?  Is there someone steering it that I should be contacting 
 directly, or is it more of a free for all?

Paolo is responsible, but sending him private email will not be useful,
you will only slow things down.

The best way of moving forward is making the full regression test suite
pass since bugs can be easily tracked down there, but they require PPC
knowledge.

Larger bug reports as in `Gtk# does not work' are just a consequence of
existing problems in the implementation.

Miguel.
___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] I give up

2004-04-09 Thread George Farris
On Fri, 2004-04-09 at 04:32, Joseph Bennie wrote:
   Remember to the rest of us who are just looking
  to be productive, we don't want to have to learn new tricks if we 
  don't have to
 
  With kindness
  Well, I have to say that this is possibly why there are so many poor
  windows applications that just don't understand the whole concept of
  multi-user.  WordPerfect used to get it right, MS-Office didn't, 
  neither
  did Mavis Beacon and an entire range of software developed for Windows.
  It is getting better but any time any company developed for multiple
  platforms and included Unix usually had a clue.  Please DO take the 
  time
  to learn new tricks.
 
 
 jokingly
 do you want slapped.
 
 Platforms don't make bad programmers, bad programmers make bad 
 applications.
 ;)
 

I agree, however, when the platform that is being written to is not
understood, things just get messy.

And seriously, yes, many programmers came from the single user DOS world
and it showed.

Cheers
-- 
George Farris [EMAIL PROTECTED]

___
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list