It seems that the HTTPListener class in .NET 2.0 does not support custom URIs as I once thought. I only supports the http:// and http:// prefixes. I'm still investigating, but it looks like I might end up writing my own custom server just so that I can do something like psvn:// Is that crazy or what? At least I have enough experience now writting tcp servers. Is TCPListener in my future? Time will tell...
I think I have finally settled into what I want to use for the transport for the remote RPC stuff. One of my main issues was not having a big external dependency for this piece. .NET Remoting and Web Services require IIS in order to do the easy-to-setup coding. I always thought that this was overkill for what I wanted to do, and I felt queasy about having to install virtual directories and all that jazz. I just don't want my users to have to deal with that.
My rule of thumb is "Don't make users jump through the hoops that I wouldn't jump myself." With that in mind, I checked out a couple of frameworks out there. The first one I looked at was RemObjects. I love how they do their developing, but I just can't afford the price of the kit. It is way above my budget. The second thing I checked out was GenuineChannels. They do a good job of removing a lot of difficulty found in using .NET remoting. They are cheaper than RemObjects, but I still felt that they were still overkill for what I wanted to do.
So today, I settled on just using a HTTPListener-based server to connect the MMC console to the server I'm going to be writting. I am deciding on what to use for passing across the wire, basically the message format. I'm investigating sending either XML-RPC or SOAP packets. I'm leaning towards using XML-RPC since the envelope is a lot simpler than SOAP. The only downside is that I would have to write a lot of conversion myself, converting objects to/from XML-RPC documents. I don't think I will have a lot of work to do, since I won't need a lot of differerent types of "envelopes." I would have rather bought this, but I just can't justify a $500 purchase for a product that might now sell for no more then $79.
I'm one of those people that find web programming quite annoying. I admit that ASP.NET is heads and shoulders above ASP.
The main thing that I like about MMC is how well organized programming against nodes is. The base class for nodes in MMC is the ScopeNode. I have created several derived classes to handle the different nodes. Each encapsulates the correct icon to use, the actions for the node, and any other custom logic for each node. This way of coding has sped my adding of needed functionality.
I now only have 4 more main features to add, before I start beta testing
- Hot copy command for repositories
- Dump command for repositories
- Info command for all Subversion objects
- Proplist command for all Subversion objects
What made this all posible is the SVNManagerLib library that I have been hosting at SourceForge. This is an assembly that sits between PainlessSVN and the Subversion server. The URL is https://sourceforge.net/projects/svnmanagerlib
It appears that there is a bug in the internal imagelist that MMC 3.0 uses to store the 16x16 icons. From what I understand XP icons are RGBA bitmaps and use the AlphaBlend API. Regular bitmaps use the BitBlt API. The XP Alpha icons show up with a black background. Any icons that I converted from alpha to 256 using the auto conversion feature in Axialis IconWorkshop.
The workaround I found, is to change the palette of these icons into a true 256 palette. I chose the Windows XP.axct from the palettes listed in the file dialog. This seems to fix the black background when the icons are shown in MMC. I only did this for the 16x16, and left the 32x32 icons untouched.
What a pain in the ass!
PS. I wish I had a freaking spell checker built into this!!!
I implemented the new dialog designs from Brandon. They are definetely not hideus like my originals where. I might tweak the title, but not right now. This new format is much easier on the eyes. Here's a screenshot of what they now look like:
