C# interface restrictions / remoting

[matthew_glen_evans]

Hi there,

Quick one about interfaces in c#. It seems that it is illegal to
declare types within an interface.

I was quite used to doing this in VB.net where the interface can define
a
clients remoting interface and object model.

eg..

Public Interface ISelectionEngine

Function GetProductData(ByVal ChannelID As String) As XmlDocument

<Serializable()> _
Class ApplicantIncomeType
Public IncomeBasic As Decimal
Public IncomeBonus As Decimal
Public IncomeCommission As Decimal
Public IncomeOvertime As Decimal
Public StartDate As DateTime
Public EndDate As DateTime
End Class

<Serializable()> _
Enum ArrearPeriodConstants
ZeroTo6months
SevenTo12months
ThirteenTo24
End Enum

<Serializable()> _
Class NoProductFoundException
Inherits Exception
Public Sub New(ByVal sMessage As String)
MyBase.New(sMessage)
End Sub
Protected Sub New(ByVal info As SerializationInfo, ByVal
context As StreamingContext)
MyBase.New(info, context)
End Sub
End Class

End Interface

This will compile in vb.net...

I guess I could code the interface assembly in vb.net , but what is the
correct way to expose types across the remoting boundary in c#.

BTW this is a server activated object remoting configuration.

Thanks in advance,

Matthew

 

[Ian Griffiths [C# MVP]]

Why do you particularly need it to be a nested type?

In C#, if you want to define types to be used across a remoting boundary,
the normal practice is to declare the relevant type at the same scope as the
interface:

using System;
using System.Runtime.Serialization;
using System.Xml;

public interface ISelectionEngine
{
XmlDocument GetProductData(string ChannelID);
}

[Serializable]
public class ApplicantIncomeType
{
public decimal IncomeBasic;
public decimal IncomeBonus;
public decimal IncomeCommission;
public decimal IncomeOvertime;
public DateTime StartDate;
public DateTime EndDate;
}

[Serializable]
public enum ArrearPeriodConstants
{
ZeroTo6months,
SevenTo12months,
ThirteenTo24
}

[Serializable]
public class NoProductFoundException : Exception
{
public NoProductFoundException(string sMessage)
: base(sMessage)
{ }
protected NoProductFoundException(SerializationInfo info,
StreamingContext context) : base(info, context)
{ }
}

If you're using the interface for remoting, then you'll also be able to use
these other types across the same remoting interface. Remoting really
doesn't care where the types are defined so long as it's able to access
them. Making them nested types doesn't add anything. I've successfully
used types defined in the above manner across remoting boundaries in the
past. It never even occurred to me that I might want the types to be
nested.

So the usual practice would be to compile that source code into a seperate
DLL that is present on both the client and the server end of your
connection. You'll then be able to use the same types on either side. The
fact that the types aren't nested won't change anything.

 

[matthew_glen_evans]

I had tentatively come to that conclusion. Thanks very much for
confirming it.