[en] Roadmap proposal

Topics: Announcements
Coordinator
Mar 20, 2011 at 2:53 PM
Edited Mar 21, 2011 at 1:50 PM

Hi, Rainbird!

I have a few new ideas for Zyan, but all of them need a lot of stuff to be done.
I don't want Zyan 2.0 release to be delayed, though, so I'd like to schedule them for the next release.
Here is a sketch roadmap:

Zyan 2.0

  • Duplex TCP channel
  • Call interception
  • Basic LINQ support
  • One-way calls support
  • Other cool things done since 1.2
  • English documentation (I'm currently working on it)

Zyan 3.0 (?)

  • Generic methods support
  • Better LINQ integration
  • Handling component references
  • Replacing reflection stuff with dynamic methods
  • Hosting anonymous types
  • Hosting IDynamicMetaObjectProviders (ExpandoObject, Clay, etc)
  • Optional compression

To be discussed

  • Faster custom serialization instead of BinaryFormatter
  • Reliable UDP or UDT channel
  • Fast Windows-messages channel
  • NoSQL-based session management

What do you think?

Coordinator
Mar 21, 2011 at 9:37 PM
Edited Mar 21, 2011 at 9:39 PM

Hi, yallie,

thanks for your ideas and plannings. Full ack for Zyan 2.0. Only centralized handling of SocketException and other network related errors sould be on the 2.0 roadmap too.
For the 3.0 features we should get a little bit deeper into the details, first.

  • Generic methods support

Generic methods are commonly used and I agree with you, that Zyan should support them. I see no problems to implement that feature. 

  • Better LINQ integration

Yes, LINQ integration in a more intuitive way would be great. When generic methods are working, better LINQ integration is only a small footstep away.

  • Handling component references

I have worries about the feasibility of this feature. Please check my comment on http://zyan.codeplex.com/workitem/766.

  • Replacing reflection stuff with dynamic methods

Sounds interesting. Are dynamic methods faster than reflection? What are the pros and cons of dynamic methods compared to reflection? We should also think about mono support.
I have not really experience with dynamic methods.

  • Hosting anonymous types

That´s good for Zyan 3.0.

When we got anonymous types to work with Zyan, Expandos and all that stuff should be no big problem.

  • Optional compression

Very handy feature. This can be implemented as a remoting channel sink.

  • Faster custom serialization instead of BinaryFormatter

Why not. Faster is alway better, when it´ll have no other drawbacks.

  • Reliable UDP or UDT channel

Developing new remoting channels is a lot of work. Much more than developing custom sinks.
Channel development can be made easily side by side, because it doesn´t require changes on the Zyan API.
The following link may be helpful when developing a UDP channel: http://www.winsocketdotnetworkprogramming.com/clientservernetremotingnetwork12f.html   

  • Fast Windows-messages channel

Greater diversity is good for Zyan.
In wich scenarios has a Window Message Channel advantages? Are the use cases not the same like IpcChannel?

  • NoSQL-based session management

Great feature! What NoSQL engines do you want to support? Or create a lightwight NoSql engine especially for session persistance?

I have some ideas for Zyan 3.0, too.

  • Process callbacks with the ZyanDispatcher on client side

Currently callbacks from server to client are not processed the same way which normal server calls are done. This results in unexpected behavior in some cases.
To resolve this, I plan to hold a ZyanDispatcher for every ZyanConnection and to manage call dispatch and parameter handling of callbacks with it.

  • Easier and more flexible integration of remoting sinks

backdog has provided a custom sink for network statistics as patch. Unfortunately Zyan offers no interface to plug single sinks into the Remoting Pipeline.
You have to write new protocol setup classes. I think Zyan should provide support for plugging in custom sinks without writing a new protocol setup.

  • Monitoring and statistic API

I want to integrate network statistic functionality based on blackdog´s patch. Detailed monitoring and logging is always required in bigger applications. Think about error tracking in an production environment, for example.

I´m looking forward to future Zyan versions.



Coordinator
Mar 21, 2011 at 11:43 PM
Edited Jul 5, 2011 at 2:01 PM

Hi!

>>Generic methods support

>I see no problems to implement that feature.

Hmm, maybe I don't get something... I was always thinking that .NET remoting just can't create MethodCallMessages for generic methods. Can you provide brief overview of how are you planning to implement generic methods support?

>>Replacing reflection stuff with dynamic methods

>Sounds interesting. Are dynamic methods faster than reflection?

Yes, dynamic methods are many times faster (almost just as fast as plain calls). Here is a quick test I just wrote (see below for the source code):

Plain calls. Elapsed: 381,8697 ms
Reflection. Elapsed:  11321,8403 ms (29,65 times slower)
Dynamic method:       401,4484 ms (only 1,05 times slower)

I don't know about any drawbacks of dynamic methods (except that it's a bit more complex to write ilasm code than to use reflection invocation API). Mono framework supports dynamic methods.

