Re: [Mono-dev] TypeLoadException when remoting from Windows
On 2/7/07, Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] wrote: Jacob Ilsø Christensen escribió: Hi. I am trying to do a remote call from Windows to an application running on Linux under Mono 1.2.2.1. When I try it, I get the exception below. There is not much info as to what might be wrong. Is it a missing assembly? Does it work with MS.NET vs MS.NET? If yes, then it's a bug in Mono. If not, it probably gives you a better error message and that could be a bug in Mono too because of the lack of info and you should report it. Yep, it works perfectly from MS.NET to MS.NET. I filed a bug report that mono should report a more meaningful error message (http://bugzilla.ximian.com/show_bug.cgi?id=80761). Regards, Andrés [ knocte ] -- ___ 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] TypeLoadException when remoting from Windows
Jacob Ilsø Christensen wrote: On 2/7/07, Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] wrote: Jacob Ilsø Christensen escribió: Hi. I am trying to do a remote call from Windows to an application running on Linux under Mono 1.2.2.1. When I try it, I get the exception below. There is not much info as to what might be wrong. Is it a missing assembly? Does it work with MS.NET vs MS.NET? If yes, then it's a bug in Mono. If not, it probably gives you a better error message and that could be a bug in Mono too because of the lack of info and you should report it. Yep, it works perfectly from MS.NET to MS.NET. I filed a bug report that mono should report a more meaningful error message (http://bugzilla.ximian.com/show_bug.cgi?id=80761). Please attach a test case to this bug entry. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WS stack.
Hi, Well, if your patch is exactly about message serialization, then it is not appropriate. The WSDL currently we generate is buggy and such a buggy WSDL will result in such an incorrect message serialization (that is, since the WSDL says fooSpecified should/could be in the message, wsdl.exe will interpret it as part of the message contract, and thus it will generate wrong proxy classes). However, you patch is for SoapReflectionImporter and I guess that seems to be the correct file to fix. Or is your way to reproduce the bug different? Are you using different service engine (e.g. .NET) ? Atsushi Eno Daniel Lundqvist wrote: Hi, Ok, I think there perhaps is a missunderstanding here. What I'm talking about here is not the resulting WSDL but the actual SOAP/XML serialization of the RPC call. I apologize if I wasn't clear enough about that from the start. Hope that makes more sense for you in this case. -Ursprungligt meddelande- Från: [EMAIL PROTECTED] genom Atsushi Eno Skickat: on 2007-02-07 16:27 Till: mono-devel-list@lists.ximian.com Ämne: Re: [Mono-dev] WS stack. Hi :) Daniel Lundqvist wrote: Hey again :) ons 2007-02-07 klockan 20:51 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: Hi Atsushi, mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: The issue here is that it always sends the oid and parentoid field regardless of value of fieldSpecified. I got a patch (against SVN) for it, don't know if it's correct but solves the problem for me. So now it only sends oid and parentoid when fieldSpecified is set to true. This was tested with 1.1.17.1 but the problem is in SVN as well from what I can see. Oh, cool. Can you please share the patch so that it could be fixed? Of course, thought I attached it but I'll reattach it. The problem is that XmlTypeMapMember::CheckOptionalValueType is never called and thus the OPTIONAL bit in its flags field is never set (Which is then checked in XmlSerializationWriterInterpreter::MemberHasValue). Thanks :) However, now I tried your patch but it does not seem to fix the issue. Do you have actual case that the patch indeed fix the issue? I attached what I tried. Weird. I've redone my tests with the 1.2.3 release. With a stock System.Xml.dll it have the problem but with a patched (with the patch I sent earlier) it don't. There are some other places (I think) that XmlTypeMapMember is instanciated but I didn't add the call there, so this patch only fixes my problem. Perhaps this call should be placed in a more appropiate place, but I don't speak the XML/WS stack fluently enough to find where. If your patch does not fix the case that I attached, then yes it is likely to happen. I'd wait for your case and try to fix it. Now I think I see one issue. Since you are using WebService and WebMethod attributes perhaps they are hitting the other path that is calling CreateMapMember(), in ImportMembersMapping in either XmlReflectionImport.cs or SoapReflectionImport.cs (depends on using literal encoding or not). After some more investigation that seems to be the case. From what I can see the enclosing type is not available at that point (which is needed to call XmlTypeMapMember::CheckOptionalValueType). Well, however removing [WebService] didn't change anything, and without [WebMethod] it doesn't expose any ports. Or are you checking anything else than the output WSDL? (As long as the WSDL contains 'oldSpecified' and 'parentoidSpecified' the issue isn't fixed.) Probably a reproducible example would tell me what exactly is the issue you are having fix. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TypeLoadException when remoting from Windows
On 2/8/07, Robert Jordan [EMAIL PROTECTED] wrote: Jacob Ilsø Christensen wrote: On 2/7/07, Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] wrote: Jacob Ilsø Christensen escribió: Hi. I am trying to do a remote call from Windows to an application running on Linux under Mono 1.2.2.1. When I try it, I get the exception below. There is not much info as to what might be wrong. Is it a missing assembly? Does it work with MS.NET vs MS.NET? If yes, then it's a bug in Mono. If not, it probably gives you a better error message and that could be a bug in Mono too because of the lack of info and you should report it. Yep, it works perfectly from MS.NET to MS.NET. I filed a bug report that mono should report a more meaningful error message (http://bugzilla.ximian.com/show_bug.cgi?id=80761). Please attach a test case to this bug entry. I would like to, but it would be much less time consuming for me if the TypeLoadException provided a better error message. That way I could easier pinpoint the issue and write a test case. /Jacob Robert ___ 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] [OT] Yast (3.0) in C#
Hi, This idea may be wired. But I think rewriting yast in C# is real test/showcase of how much mature mono is? My sugesstion on this. *Gui must be written in WinForm, which is test/showcase how much complete WinForm is? -- Sharique uddin Ahmed Farooqui (C++/C# Developer, IT Consultant) http://www.sharique.managefolio.com/ A revolution is about to begin. A world is about to change. And you and me are the initiator. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TypeLoadException when remoting from Windows
Jacob Ilsø Christensen escribió: I am trying to do a remote call from Windows to an application running on Linux under Mono 1.2.2.1. When I try it, I get the exception below. There is not much info as to what might be wrong. Is it a missing assembly? Does it work with MS.NET vs MS.NET? If yes, then it's a bug in Mono. If not, it probably gives you a better error message and that could be a bug in Mono too because of the lack of info and you should report it. Yep, it works perfectly from MS.NET to MS.NET. I filed a bug report that mono should report a more meaningful error message (http://bugzilla.ximian.com/show_bug.cgi?id=80761). Please attach a test case to this bug entry. I would like to, but it would be much less time consuming for me if the TypeLoadException provided a better error message. That way I could easier pinpoint the issue and write a test case. But you must first indicate which is the bug: the remoting issue or the meaningless info message. If it's the latter, you must provide a testcase for it. And once that's fixed, perhaps you could write a testcase for the remoting issue without problems. Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [OT] Yast (3.0) in C#
If I were to suggest something like that I will never suggest legacy GUI framework i.e. windows forms for new development. And of course you are wrong to choose whom to talk to about your idea. Atsushi Eno Sharique uddin Ahmed Farooqui wrote: Hi, This idea may be wired. But I think rewriting yast in C# is real test/showcase of how much mature mono is? My sugesstion on this. *Gui must be written in WinForm, which is test/showcase how much complete WinForm is? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [OT] Yast (3.0) in C#
Have you thought about using a framework which will let you implement multiple frontends? Regards, Matthijs ter Woord Sharique uddin Ahmed Farooqui wrote: Hi, This idea may be wired. But I think rewriting yast in C# is real test/showcase of how much mature mono is? My sugesstion on this. *Gui must be written in WinForm, which is test/showcase how much complete WinForm is? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TypeLoadException when remoting from Windows
Jacob Ilsø Christensen wrote: On 2/8/07, Robert Jordan [EMAIL PROTECTED] wrote: Jacob Ilsø Christensen wrote: On 2/7/07, Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] wrote: Jacob Ilsø Christensen escribió: Hi. I am trying to do a remote call from Windows to an application running on Linux under Mono 1.2.2.1. When I try it, I get the exception below. There is not much info as to what might be wrong. Is it a missing assembly? Does it work with MS.NET vs MS.NET? If yes, then it's a bug in Mono. If not, it probably gives you a better error message and that could be a bug in Mono too because of the lack of info and you should report it. Yep, it works perfectly from MS.NET to MS.NET. I filed a bug report that mono should report a more meaningful error message (http://bugzilla.ximian.com/show_bug.cgi?id=80761). Please attach a test case to this bug entry. I would like to, but it would be much less time consuming for me if the TypeLoadException provided a better error message. That way I could easier pinpoint the issue and write a test case. Hint: it's a MS corlib type that doesn't exist in Mono, maybe one of these: System.RuntimeType (the underlying type of System.Type = this basically means that you can't remote System.Type between the runtimes) or another System.Runtime* type, mostly used for Method/Property/Event/FieldInfo. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] ASP.NET 2.0 - fix page culture creation when the browser passes neutral culture
Title: RE: [Mono-dev] [PATCH] ASP.NET 2.0 - fix page culture creation when the browser passes neutral culture Looks good. Regards, Kosta -Original Message- From: [EMAIL PROTECTED] on behalf of Marek Habersack Sent: Thu 08/02/2007 06:53 To: Mono Development List Subject: [Mono-dev] [PATCH] ASP.NET 2.0 - fix page culture creation when the browser passes neutral culture Hello, The attached diff fixes a backtrace when the browser passes a culture of the form 'en', 'de' - i.e. a neutral culture which cannot be used as the current thread culture/ui culture. Please review, thanks marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] ASP.NET 2.0 - fix for TemplateSourceDirectory inheritance with master pages
Title: RE: [Mono-dev] [PATCH] ASP.NET 2.0 - fix for TemplateSourceDirectory inheritance with master pages Hello Marek, To solve the problem you describe, MS set the new property - AppRelativeTemplateSourceDirectory. I think it would be better to follow their solution - then we will be able to share our code (see Control.TemplateSourceDirectory - the JVM version). In addition, if the user overrides TemplateSourceDirectory, his code will not compile under mono. Regards, Konstantin Triger -Original Message- From: [EMAIL PROTECTED] on behalf of Marek Habersack Sent: Thu 08/02/2007 00:25 To: Mono Development List Subject: [Mono-dev] [PATCH] ASP.NET 2.0 - fix for TemplateSourceDirectory inheritance with master pages Hello, The attached diff fixes a situation, where ResolveClientUrl wouldn't work correctly if it was used from within a control placed in a page that uses a master page, i.e. if the parenthood tree was like: System.Web.UI.WebControls.ContentPlaceHolder System.Web.UI.HtmlControls.HtmlForm ASP.test_master ASP.Default_aspx with the site layout: Default.aspx subdir/test.master subdir/Default.aspx In such situation, ResolveUrl (called by ResolveClientUrl) would return incorrect URL for any relative address, in the above case, if invoked from ~/Default.aspx: ResolveClientUrl(subdir/Default.aspx) == subdir/subdir/Default.aspx This was due to the fact, that ASP.test_master TemplateSourceDirectory code (generated by the TemplateControlCompiler) would not reach up to its parent, but would return ~/subdir instead of /. The diff makes two modifications - first it makes sure TemplateSourceDirectory always returns a HTTP-absolute URL (e.g. /, /subdir etc) and that any template control checks for its parent's TemplateSourceDir value before returning its hard-coded source directory. please review, thanks marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] ASP.NET 2.0 - fix for TemplateSourceDirectory inheritance with master pages
On Thu, 8 Feb 2007 06:16:59 -0800, Konstantin Triger [EMAIL PROTECTED] scribbled: RE: [Mono-dev] [PATCH] ASP.NET 2.0 - fix for TemplateSourceDirectory inheritance with master pages Hello Marek, Hello Kosta, To solve the problem you describe, MS set the new property - AppRelativeTemplateSourceDirectory. I think it would be better to follow TemplateSourceDirectory is a different thing to this one. The changes in the diff make TemplateSourceDirectory work in accordance with what tests on MS.NET show. their solution - then we will be able to share our code (see Control.TemplateSourceDirectory - the JVM version). In addition, if the user overrides TemplateSourceDirectory, his code will not compile under mono. I agree, but I need this as a staging phase for now. I need to think about a nice way of not adding TemplateSourceDirectory in generated code. regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] ASP.NET 2.0 - fix for TemplateSourceDirectory inheritance with master pages
Title: RE: [Mono-dev] [PATCH] ASP.NET 2.0 - fix for TemplateSourceDirectory inheritance with master pages Hi Marek, their solution - then we will be able to share our code (see Control.TemplateSourceDirectory - the JVM version). In addition, if the user overrides TemplateSourceDirectory, his code will not compile under mono. I agree, but I need this as a staging phase for now. I need to think about a nice way of not adding TemplateSourceDirectory in generated code. I guess the things will work if you set the AppRelativeTemplateSourceDirectory with 'parser.BaseVirtualDir'. (Not tested though). regards, Kosta ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TypeLoadException when remoting from Windows
Hi.
Ok, I finally managed to reproduce the issue. Attached are some test
files. The file named compile shows how to compile the stuff.
So, first launch TestImpl.exe and then Test.exe. What I experienced is
the following:
MS .NET - MS.NET works
MS .NET - Mono does not work (throws the exception I wrote about earlier)
Mono - MS.NET works
Mono - Mono works
If I comment out the event handler line in Test.cs all four cases
work. Can someone confirm this issue?
Thanks,
Jacob
On 2/8/07, Robert Jordan [EMAIL PROTECTED] wrote:
Jacob Ilsø Christensen wrote:
On 2/8/07, Robert Jordan [EMAIL PROTECTED] wrote:
Jacob Ilsø Christensen wrote:
On 2/7/07, Andrés G. Aragoneses [ knocte ] [EMAIL PROTECTED] wrote:
Jacob Ilsø Christensen escribió:
Hi.
I am trying to do a remote call from Windows to an application running
on Linux under Mono 1.2.2.1. When I try it, I get the exception below.
There is not much info as to what might be wrong. Is it a missing
assembly?
Does it work with MS.NET vs MS.NET? If yes, then it's a bug in Mono. If
not, it probably gives you a better error message and that could be a
bug in Mono too because of the lack of info and you should report it.
Yep, it works perfectly from MS.NET to MS.NET. I filed a bug report
that mono should report a more meaningful error message
(http://bugzilla.ximian.com/show_bug.cgi?id=80761).
Please attach a test case to this bug entry.
I would like to, but it would be much less time consuming for me if
the TypeLoadException provided a better error message. That way I
could easier pinpoint the issue and write a test case.
Hint: it's a MS corlib type that doesn't exist in Mono, maybe
one of these: System.RuntimeType (the underlying type of
System.Type = this basically means that you can't remote
System.Type between the runtimes) or another System.Runtime* type,
mostly used for Method/Property/Event/FieldInfo.
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
gmcs ITest.cs /t:library
gmcs Test.cs /r:ITest.dll
gmcs TestImpl.cs /r:ITest.dll /r:System.Runtime.Remoting
public delegate void TestDelegate(object sender, System.EventArgs eventArgs);
public interface ITest
{
void Test();
event TestDelegate TestEvent;
}
using System;
using System.IO;
public class Test
{
public static void Main()
{
string service = tcp://192.168.0.133:5000/;
ITest test = (ITest)Activator.GetObject(typeof(ITest), service
+ Test);
test.Test();
test.TestEvent += new TestDelegate(TestHandler); // This causes
problems
}
public static void TestHandler(object sender, EventArgs eventArgs)
{
}
}
using System;
using System.Collections;
using System.IO;
using System.Threading;
using System.Runtime.Remoting;
using System.Runtime.Serialization.Formatters;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
public class MyTest : MarshalByRefObject, ITest
{
public void Test()
{
Console.Out.WriteLine(Test);
}
public event TestDelegate TestEvent;
}
public class TestImpl
{
public static void Main()
{
BinaryServerFormatterSinkProvider provider = new
BinaryServerFormatterSinkProvider();
provider.TypeFilterLevel = TypeFilterLevel.Full;
IDictionary props = new Hashtable();
props[port] = 5000;
props[name] = originalTcpChannel;
TcpChannel channel = new TcpChannel(props, null, provider);
ChannelServices.RegisterChannel(channel, false);
RemotingServices.Marshal(new MyTest(), Test);
System.Console.WriteLine(Ready...);
System.Console.ReadLine();
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] COM Callable Wrapper Patch
On 02/07/07 Jon Chambers wrote:
different. I currently have no way to determine that an object with a
finalizer needs it's CCW destroyed but don't need it's finalizer run.
For delegates we just check and return in SuppressFinalize.
You could add a similar check there with the usual fast path for when no
com support has been used.
It looks like this check has not been implemented.
At least add a FIXME with the explanation.
+gboolean
+mono_marshal_free_ccw (MonoObject* object)
+{
+ GList *ccw_list, *ccw_list_orig, *ccw_list_item;
+ /* no ccw's were created */
+ if (!ccw_hash || g_hash_table_size (ccw_hash) == 0)
+ return FALSE;
+
+ /* need to cache orig list address to remove from hash_table if empty */
+ ccw_list = ccw_list_orig = g_hash_table_lookup (ccw_hash,
GINT_TO_POINTER (mono_object_hash (object)));
The hash table accesses need locking protection. I didn't check for
other lockings issues, but I guess it will be easier once the code is
integrated in svn.
+void
+cominterop_mono_string_to_guid (const MonoString* string, guint8 *guid) {
+ gunichar2 * chars = mono_string_chars (string);
+ guid [0] = g_unichar_xdigit_value (chars [7]) + (g_unichar_xdigit_value
(chars [6]) 4);
+ guid [1] = g_unichar_xdigit_value (chars [5]) + (g_unichar_xdigit_value
(chars [4]) 4);
[...]
I would implement this with a loop: put in a small const byte array the
indexes in the proper sequence (in this case: 7, 5, 3, 1, 12, 10, ...)
and loop other it.
Please commit after the above changes.
Thanks!
lupus
--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] ZMD not working with Mono 1.2.3
Hello, After updating Mono from 1.2.2 to 1.2.3 I can't seem to talk to the ZenWorks Management Daemon anymore - client tools like rug or zen-updater all hang. I've described the problem on the opensuse mailing list: http://lists.opensuse.org/opensuse/2007-02/msg00800.html If someone happens to run ZMD, may I please ask if it works for you with the latest release? Thanks, Sorin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
