Skip to content

net

  • in net
  • 1 min read

Gzip under .NET

The kind folks over at ICSharpCode have created a Zlib library with Gzip, Zip, Tar and Bzip2 implementations.

Tried it out last night and it works beautifully. It fits into the networking thread of last in that I've decided that for communication i'm going to use Gzipped Base64 encoded XML. That gives me a nice compact format that's quite portable. Already tried out sending a such encoded message from a perl program on Linux to .NET on Windows and it worked beautifully. And it's 90% smaller than plain old XML.

Maybe if the Fast Infoset Project takes off, there'll be a more compact binary XML. In the meantime, this approach is at least easy for anyone to read, what with the ubiquity of gzip and b64.

  • in net
  • 1 min read

Remoting and Mono

After my TCP toying I decided to do some Remoting experiments last night. One of my goals with the network programming i'm doing right now is that the business logic of the code should be portable between .NET and Mono. I know Remoting is a probably not the answer there, since it may not even stay compatible between .NET revisions.

Regardless, I tried it out and it worked great between Linux and Windows. Nice, simple elegant (with a fair share of black magic under the hood). The only pitfall I came across was that if you are using RemotingConfiguration.RegisterActivatedClientType(), you gotta make sure that the type you are using comes from the same assembly on the two platforms. I had a bunch of problems because I compiled the Windows and Linux versions differently at first, but then i just copied the Assembly that contained the classes to be remoted to the linux side and compiled against it. That did the trick.

Now, is there something inbetween Remoting and writing my own protocol with TcpClient for doing Client/Server communication? More research for another night.

  • in net
  • 1 min read

TCP communication

Played around with TcpListener and TcpClient a bit this weekend. Last time I did low level network programming was in perl and it's interface was basically a socket interface. I did multiplexing with Posix select to check on sockets that were ready to do some communication. With C# i decided to go the multi-threading route instead and use the slightly higher level interfaces TcpListener and TcpClient.

I use the listener in the main thread in non-blocking mode, using pending to decide whether to accept a new connection. Then i spawn a thread for each TcpClient and have it listen the the client.

So far so good and fairly simple stuff. Except that I can't figure out how to detect if a client closed the connection on me rather me disconnecting them. I thought i'd get a SocketException when the client goes away, but so far my experiments show TcpClient happuily trying to read from the socket forever. Ho hum.

Update: Ok, so i'm just blind. I was so wrapped up looking for exceptions telling me that the client went away that i ignored the normal method of checking whether the read call read 0 bytes, just like in normal Posix sockets. Now that works like a charm

  • in net
  • 1 min read

EndDTE vs. VCCodeModel

Trying to identify all the members in a class, i can use CodeElement.Kind and build a large case statement against vsCMCodeElement.. But once I hit vsCMElement.vsCMElementEvent I hit a dead end. All the others have CodeBlah interfaces I can use to get .Access from, but there is no CodeEvent.

Digging around the net for a while i found the Microsoft.VisualStudio.VCCodeModel namespace, which has VCCodeEvent which in turn doesn't have an .Access member. And anyhow how does this sucker relate?

It would be nice if there was a reference from the vsCMCodeElement enum to the appropriate CodeElement interface.

And while we're wishing, how about a C# to EnvDTE reference. Oh, well, more experimenting to come

  • in net
  • 1 min read

EnvDTE

I figured I might as well blog this, since otherwise, i'll just loose the information I've come across. Simply this exists to write down useful or cool things I come across coding.

The impetus right now is on documenting my forays into EnvDTE in Visual Studio .NET 2003. EnvDTE is the namespace containing all the IDE automation classes, which I must say so far proves to be the worst documented portion of anything .NET related. I mean the MSDN docs are not even in the same format as the rest of the MSDN docs, the only examples in those docs are sparse at best and in VB.. Did I mention, I'm tackling this from the C# end.

Well, I made some headway so far and it's amazingly powerful stuff in there, but it's certainly a form of black magic. Nobody said it'd be easy.