>>Reliable UDP or UDT channel

>Developing new remoting channels is a lot of work. Much more than developing custom sinks.

I've developed simple (unreliable) UDP channel some time ago. It wasn't very easy (it took about a couple of days), but it's quite feasible.
UPD. I checked in the source code of my channel (see udp_channel branch). It was tested with TcpEx's sample client/server classes.

>Channel development can be made easily side by side, because it doesn´t require changes on the Zyan API.

Yes, I agree.

>The following link may be helpful when developing a UDP channel: http://www.winsocketdotnetworkprogramming.com/clientservernetremotingnetwork12f.html   

Thanks! Looks interesting.

>>Fast Windows-messages channel

>In wich scenarios has a Window Message Channel advantages? Are the use cases not the same like IpcChannel?

I've heard that using windows messages (WM_DATA) is the fastest way of inter-process communications for windows applications with a message pump (faster than named pipes). I think, we should just test it against Ipc channel.

>What NoSQL engines do you want to support?

I was thinking about Redis. ServiceStack library has a great .NET Redis client distributed under BSD license.

>Or create a lightwight NoSql engine especially for session persistance?

It's also a good idea :)

>Easier and more flexible integration of remoting sinks

Oh, I just forgot to mention this! This is a must-have, of course.

>Monitoring and statistic API

Agreed!


Here is a source code for dynamic methods benchmark I just wrote:

// C:\Windows\Microsoft.NET\Framework\v3.5\csc test.cs

using System;
using System.Diagnostics;
using System.Reflection;
using System.Reflection.Emit;

class Program
{
	const int Iterations = 1000000;

	static void Main()
	{
		var test = new TestClass();
		var arg1 = 123;
		var arg2 = "456";

		// plain
		var sw = new Stopwatch();
		sw.Start();
		for (int i = 0; i < Iterations; i++)
		{
			var result = test.DoStuff(arg1, arg2);
		}
		sw.Stop();
		var plain = sw.Elapsed.TotalMilliseconds;
		Console.WriteLine("Plain calls. Elapsed:    {0} ms", plain);

		// reflection
		var mi = typeof(TestClass).GetMethod("DoStuff", BindingFlags.Instance | BindingFlags.Public);
		sw = new Stopwatch();
		sw.Start();
		for (int i = 0; i < Iterations; i++)
		{
			var result = mi.Invoke(test, new object[] { arg1, arg2 });
		}
		sw.Stop();
		var reflection = sw.Elapsed.TotalMilliseconds;
		Console.WriteLine("Reflection. Elapsed:     {0} ms ({1:0.00} times slower)", reflection, reflection / plain);

		// dynamic method
		var doStuff = new DynamicMethod(
			"DoStuffDynamic", 
			typeof(string), // return type 
			new[] { typeof(TestClass), typeof(int), typeof(string) }, // argument types
			typeof(Program).Module);

		var il = doStuff.GetILGenerator();
		il.Emit(OpCodes.Ldarg_0);
		il.Emit(OpCodes.Ldarg_1);
		il.Emit(OpCodes.Ldarg_2);
		il.EmitCall(OpCodes.Call, mi, null);
		il.Emit(OpCodes.Ret);
		var doStuffDelegate = (Func<TestClass, int, string, string>)doStuff.CreateDelegate(typeof(Func<TestClass, int, string, string>));

		sw = new Stopwatch();
		sw.Start();
		for (int i = 0; i < Iterations; i++)
		{
			var result = doStuffDelegate(test, arg1, arg2);
		}
		sw.Stop();
		var dyn = sw.Elapsed.TotalMilliseconds;
		Console.WriteLine("Dynamic method. Elapsed: {0} ms (only {1:0.00} times slower)", dyn, dyn / plain);
	}
}                              

