I am experiencing a very strange problem while trying to set the value of a public field in a class that is being accessed using .NET remoting. Assuming the following definitions: public enum BuildMethod { DropBox, CVS, } public class BuildInfo : System.MarshalByRefObject { /// public BuildMethod Method; ... } The problem occurs in my client when I am trying to set the value of the Method field of BuildInfo, i.e.: xxxx.Method = BuildMethod.DropBox; There does not appear to be a problem retrieving the value of the Method field, but only when I try to set it. Exception Details: System.Runtime.Remoting.RemotingException: The argument type 1 cannot be converted into parameter type Matrix.Definitions.Schema.BuildMethod. Stack Trace: [RemotingException: The argument type 1 cannot be converted into parameter type Matrix.Definitions.Schema.BuildMethod.] System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) +264 System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) +877 System.Object.FieldSetter(String typeName, String fieldName, Object val) +0 Matrix.ProductMgmt.DeliveryMethodEditor.Save_Click(Object sender, EventArgs e) in D:\Matrix\WebApp\Application\ProductMgmt\DeliveryMethodEditor.ascx.cs:116 System.Web.UI.WebControls.LinkButton.OnClick(EventArgs e) +108 System.Web.UI.WebControls.LinkButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +57 System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +18 System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +138 System.Web.UI.Page.ProcessRequestMain() +1277 I am setting up the channel on the server side like this: System.Runtime.Remoting.Channels.BinaryServerFormatterSinkProvider SinkProvider = new BinaryServerFormatterSinkProvider(); SinkProvider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = 10782; this.ServiceChannel = new TcpChannel(props, null, SinkProvider); ChannelServices.RegisterChannel(this.ServiceChannel); I am making the object available on the server side using RemotingServices.Marshal(). I would appreciate any help or suggestions that anyone can provide. Thank you, Clark Laughlin

I am experiencing a very strange problem while trying to set the value of a public field in a class that is being accessed using .NET remoting. Assuming the following definitions: public enum BuildMethod { DropBox, CVS, } public class BuildInfo : System.MarshalByRefObject { /// public BuildMethod Method; ... } The problem occurs in my client when I am trying to set the value of the Method field of BuildInfo, i.e.: xxxx.Method = BuildMethod.DropBox; There does not appear to be a problem retrieving the value of the Method field, but only when I try to set it. Exception Details: System.Runtime.Remoting.RemotingException: The argument type 1 cannot be converted into parameter type Matrix.Definitions.Schema.BuildMethod. Stack Trace: [RemotingException: The argument type 1 cannot be converted into parameter type Matrix.Definitions.Schema.BuildMethod.] System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) +264 System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) +877 System.Object.FieldSetter(String typeName, String fieldName, Object val) +0 Matrix.ProductMgmt.DeliveryMethodEditor.Save_Click(Object sender, EventArgs e) in D:\Matrix\WebApp\Application\ProductMgmt\DeliveryMethodEditor.ascx.cs:116 System.Web.UI.WebControls.LinkButton.OnClick(EventArgs e) +108 System.Web.UI.WebControls.LinkButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +57 System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +18 System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +138 System.Web.UI.Page.ProcessRequestMain() +1277 I am setting up the channel on the server side like this: System.Runtime.Remoting.Channels.BinaryServerFormatterSinkProvider SinkProvider = new BinaryServerFormatterSinkProvider(); SinkProvider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = 10782; this.ServiceChannel = new TcpChannel(props, null, SinkProvider); ChannelServices.RegisterChannel(this.ServiceChannel); I am making the object available on the server side using RemotingServices.Marshal(). I would appreciate any help or suggestions that anyone can provide. Thank you, Clark Laughlin

I am having an interesting, but very annoying problem related to making web service requests from .NET to a Perl SOAP::Lite web service that is running on Linux. Here is the situation: (1) In most cases, we are able to make web service calls from ASP.NET to the Perl web service just fine. There may be problems, but the test methods that we've tried seem to work fine. (2) A .NET console application is able to make calls to the Perl web service without any visible problems. (3) The problem comes in when the Perl web service throws a SoapException. When this happens and the web service was called from the ASP.NET client, a System.Runtime.Serialization.SerializationException is thrown that says the following: An unhandled exception of type 'System.Runtime.Serialization.SerializationException' occurred in Unknown Module. Additional information: The type System.Web.Services.Protocols.SoapException in Assembly System.Web.Services, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f57f11d50a3a is not marked as serializable. What is confusing is that we can make make the same call from a .NET console application to the Perl web service and it works properly, throwing a SoapException. In each of the clients (ASP.NET & .NET console app), a web reference to the Perl web service was created the exact same way in Visual Studio based on a WSDL file, so there are no apparent differences in that area. In summary, we are finding a difference in behavior between an ASP.NET client and a .NET console application and I can't figure out what the difference is between them. If anyone has any suggestions or information on this, it would be most appreciated. Thank you, Clark Laughlin

I am having an interesting, but very annoying problem related to making web service requests from .NET to a Perl SOAP::Lite web service that is running on Linux. Here is the situation: (1) In most cases, we are able to make web service calls from ASP.NET to the Perl web service just fine. There may be problems, but the test methods that we've tried seem to work fine. (2) A .NET console application is able to make calls to the Perl web service without any visible problems. (3) The problem comes in when the Perl web service throws a SoapException. When this happens and the web service was called from the ASP.NET client, a System.Runtime.Serialization.SerializationException is thrown that says the following: An unhandled exception of type 'System.Runtime.Serialization.SerializationException' occurred in Unknown Module. Additional information: The type System.Web.Services.Protocols.SoapException in Assembly System.Web.Services, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f57f11d50a3a is not marked as serializable. What is confusing is that we can make make the same call from a .NET console application to the Perl web service and it works properly, throwing a SoapException. In each of the clients (ASP.NET & .NET console app), a web reference to the Perl web service was created the exact same way in Visual Studio based on a WSDL file, so there are no apparent differences in that area. In summary, we are finding a difference in behavior between an ASP.NET client and a .NET console application and I can't figure out what the difference is between them. If anyone has any suggestions or information on this, it would be most appreciated. Thank you, Clark Laughlin

I am having an interesting, but very annoying problem related to making web service requests from .NET to a Perl SOAP::Lite web service that is running on Linux. Here is the situation: (1) In most cases, we are able to make web service calls from ASP.NET to the Perl web service just fine. There may be problems, but the test methods that we've tried seem to work fine. (2) A .NET console application is able to make calls to the Perl web service without any visible problems. (3) The problem comes in when the Perl web service throws a SoapException. When this happens and the web service was called from the ASP.NET client, a System.Runtime.Serialization.SerializationException is thrown that says the following: An unhandled exception of type 'System.Runtime.Serialization.SerializationException' occurred in Unknown Module. Additional information: The type System.Web.Services.Protocols.SoapException in Assembly System.Web.Services, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f57f11d50a3a is not marked as serializable. What is confusing is that we can make make the same call from a .NET console application to the Perl web service and it works properly, throwing a SoapException. In each of the clients (ASP.NET & .NET console app), a web reference to the Perl web service was created the exact same way in Visual Studio based on a WSDL file, so there are no apparent differences in that area. In summary, we are finding a difference in behavior between an ASP.NET client and a .NET console application and I can't figure out what the difference is between them. If anyone has any suggestions or information on this, it would be most appreciated. Thank you, Clark Laughlin