I had Groove running on my notebook and I brought it up a few times to do things. I collaborate with some clients and people with Groove, keeping documents and discussions in sync. I also use it as a better Briefcase. And invariably, the comments were like "Wow, that's cool! I could manage my distributed project that way. I could keep track of bugs across a geographically disperse team that way. And man, you're disconnected and can sync later?" Then all of them would say "Who's Groove?" Its interesting to note that people need this kind of stuff and they have no idea its even out there or who Groove is (none of the developers in the room had ever heard of them). [...] How do we get people to collaborate? [Sam Gentile's Radio Weblog]

So then I download and install Groove, and start playing with it.  After 15 or 20 minutes of this, I'm starting to get it, so I think.  I call a few people from a client's office and get them to install it, and we start exploring what we can do.  By now, I'm getting excited about what I can do with this, and I'm starting to think I get it.  We figure out a couple of quick wins, and share a "pilot" groove space out to the team. [Greg Reinacker's Weblog]

Greg emailed me about Groove yesterday, I too had taken note of the recent posting on Groove and I'd been kicking around the idea of downloading it and seeing if anybody else at work would be interested.  Communication and collaboration are serious problems at work.  We've been using Sharepoint, but the results aren't great; we're using it as a glorified file server with a web interface.  Unfortunately, our connection to the Internet was pretty flaky yesterday and I couldn't connect to Groove the couple times I tried.  Monday, hopefully.

"Be an MCSE in 6 Weeks!" And other marketing BS.

Forgive me if I sound idealistic, but an education should be about gaining knowledge, not just about what you will do in your career, but knowledge about life.

[All Things Java]

Amen!

We're off!.

We're off to get married! [IUnknown.com: John Lam's Weblog on Software Development]

Belated congratulations, John and Carolyn!

I've been incredibly busy lately.  My company is deploying our Web Services for our early adopters, and I've been given the task of implementing the deployment procedures.  One of the problems to overcome was that our developers are using Visual Studio .NET, which is an awesome development environment, but is simply horrible for doing automated builds.  So the problem was to find a way to keep the developers happy working in VS.NET, but keep me happy doing build and deployment.  Read on for my solution.

A correction to an earlier post about Jim Klopfenstein's article on System.Management.  I said that "I've been playing in System.Management lately".  What I should have said is that I've been playing in System.DirectoryServices lately.  Yes, it's been that kind of month.  Anyway, aside from a mea culpa, I figured I'd elaborate on what I meant.

The specific problem I set out to solve was to install web services on our production servers.  These being production servers, IGS doesn't just let us terminal server into the box on an admin account and start hacking away.  We open a change ticket, give specific install instructions, and a tech implements the change.  Being that 1) I have to write the install instructions, and I'd rather write code, and 2) Written procedures are brittle, prone to erroneous implementation, and slower for the tech to implement, I decided to use NAnt to help out. 

The only problem with this was tweaking IIS, to set up virtual directories, applications, and tweak the security settings.  NAnt has no built in support for this, and although there was some muttering on the NAntContrib mailing lists about implementing this, but I have deadlines and it's really not too hard.  I already knew about the ADSI model for IIS and had worked with it before.  System.DirectoryServices is the managed way to do this, so I set out to write the NAnt tasks to support my installation.

But, still, there was a stumbling block, namely that IGS standard practice is to disable the default site, create new virtual sites, and put the website content somewhere besides c:inetpubwwwroot.  This means that you won't find the website running on port 80 at IIS://localhost/W3SVC/1/Root. ; So I wanted a task where I could write

<iisgetserverpath port="80" propname="iis.path"/>

and then have the correct ADSI path stored in the iis.path property, so I could use it later like so, in this instance to create a virtual directory named "Foo" off the root of the site:

<iiscreatevdir path="${iis.path}/Root" vdir="Foo"/>

Really, this code ends up being pretty simple.  The search looks like this:

using (DirectoryEntry w3svc = new DirectoryEntry("IIS://localhost/W3SVC"))
{
 foreach (DirectoryEntry child in w3svc.Children)
 {
  // enumerate the IIsWebServer objects
  if (child.SchemaClassName.Equals(ServerType))
  {
 PropertyValueCollection pvc = child.Properties["ServerBindings"]; 
String[] bindingParts = ((String)pvc[0]).Split(new char[] {':'},3);

if (Int32.Parse(bindingParts[1]).Equals(Port))
    {
     // we'll use this instance if we don't find another one that's running
     ADSIPath = child.Path;
     // check to see if this server is running - there can be only one server
     // running on a given port.
     if ( ((int) child.Properties["ServerState"].Value) == 2)
     {
       // this is the instance we want.
       Log.WriteLine("{0}Found server {1} running on port {2}", 
         LogPrefix, ADSIPath,Port);
       break; // found the server, break out.
     }
   }
 }
  }
   // At this point, if ADSIPath is null, there was no instance found at that port.
   if (ADSIPath == null)
   {
     Log.WriteLine("{0}No server found running on port {1}", 
       LogPrefix, Port);
     throw new BuildException(String.Format("Unable to find a server at port {0}",Port));
   }
   // save the ADSI path of the server into the specified property.
   Project.Properties.Add(PropName,ADSIPath);
}     

As you can see, though, it's a bit more code than Jim's example.  However, when I tried out Jim's code, I kept getting an error on the ManagementScope.Connect() call that the scope was invalid.  Does this code run only on server versions of the OS?  Also, I'm having trouble finding documentation on what scopes exist.  So I'll be looking at the System.Management approach, but for now, System.DirectoryServices works for me.  (You can download the full source for my task from here).