class TestClass
{
	public string DoStuff(int a, string b)
	{
		return a.ToString() + b;
	}
}
Coordinator
Mar 22, 2011 at 8:31 AM

> Hmm, maybe I don't get something... I was always thinking that .NET remoting just can't create MethodCallMessages for generic methods. Can you provide brief overview of how are you planning to implement generic methods support?

// Determine if method is a generic method
methodCallMessage.MethodBase.IsGenericMethod

// Get array of generic argument types 
methodCallMessage.MethodBase.GetGenericArguments()


The MethodCallMessage supports generic methods. The proxy technology (RealProxy) also supports generic methods. I think the RemotingProxy and/or the native Remoting Dispatcher don´t handle them correctly. For Zyan this is not important, because we use a custom proxy (ZyanProxy) and a custom dispatcher. I think we only have to extend ZyanDispatcher.Invoke with additional parameters to identify generic method calls and sending generic argument types to the server. On serverside the new parameters can be used to dispatch the generic method call correctly.

Microsoft does no longer invest into .NET Remoting. Because of this, no one has ever added generic method support to .NET Remoting. The SoapFormatter has no generic support. Microsoft propagates WCF. But I don´t like WCF. It´s a monster. But that´s only my personal opinion. Others may think WCF is cool.

> I've heard that using windows messages (WM_DATA) is the fastest way of inter-process communications for windows applications with a message pump (faster than named pipes). I think, we should just test it against Ipc channel.

Then we should give it a try.

Coordinator
Mar 22, 2011 at 11:05 AM
Edited Mar 22, 2011 at 11:07 AM

>The MethodCallMessage supports generic methods. The proxy technology (RealProxy) also supports generic methods.

This is amazing!

I was thinking of some wrapper chain to convert generic methods to non-generic on-the-fly, something like this:

public interface IMyServer
{
     T GetValue<T>(string name);
}

public class MyServer : IMyServer
{
    public T GetValue<T>(string name) { ... }
}

// automatically-generated non-generic wrapper interface
public interface IMyServer_NonGeneric
{
    object GetValue(Type t, string name);
}

// automatically-generated non-generic server-side wrapper
public class MyServer_NonGeneric : NonGenericWrapperBase, IMyServer_NonGeneric
{ private IMyServer instance; private MethodInfo getValueMethodInfo = GetMethod(...); public object GetValue(Type type, string name) { return base.Invoke(instance, getValueMethodInfo, type, name); } } // automatically-generated generic client-side wrapper public class MyServer_Generic : GenericWrapperBase, IMyServer { private IMyServer_NonGeneric proxy; public T GetValue<T>(string name) { return (T)proxy.GeValue(typeof(T), name); } }

The call would go like this: Client -> MyServer_Generic -> IMyServer_NonGeneric proxy -> (remote connection) -> MyServer_NonGeneric -> MyServer.

If RealProxy supports generic methods, the solution would be much simpler!

>Microsoft does no longer invest into .NET Remoting.

Yep. That's sad.

>Microsoft propagates WCF. But I don´t like WCF. It´s a monster. But that´s only my personal opinion. Others may think WCF is cool.

