Do not check-in DEBUG specific code.

We are using .Net Remoting to interact beteeen client and back end server. I needed to call a method from services class.
For debugging purposes I decided to create the class directly. It was easier to debug without starting extra back-end process.
The code was like the following:

IMyServices services = (IMyServices)RemotingHelper.GetObject(typeof(IMyServices));
    services = new MyServices();
// Process the task

During the development I checked that the method done the required processing and changed the parameter object as expected.

And I’ve checked in the code, assuming that in Release mode the application will work the same way just by instantiating proxy instead of full object.
However in Release mode changes in parameter inside calling method were not returned back.
Of course, If parameter is serializable, it is passed by value. and correct implementation will use return value

 ItemsCollection = services.ProcessItems(ItemsCollection);

But more general recommendation before check-in remove/comment-out any DEBUG specific shortcuts and test the code  as it will be in production.

.Net Remoting clent proxy error in debugger inspection

I am using .Net Remoting and tried to debug call from client proxy. It didn’t allow me to step into(whick is actually normal) and Debugger inspection showed me that Identity property has an exception:

  Identity System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.Remoting.RemotingException: Permission denied: cannot call non-public or static methods remotely.

Server stack trace:
   at System.Runtime.Remoting.Channels.ChannelServices.DispatchMessage(IServerChannelSinkStack sinkStack, IMessage msg, IMessage& replyMsg)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at System.MarshalByRefObject.get_Identity()
   — End of inner exception stack trace —
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
   at Microsoft.Office.Tools.Debugger.Tools.TryCreateDebuggerItem(MemberInfo member, Object target, __Item& item) System.Reflection.TargetInvocationException

I’ve decided that there is an error and tried to find the solution. Similar issues (without good explanation) are:
Fortunately this debugger message can be ignored, and my call to remoting service worked as expected.

Remoting asyncronous call to fire and forget

I want to do .Net Remoting asyncronous call with “fire and forget” approach.
MSDN statement in OneWayAttribute Class documentation is not clear “The method can execute synchronously or asynchronously with respect to the caller.”  
Thanks to manish godse’s blog : OneWay messages in remoting post: invoking a method with [OneWay] attribute the client will not wait for a response and the call will return immediately. In essence the call gets converted to an async call and the client doesnt wait for a server response. The async behaviour for [OneWay] messages is true, when you are invoking a method on a remoting proxy. Invoking the same method on a regular object will be called synchronously like any other method.
Similar explanation is in Using OneWayAttribute for Remote Calls article.
In a summury, to call a Remoting method asyncronously to “fire and forget”, you need to mark a method on your remote INTERFACE with OneWayAttribute.
Related links:

Could not load type ‘System.ServiceModel.Configuration.BindingsSectionGroup’

After installing .Net 3.5 SP1 on the existing server, that runs .Net 2.0, I’ve got the exception: 

Source : mscorlib

Message : An error occurred creating the configuration section handler for system.serviceModel/bindings: Could not load type ‘System.ServiceModel.Configuration.BindingsSectionGroup’ from assembly ‘System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089’.

Filename : c:WINDOWSMicrosoft.NETFrameworkv2.0.50727Configmachine.config

Line : 100

Errors : System.Configuration.ConfigurationException[]

Stack Trace :

