Re: [Mono-dev] MonoMethod-MethodInfo

2015-02-14 Thread Jeroen Frijters
If you know the module on the managed side, Module.ResolveMethod() can be used 
to get a MethodInfo from a token.

Regards,
Jeroen

 -Original Message-
 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of Greg Young
 Sent: Saturday, February 14, 2015 21:56
 To: mono-devel-list@lists.ximian.com
 Subject: [Mono-dev] MonoMethod-MethodInfo
 
 Let's say I have a MonoMethod in unmanaged code. I want to pass some
 data out of that code back into managed code (using some identifiers of
 the monomethod) so that the managed code can obtain a MethodInfo via
 reflection.
 
 At first I thought about passing the token(s). I cannot however find
 anyway of looking up a MethodInfo based on its token (nor a type ...).
 I could get the type and then iterate over the methods but this seems
 like a bad idea.
 
 1) Am I missing something with tokens on the managed side?
 2) Is there some other way of doing this that I am missing?
 
 Cheers,
 
 Greg
 
 --
 Studying for the Turing test
 ___
 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] MonoMethod-MethodInfo

2015-02-14 Thread Jonathan Chambers
You could pass the manged MethodInfo* object directly into managed,
retrieving it in native code by calling: mono_method_get_object

Alternatively, you could pass a System.RuntimeMethodHandle struct into
managed code (with the MonoMethod* as the value in that structure) and
call MethodBase.GetMethodFromHandle to retrieve the method from that handle
when needed.

- Jonathan

On Sat, Feb 14, 2015 at 3:56 PM, Greg Young gregoryyou...@gmail.com wrote:

 Let's say I have a MonoMethod in unmanaged code. I want to pass some
 data out of that code back into managed code (using some identifiers
 of the monomethod) so that the managed code can obtain a MethodInfo
 via reflection.

 At first I thought about passing the token(s). I cannot however find
 anyway of looking up a MethodInfo based on its token (nor a type ...).
 I could get the type and then iterate over the methods but this seems
 like a bad idea.

 1) Am I missing something with tokens on the managed side?
 2) Is there some other way of doing this that I am missing?

 Cheers,

 Greg

 --
 Studying for the Turing test
 ___
 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] MonoMethod-MethodInfo

2015-02-14 Thread Greg Young
Let's say I have a MonoMethod in unmanaged code. I want to pass some
data out of that code back into managed code (using some identifiers
of the monomethod) so that the managed code can obtain a MethodInfo
via reflection.

At first I thought about passing the token(s). I cannot however find
anyway of looking up a MethodInfo based on its token (nor a type ...).
I could get the type and then iterate over the methods but this seems
like a bad idea.

1) Am I missing something with tokens on the managed side?
2) Is there some other way of doing this that I am missing?

Cheers,

Greg

-- 
Studying for the Turing test
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] WCF WebServiceHost crashes mono if client disconnects early

2015-02-14 Thread Horst Müller
Greetings!

I've stumbled upon what I believe to be a rather serious problem in mono's
WCF implementation.

When a client disconnects during a transmission from a WebServiceHost, an
exception is thrown:

Exception Write failure   at System.Net.Sockets.NetworkStream.Write
(System.Byte[] buffer, Int32 offset, Int32 size) [0x0008e] in
/build/mono/src/mono-3.12.0/mcs/class/System/System.Net.Sockets/NetworkStream.cs:418

  at System.Net.ResponseStream.InternalWrite (System.Byte[] buffer, Int32
offset, Int32 count) [0x00029] in
/build/mono/src/mono-3.12.0/mcs/class/System/System.Net/ResponseStream.cs:132

  at System.Net.ResponseStream.Write (System.Byte[] buffer, Int32 offset,
Int32 count) [0x000dd] in
/build/mono/src/mono-3.12.0/mcs/class/System/System.Net/ResponseStream.cs:165

  at System.ServiceModel.Channels.Http.HttpRequestContext.InternalReply