WCF may be cool for many scenarios, but it's no way a replacement for Remoting. Remoting is strictly .NET-oriented while WCF tends to be as portable as possible. WCF is generally more developer-friendly than Remoting, but I don't like its verbosity. Application code tends to become bloated with numerous WCF attributes, fault contracts, etc even for relatively simple scenarios.

Coordinator
Mar 27, 2011 at 3:25 PM

I finally translated all Zyan documentation to English.

Rainbird, please review my texts once you have some spare time.

You might want to fix or add something, as I am not sure everything is 100% correct (I did my best to understand it all, though).

Coordinator
Mar 27, 2011 at 7:02 PM

Great English translation, yallie! I´ve nothing to add or change so far.

I´ll keep the English and German documentation pages synchronized, for all future extensions to the documentation. Please feel free to add documentation topics in English, if you want. I´ll translate them to German, as soon as I can spare time. The English documentation is more important than the German version. Almost all german developers can understand English. So the German documentation is only a nice to have feature.

I order to complete Zyan 2.0, I am currently working on stable WAN support for the TCP Duplex Channel and centralized handling for communication errors.

 

Coordinator
Mar 27, 2011 at 9:21 PM

Thanks!

>Please feel free to add documentation topics in English, if you want. I´ll translate them to German, as soon as I can spare time.

That's great! I think I should at least add a page about LINQ support.

Coordinator
Jun 3, 2011 at 11:13 PM

Zyan 2.0 final is released. After a long time of testing and fixing (especially the Duplex Channel) I think this release could be truly called "stable version".

Special thanks to you, yallie, for your great support and for your good ideas.

Coordinator
Jun 5, 2011 at 6:05 PM

That's a good news!

I've just checked in a minor update to the resource translation.
Is it too late to update the release binaries?

What about the work item prioritization?
I'd suggest

  1. merging/fixing/localizing InterLinq, so we can join Zyan assemblies into one
  2. publishing a NuGet package to simplify Zyan integration.

After that we can focus on a brand new features such as generics support.

Coordinator
Jun 6, 2011 at 6:10 AM

Sorry, I forgot about the resource translation. It´s not too late to update the release binaries. But we should raise the version to 2.0.0.1. I can create an publish updated binaries this evening.

I agree with the work item prioritization you suggested and suggest to add a third task:

3. Adding documentation for new features.

I also suggest to create some minor releases (e.G. 2.1, ...) before 3.0 to introduce new features step by step.

Coordinator
Jun 7, 2011 at 12:02 PM
Rainbird wrote:

3. Adding documentation for new features.

I think, it's even more important than anything else. Scarce/outdated documentation is a common weak point of the open-source projects.

Rainbird wrote:

I also suggest to create some minor releases (e.G. 2.1, ...) before 3.0 to introduce new features step by step.

Yes, absolutely.

Coordinator
Jun 30, 2011 at 2:34 PM
Rainbird wrote:
  • Generic methods support

Generic methods are commonly used and I agree with you, that Zyan should support them. I see no problems to implement that feature.

You were right, Rainbird, implementing generic methods support was quite easy :)

Here is my unit test checked in a few minutes ago:

public interface ISampleServer
{
	T GetValue<T>(string name);
}

public class SampleServer : ISampleServer
{
	public T GetValue<T>(string propertyName)
	{
		var proc = Process.GetCurrentProcess();
		var prop = proc.GetType().GetProperty(propertyName);
		return (T)prop.GetValue(proc, null);
	}
}

[TestMethod]
public void TestGenericReturnValue()
{
	var proxy = ZyanConnection.CreateProxy<ISampleServer>();
	var proc = Process.GetCurrentProcess();

	var id1 = proc.Id;
	var id2 = proxy.GetValue<int>("Id");
	Assert.AreEqual(id1, id2);

	var mn1 = proc.MachineName;
	var mn2 = proxy.GetValue<string>("MachineName");
	Assert.AreEqual(mn1, mn2);

	var st1 = proc.StartTime;
	var st2 = proxy.GetValue<DateTime>("StartTime");
	Assert.AreEqual(st1, st2);
}
Coordinator
Jul 4, 2011 at 4:37 PM

