Discussions

@itsnotabug: Ah excellent, I'll check it out.

@ScanIAm: Yes that is exactly what I was looking for. I guess I just missed that, thanks! A much better solution for sure.

5 hours ago, cheong wrote

Wrap your code with using block, when leaving the block it'd call dispose on the TcpClient underneath, which will close the connection.

TcpClientChannel doesn't implement interface IDisposable so it can't be used in a using block.

It seems there is no clear way to disconnect explicitly. I think the idea is that the connection will be closed when the lease expires or the client interface instance is GC'ed.

This actually creates a problem for me because due to a complication of the code that the server PInvokes into, the server needs to restart itself between sessions. When this happens and I re-create the interface on the client side using Activator.GetObject, it somehow returns the previous interface instance (probably tries to re-use the previous one due to Singleton) but any calls to it will throw an exception because it isn't connected to the server anymore. I hacked around this problem by putting the code shown above into a loop and if the exception is thrown, try again. It always seems to succeed on the second try.

I'm just thinking there must be a way to close the connection explicitly but I can't figure out how.

Actually, it turns out StackFrame isn't that slow, less than 1 ms. And since I can't use C# 5.0, I'll stick with that for now.

But it is good to know this feature was added to 5.0.

BTW this is all my own code so I have full control over what happens where. However I need this because hand-coding each method is going to take a long time, vs simply copy/pasting the same thing everywhere.

OK previously I asked about WCF but I had to revert to .Net remoting for a reason that's too long to explain here.

Anyway, everything works well except... I' can't figure out how to disconnect from the client side. Specifically, I'm following the pattern where the server/client shares a common interface declaration, and there is no shared DLL. However on the client side, I have a reference to the interface, but since it isn't derived from MarshalByRefObject, I can't figure out how to initiate a clean disconnect from the client side.

On the client, I'm doing this:

var channel = new TcpClientChannel();
var url = "tcp://" + ipAddress.ToString() + ":" + port.ToString() + "/MyService";

ChannelServices.RegisterChannel(channel, false);

var remoteApi = (IMyInterface)Activator.GetObject(typeof(IMyInterface), url);

Anyone have an idea?

OK looks like StackFrame will do what I need. Just wondering how slow it will be since I want to use it for logging purposes. Something like:

public void Foo()
{
    StartMethod(new StackFrame());
    ...
    ...
}

StartMethod will then log whatever is passed in as the stack frame.

Is it possible to get the current method name in C# similar like you can get the current function name in C/C++ using __FUNCTION__?

I tried to do this once with reflection but I couldn't figure out how to do it.

Thanks everyone for the suggestions.

1 day ago, myefforts2 wrote

This is totally possible. Add the contract files to the client project as a link (Add | Existing Item | Add As Link). If you're willing to create the ChannelFactory on the client yourself then you don't need any config either.

Yes I ended up adding the common files as a link to the other project. This works well and is the best way to share common files between different projects. I remember using links to files in a previous version of VS (maybe it was VS 2008), but it was very flaky at that time. Sometimes VS would get confused and even end up crashing. But it seems to work flawlessly in VS 2012.

I'm not very familiar with WCF although a few years ago I did use it for IPC between two different processes on the same system. However in that case there was a DLL shared between the server/client which contained the interface.

This is what I want to do now:

Server:

• Define an interface and add ServiceContract, OperationContract, etc attributes.

Client:

• Be able to consume the interface defined by the server without requiring a shared DLL or XML config file at runtime.

Now the server and client are both projects within the same solution, and will never be compiled separately, but will run on different systems. So it is possible to share the same source files between the two projects (maybe that's all I need?). What I am looking for is to end up with both the server and client having a single *.exe file and not require a shared DLL or config file.

Is this possible with WCF?

And White. And Square. And Maps. And Aluminum. And Baubles.