(System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x00157] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:160

  at System.ServiceModel.Channels.Http.HttpRequestContext.Reply
(System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x0] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:101

  at System.ServiceModel.Dispatcher.MessageProcessingContext.Reply (Boolean
useTimeout) [0x00026] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/MessageProcessingContext.cs:96

  at System.ServiceModel.Dispatcher.OperationInvokerHandler.Reply
(System.ServiceModel.Dispatcher.MessageProcessingContext mrc, Boolean
useTimeout) [0x0001d] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/OperationInvokerHandler.cs:69

  at System.ServiceModel.Dispatcher.OperationInvokerHandler.ProcessRequest
(System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x00044] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/OperationInvokerHandler.cs:29

  at
System.ServiceModel.Dispatcher.BaseRequestProcessorHandler.ProcessRequestChain
(System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x0] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessorHandler.cs:15

  at
System.ServiceModel.Dispatcher.BaseRequestProcessorHandler.ProcessRequestChain
(System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x00017] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessorHandler.cs:16

  at System.ServiceModel.Dispatcher.HandlersChain.ProcessRequestChain
(System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0xb] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessor.cs:72

  at System.ServiceModel.Dispatcher.BaseRequestProcessor.ProcessRequest
(System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x00018] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessor.cs:26


This exception gets caught and rethrown until it ends up at
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:596,
where ProcessErrorWithHandlers returns false and we reply to the
RequestContext with an error message. This then generates a second
exception that is not caught, crashing the whole program:

Unhandled Exception:
System.InvalidOperationException: Cannot be changed after headers are sent.
  at System.Net.HttpListenerResponse.set_ContentType (System.String value)
[0x00027] in
/build/mono/src/mono-3.12.0/mcs/class/System/System.Net/HttpListenerResponse.cs:110

  at
System.ServiceModel.Channels.Http.HttpStandaloneResponseInfo.set_ContentType
(System.String value) [0x0] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpContextInfo.cs:274

  at System.ServiceModel.Channels.Http.HttpRequestContext.InternalReply
(System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x00046] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:140

  at System.ServiceModel.Channels.Http.HttpRequestContext.Reply
(System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x0] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:101

  at System.ServiceModel.Channels.Http.HttpRequestContext.Reply
(System.ServiceModel.Channels.Message msg) [0x0] in
/build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:96

  at System.ServiceModel.Dispatcher.ListenerLoopManager.ProcessRequest
(IReplyChannel reply, System.ServiceModel.Channels.RequestContext rc)
[0x0003b] in

Re: [Mono-dev] MonoMethod-MethodInfo

2015-02-14 Thread Greg Young
I have to pass by lookup values. My unmanaged is running in the context of
a profiler.

On Saturday, February 14, 2015, Jonathan Chambers jonc...@gmail.com wrote:

 You could pass the manged MethodInfo* object directly into managed,
 retrieving it in native code by calling: mono_method_get_object

 Alternatively, you could pass a System.RuntimeMethodHandle struct into
 managed code (with the MonoMethod* as the value in that structure) and
 call MethodBase.GetMethodFromHandle to retrieve the method from that handle
 when needed.

 - Jonathan

 On Sat, Feb 14, 2015 at 3:56 PM, Greg Young gregoryyou...@gmail.com
 javascript:_e(%7B%7D,'cvml','gregoryyou...@gmail.com'); wrote:

 Let's say I have a MonoMethod in unmanaged code. I want to pass some
 data out of that code back into managed code (using some identifiers
 of the monomethod) so that the managed code can obtain a MethodInfo
 via reflection.

 At first I thought about passing the token(s). I cannot however find
 anyway of looking up a MethodInfo based on its token (nor a type ...).
 I could get the type and then iterate over the methods but this seems
 like a bad idea.

 1) Am I missing something with tokens on the managed side?
 2) Is there some other way of doing this that I am missing?

 Cheers,

 Greg

 --
 Studying for the Turing test
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 javascript:_e(%7B%7D,'cvml','Mono-devel-list@lists.ximian.com');
 http://lists.ximian.com/mailman/listinfo/mono-devel-list