Bad luck, Mono's RealProxy doesn't seem to support generic methods. Unit tests throw weird SerializationException:

Test-case: TestGenericArguments
Exception: System.Runtime.Serialization.SerializationException
Message: Could not find method 'System.String ProcessData[Int32](Int32)' in type 'Zyan.Tests.GenericMethodsTest+ISampleServer'
Stack trace: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception& exc, System.Object[]& out_args)

Test-case: TestGenericReturnValue1
Exception: System.Runtime.Serialization.SerializationException 
Message: Could not find method 'Int32 GetValue[Int32](System.String)' in type 'Zyan.Tests.GenericMethodsTest+ISampleServer'
Stack trace: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception& exc, System.Object[]& out_args)

Test-case: TestGenericReturnValue2
Exception: System.Runtime.Serialization.SerializationException
Message: Could not find method 'Int32 Duplicate[Int32](Int32)' in type 'Zyan.Tests.GenericMethodsTest+ISampleServer'
Stack trace: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception& exc, System.Object[]& out_args)

Test-case: TestOverloadedMethods
Exception: System.Runtime.Serialization.SerializationException
Message: Could not find method 'System.String OverloadedMethod[String](System.String, System.String, DateTime)' in type 'Zyan.Tests.GenericMethodsTest+ISampleServer'
Stack trace: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception& exc, System.Object[]& out_args)

Coordinator
Jul 14, 2011 at 11:42 AM

Hmm, the problem doesn't seem to be in RealProxy itself...

I wrote a simple test for RealProxy, and it works well under Mono 2.10.2:

// Executed by .NET4 runtime:
// Method called: Int32 GenericArgument[DateTime](System.DateTime)
// Method called: Int32 GenericReturnValue[Int32]()
// Method called: System.Collections.Generic.IEnumerable`1[Program] GetCollection[Program]()
// Method called: System.Linq.IQueryable`1[Program] GetQuery[Program]()
// Method called: Void Run[IEnumerable`1]()

// Executed by Mono runtime:
// Method called: Int32 GenericArgument[DateTime](DateTime)
// Method called: Int32 GenericReturnValue[Int32]()
// Method called: IEnumerable`1 GetCollection[Program]()
// Method called: IQueryable`1 GetQuery[Program]()
// Method called: Void Run[IEnumerable`1]()

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Remoting.Proxies;

class Program
{
	static void Main()
	{
		var proxy = new TestProxy(typeof(ISample)).GetTransparentProxy() as ISample;
		var result1 = proxy.GenericArgument(DateTime.Now);
		var result2 = proxy.GenericReturnValue<int>();
		var result3 = proxy.GetCollection<Program>();
		var result4 = proxy.GetQuery<Program>();
		proxy.Run<IEnumerable<IQueryable<int>>>();
	}
}

class TestProxy : RealProxy
{
	public TestProxy(Type type) : base(type) {}

	public override IMessage Invoke(IMessage message)
	{
		var methodCallMessage = (IMethodCallMessage)message;
		var methodInfo = (MethodInfo)methodCallMessage.MethodBase;

		Console.WriteLine("Method called: {0}", methodInfo);
		return new ReturnMessage(GetDefaultValue(methodInfo.ReturnType), null, 0, null, methodCallMessage);
	}

	object GetDefaultValue(Type type)
	{
		if (type.IsValueType && !typeof(void).IsAssignableFrom(type))
		   return Activator.CreateInstance(type);

		return null;
	}
}

interface ISample
{
	int GenericArgument<T>(T arg);

	T GenericReturnValue<T>();

	IEnumerable<T> GetCollection<T>();