Server stack trace:

   at System.Configuration.BaseConfigurationRecord.EvaluateOne(String[] keys, SectionInput input, Boolean isTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult)

   at System.Configuration.BaseConfigurationRecord.Evaluate(FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult, Boolean getLkg, Boolean getRuntimeObject, Object& result, Object& resultRuntimeObject)

   at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)

   at System.Configuration.BaseConfigurationRecord.GetSection(String configKey, Boolean getLkg, Boolean checkPermission)

   at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)

   at System.Web.Configuration.HttpConfigurationSystem.GetApplicationSection(String sectionName)

   at System.Web.Configuration.HttpConfigurationSystem.GetSection(String sectionName)

   at System.Web.Configuration.WebConfigurationManager.GetSection(String sectionName)

   at System.ServiceModel.Configuration.ConfigurationHelpers.UnsafeGetSectionFromWebConfigurationManager(String sectionPath)

   at System.ServiceModel.Configuration.ConfigurationHelpers.UnsafeGetAssociatedSection(ContextInformation evalContext, String sectionPath)

   at System.ServiceModel.Configuration.ClientSection.UnsafeGetSection()

   at System.ServiceModel.Description.ConfigLoader.LookupChannel(String configurationName, String contractName, Boolean wildcard)

   at System.ServiceModel.Description.ConfigLoader.LoadChannelBehaviors(ServiceEndpoint serviceEndpoint, String configurationName)

   at System.ServiceModel.ChannelFactory.ApplyConfiguration(String configurationName)

   at System.ServiceModel.ChannelFactory.InitializeEndpoint(String configurationName, EndpointAddress address)

   at System.ServiceModel.ChannelFactory`1..ctor(String endpointConfigurationName, EndpointAddress remoteAddress)

   at System.ServiceModel.EndpointTrait`1.CreateSimplexFactory()

   at System.ServiceModel.EndpointTrait`1.CreateChannelFactory()

   at System.ServiceModel.ClientBase`1.CreateChannelFactoryRef(EndpointTrait`1 endpointTrait)

   at System.ServiceModel.ClientBase`1.InitializeChannelFactoryRef()

   at System.ServiceModel.ClientBase`1..ctor()

I’ve searched the Google and the post suggested to use ServiceModel Registration Tool (ServiceModelReg.exe)  .But it didn’t help.


With a hint from post Unrecognized configuration section system.serviceModel

I manually updated 2 lines in Machine.config (that probably were left from some previous beta installation) based on Machine.config from my development machine, that didn’t have the problem. 

      <!–<section name=”bindings” type=”System.ServiceModel.Configuration.BindingsSectionGroup, System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>–>

      <section name=bindings type=System.ServiceModel.Configuration.BindingsSection, System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089/>

<!–<section name=”extensions” type=”System.ServiceModel.Configuration.ServiceModelExtensionsSection, System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089″/>–>

<section name=extensions type=System.ServiceModel.Configuration.ExtensionsSection, System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089/> 

And the errors disappeared.

Passing parameters in .Net Remoting

It is well known, that in .Net value type parameters are passed by value, and reference type parameters are passed by reference(more detailed and strict description can be found here).
I thought(even after a year working with application that extensively uses Remoting)  that .Net Remoting calls do the same. But I was wrong!
Recently I found that a method with custom class parameter  doesn’t have one of the properties updated after return, even if it is certainly updated inside the method.
I’ve read a few reference articles.
quickstart Remoting Overview is a little bit confusing:
Object passing. All objects created remotely are returned by reference and have to derive from MarshalByRefObject. Objects passed as parameters to a remote method call can be forwarded by value or by reference. The default behavior is pass by value provided the object in question is marked by the custom attribute [Serializable]. Additionally, the object could implement the ISerializable interface, which provides flexibility in how the object should be serialized and deserialized. Objects that are not marshal by reference or marshal by value are not remotable.

How to marshal an object to a remote server by value by using Visual C# is more clear:

Because parameter ForwardMe does not inherit from MarshalByRefObject, it is passed by value to the server.

And finally, article  Copying, Cloning, and Marshalling in .NET clarified it:

By default, all objects in .NET (both value- and reference-types) are marshalled by value when sent across the “wire” to a remote AppDomain.To override this default MBV behavior, one can simply derive one’s class from System.MarshalByRefObject .

So the Rules for passing parameters in .Net Remoting are the following:

1. Parameter should have attribute [Serializable] or derive from MarshalByRefObject.
(It would be unusual for a class to be both marked with the serializable attribute and extend MarshalByRefObject.)

2. If parameter is serializable, it is passed by value. Changes inside remote methods do not return to the client.

3. If parameter  derive from MarshalByRefObject , it is passed by reference.

4. I am not sure, what happens If you specify modifier ref  for serializable parameter. I hope that it is also passed by reference, but not sure.

The following links discuss how parameters are treated in WCF:

How to pass a reference in WCF 

Preserving Object Reference in WCF  

WCF vs .Net remoting Notes

We are using .Net remoting now between Web Server and Application Server farms. I am consider to use WCF for new modules.

Good news: The WCF and .NET Remoting are really comparable in performance. and according to MSDN article A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies WCF  even approximately 25% faster.  

I hope to extend this post when I will collect more info.

DateTime value in DataSet changed over remoting boundaries.

We are using .Net remoting(.Net framework 2.0) to pass DataSet from application server to web server.
It was noticed that if DateTime field in DataSet has ‘2008-10-26 02am” value, during remoting it is changed to ‘2008-10-26 03am“.
I beleive that it is somehow relates to Daylight Saving time change. We didn’t noticed any changes for other DateTime values.
According to  Western Australia (Perth)  has time change 26-Oct, 02:00h.
However the servers with the problem noticed are located in Melbourne and Sydney, that have different date for Daylight Saving time change.(See also
Furthermore my development machine doesn’t have this problem -‘2008-10-26 02am” is transferred unchanged.
We haven’t found any essential differences in settings between machines that have the problem and my deveopment machine. It may be related to some MS hotfix update(??). However other machines with and without .Net framework 2 SP1 have the same problem.
Update: Reader of my post asked how to send DateTime values in a DataSet with DayLight saving considerration, but then pointed that .Net 2.0 and greater has ability to specify DataSetDateTime.Unspecified  enum value(“Serialization in this mode does not cause an offset”)  in DataColumn.DateTimeMode Property. It will make DateTime values in a dataset predictable regardless of server local time settings.
Also note that in .Net 3.5 there is TimeZoneInfo Class that suppose to help with cross-zone issues.