-- 
Studying for the Turing test
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] xsp-3.12 RPM package is missing in mono-project's CentOS repository

2015-02-14 Thread Miguel de Icaza
That looks like a bad package.

XSP should not depend on a specific version of Mono, instead it should
require at least a specific version of Mono.

CCing Jo.

On Mon, Feb 9, 2015 at 11:46 AM, sean_houston sean.sta...@aesir-media.com
wrote:

 apache2-mod_mono-3.12 is available in the CentOS package repo; however, the
 repo is missing xsp-3.12.  This is forcing the use of apache2-mod_mono-3.8
 since xsp-3.12 is a requirement for installing apache2-mod_mono-3.12.  Will
 it be possible for the package maintainer(s) to release xsp-3.12 in the
 near
 future?  Information from my system follows:

 # yum update apache2-mod_mono
 snipped
 Resolving Dependencies
 -- Running transaction check
 --- Package apache2-mod_mono.x86_64 0:3.8-0 will be updated
 --- Package apache2-mod_mono.x86_64 0:3.12-0 will be an update
 -- Processing Dependency: xsp = 3.12 for package:
 apache2-mod_mono-3.12-0.x86_64
 -- Finished Dependency Resolution
 Error: Package: apache2-mod_mono-3.12-0.x86_64
 (download.mono-project.com_repo_centos_)
Requires: xsp = 3.12
Installed: xsp-3.8-0.x86_64
 (@download.mono-project.com_repo_centos_)
xsp = 3.8-0
  You could try using --skip-broken to work around the problem
  You could try running: rpm -Va --nofiles --nodigest

 

 Here are the currently-installed mono packages:
 # yum list installed \*mono\* \*xsp\*
 snipped
 Installed Packages
 apache2-mod_mono.x86_64   3.8-0
 libmono-2_0-1.x86_64  3.12.0-1
 libmono-2_0-devel.x86_64  3.12.0-1
 libmonoboehm-2_0-1.x86_64 3.12.0-1
 libmonoboehm-2_0-devel.x86_64 3.12.0-1
 libmonosgen-2_0-1.x86_64  3.12.0-1
 libmonosgen-2_0-devel.x86_64  3.12.0-1
 mono-complete.x86_64  3.12.0-1
 mono-core.x86_64  3.12.0-1
 mono-data.x86_64  3.12.0-1
 mono-data-oracle.x86_64   3.12.0-1
 mono-data-postgresql.x86_64   3.12.0-1
 mono-data-sqlite.x86_64   3.12.0-1
 mono-devel.x86_64 3.12.0-1
 mono-entityframework.x86_64   3.12.0-1
 mono-extras.x86_643.12.0-1
 mono-locale-extras.x86_64 3.12.0-1
 mono-mvc.x86_64   3.12.0-1
 mono-nunit.x86_64 3.12.0-1
 mono-reactive.x86_64  3.12.0-1
 mono-wcf.x86_64   3.12.0-1
 mono-web.x86_64   3.12.0-1
 mono-winforms.x86_64  3.12.0-1
 mono-winfxcore.x86_64 3.12.0-1
 monodoc-core.x86_64   3.12.0-1
 xsp.x86_643.8-0

 

 Enabled repositories:
 # yum repolist enabled
 snipped
 repo id repo name
 status
 base/7/x86_64   CentOS-7 - Base
 8,465
 download.mono-project.com_repo_centos_  added from:
 http://download.mono-project.com/repo/centos/199
 epel/x86_64 Extra Packages for Enterprise Linux
 7 - x86_64 7,195
 extras/7/x86_64 CentOS-7 - Extras
 104
 updates/7/x86_64CentOS-7 - Updates
 1,668

 Thanks!
 Sean



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/xsp-3-12-RPM-package-is-missing-in-mono-project-s-CentOS-repository-tp4665433.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list