	IQueryable<T> GetQuery<T>();

	void Run<T>();
}

Coordinator
Jul 14, 2011 at 12:04 PM
Edited Jul 14, 2011 at 12:07 PM

The exception printed by Mono Runtime is rethrown by RealProxy class, and it doesn't carry much information:

Exception: System.Runtime.Serialization.SerializationException

Could not find method 'System.String ProcessData[Int32](Int32)' in type 'Zyan.Tests.GenericMethodsTest+ISampleServer'

 at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp,
       IMessage msg, System.Exception& exc, System.Object[]& out_args) [0x00165]
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Runtime.Remoting.Proxies\RealProxy.cs:226 

I've managed to track remote StackTrace in a private field of Exception object, which is much more interesting:

Server stack trace: 

 at System.Reflection.MemberInfoSerializationHolder.GetRealObject (StreamingContext context) [0x00136]
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Reflection\MemberInfoSerializationHolder.cs:131 

 at System.Runtime.Serialization.ObjectRecord.LoadData (System.Runtime.Serialization.ObjectManager manager,
       ISurrogateSelector selector, StreamingContext context) [0x00133]
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Runtime.Serialization\ObjectManager.cs:579 

 at System.Runtime.Serialization.ObjectManager.DoFixups () [0x00066]
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Runtime.Serialization\ObjectManager.cs:80 

 at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadNextObject (System.IO.BinaryReader reader) [0x0000f]
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Runtime.Serialization.Formatters.Binary\ObjectReader.cs:145 

 at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObjectGraph (BinaryElement elem, System.IO.BinaryReader reader,
       Boolean readHeaders, System.Object& result, System.Runtime.Remoting.Messaging.Header[]& headers) [0x00041] 
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Runtime.Serialization.Formatters.Binary\ObjectReader.cs:110 

 at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObjectGraph (System.IO.BinaryReader reader, Boolean readHeaders, 
       System.Object& result, System.Runtime.Remoting.Messaging.Header[]& headers) [0x00007] 
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Runtime.Serialization.Formatters.Binary\ObjectReader.cs:95

 at System.Runtime.Serialization.Formatters.Binary.MessageFormatter.ReadMethodCall (BinaryElement elem, System.IO.BinaryReader reader, 
       Boolean hasHeaders, System.Runtime.Remoting.Messaging.HeaderHandler headerHandler, 
       System.Runtime.Serialization.Formatters.Binary.BinaryFormatter formatter) [0x000d6] 
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Runtime.Serialization.Formatters.Binary\MessageFormatter.cs:315 

 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserialize (System.IO.Stream serializationStream, 
       System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00054] 
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Runtime.Serialization.Formatters.Binary\BinaryFormatter.cs:155 

 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, 
       System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00000] 
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\corlib\System.Runtime.Serialization.Formatters.Binary\BinaryFormatter.cs:128 

 at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage (IServerChannelSinkStack sinkStack, IMessage requestMsg, 
       ITransportHeaders requestHeaders, System.IO.Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, 
       System.IO.Stream& responseStream) [0x000a1] 
    in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.10.2\mcs\class\System.Runtime.Remoting\System.Runtime.Remoting.Channels\BinaryServerFormatterSink.cs:162 

Exception rethrown at [0]: 

Looks like BinaryFormatter tries to deserialize MethodInfo or something like that. Still don't have any idea why.

Coordinator
Jul 14, 2011 at 1:09 PM
Edited Jul 14, 2011 at 1:49 PM

The problem seem to be caused by ParameterDefinition for generic method:

public object IZyanDispatcher.Invoke(Guid trackingID, string interfaceName, List<DelegateCorrelationInfo> delegateCorrelationSet, 
    string methodName, Type[] genericArguments, ParameterInfo[] paramDefs, params object[] args)

 

UPD. The quest is complete! Generic methods now work on Mono :)

Coordinator
Jul 18, 2011 at 7:43 PM

Great!

That is a big improvement.