Recent Updates Page 75

Ok, I’ve gotten a great response from others arriving at Tech Ed early, so this party should be a lot of fun.  I have some ideas myself, but I’d like to take suggestions (from those who plan on attending) on the following items:

1. What time it should start


2. Where I should book it


3. What activities to include


4. What restaurant to include (because we must certainly kick off the week with a geek dinner!)

Here’s one idea.  If everyone can get a class M license before June, we can all rent Harley’s from EagleRider’s in Orlando. 🙂  I had a Fat Boy for a day back in 2001, and Orlando is a pretty nice town to ride through.

That was a joke, but now that I think about it, I’m actually arriving the evening of the 3rd (Friday), so if any other bikers are as well, then maybe we can get our rentals and have a Pre-Pre-Tech Ed Party Biker Run.

I had to manually edit a Visual Studio 2003 solution file today.  I changed the source control location for the contained projects, and I found it easier just to edit the solution file than to use the GUI to fix it.  One thing I found particularly odd is that the solution file isn’t Xml.  Project files are Xml, but not solution files. 

Whidbey doesn’t make solution files Xml either.  I wonder why a custom format would be chosen over Xml.  With backward-compatibility being such a high priority, I now wonder if the solution file with _ever_ be converted to Xml.

If you are interested in good design, you must check out Jeremy Miller’s blog.  He has some great TDD info in plain, distilled language.

Warning:  the following technique uses a child AppDomain and remoting.  If you don’t understand these concepts, then you don’t have a need for this technique.  If all your code runs in a single AppDomain, then all config keys will have to go in the <process>.config file.  In that scenario, if you need additional configuration, you’ll have to use another persistence medium such as a database or custom Xml file.

With that being said, sometimes it is appropriate to run some code in a dedicated AppDomain and shield it from the rest of the process.  In this case, the entry point will be up to you, and the default config file will also be up to you.  You can run a particular class library inside an AppDomain and give it a dedicated config file.  NUnit uses this technique to allow test assemblies to be configurable by naming your config file FooTestAssembly.dll.config.  In a particular application, I have several “plugin” class libraries, and I need each to have dedicated configuration.  I’d like to use the built-in appSettings because this is the “simplest thing that would work”.  Here is how I go about doing this.  You can also download the complete sample solution at my downloads page.

I’m going to create a simple console app to be the entry point for my application:

Notice how I use one configuration item in the default app.config file for this console app?  Now, here is the code for my simple class library:

There is no magic here.  It accesses config settings just like any other code would.  The trick is the context in which this code runs.  This code is running in a new AppDomain I created.  I set the configuration file explicitly to “ConfigTestClassLibrary.dll.config”.  You can use any method you’d like to “discover” what name you would like to use, but this is simple.  Now, when my AppDomain is created, that config file is automatically used.  They are isolated.  My class library code can’t access the default config file of the exe, and the exe can’t access “ConfigTestClassLibrary.dll.config”.  AppDomain completely partitions context.  Memory isn’t shared, static state isn’t shared, and configuration isn’t shared.

Using this method, every application plugin I write can run in its own memory space and own its own configuration.

Anyone who is doing TDD with .Net _must_ check out TestRunner from MailFrame.net!  It brings the hierarchy of tests into a VS pane and allows you to select and run tests just like NUnit, but from within VS.  It uses the NUnit core and frameworks internally.  It’s free for personal use, but only $49 for commercial use!  Here is a screenshot:

I excited to announce that my “Agile Methodologies with .Net” Birds of a Feather session was accepted for Tech Ed 2005!  Thanks to all who voted for it, but more importantly, I’m excited that there are many people interested in doing Agile development with .Net.

Here is a quote from the email I received:

“We’ve heard the feedback loud and clear from previous conferences: a Birds of a Feather session is a discussion; it is not a presentation, lecture or breakout session. Birds of a Feather sessions fill a niche in the conference – it is an opportunity for attendees to connect and interact directly with one another, to be part of their community.”

I hope to be able to facilitate a great discussion where we can all learn from each other.

This session will be on Wednesday, June 8th at 7:45PM.

That’s exactly what I’m doing right now.  My development shop used to be MSF waterfall and is now pushing for CMM.  This is a push from management.  It is very difficult to write good, maintainable software in this fashion.  Sure, we can crank out version 1 and maybe 2 without a hitch, but as soon as the developers who intimately know the software leave, or forget, you immediately have legacy code.  You don’t know what you can change without breaking other things.

I don’t recall from whom I heard the quote, but I’ve heard it said that:

Legacy code is code for which there are insufficient unit tests.

I could not agree with that more.  I’m the pusher for TDD in my work group, so it’s difficult getting there, but there is a significant difference in the code that is written using TDD and the other code that exists (and is being added) without unit tests.  The design is different too (TDD is design).  It is incredibly obvious that 1) the TDDed code has fewer bugs and can be changed with confidence, and 2) The other code is a ball of mystery (legacy) that you don’t want to touch for fear of unforeseen consequences.

Another Agile practice I’m pushing is automated builds.  Our build is scheduled to run twice a day.  It does everything to get the new source built an on a development server.  It runs the unit tests and reports.  I use NAnt for that, and it works very well.  I intend to hook up FxCop and CruiseControl.Net to our build process soon.

One thing I’m not sure will change is the manner in which we plan projects.  Our project managers _must_ use CMM in their planning, so it’s probably a losing battle right there.  The schedule will be set, the features will be planned, the headcount will be assigned, and then it’s expected that the team deliver 100% of the scope on the due date.  No incremental releases with requirements verification and reprioritization, but pure waterfall.  Plan phase, dev phase, stabilization phase, and deploy.  Then 5 years down the road, replace the app because it’s become hard to maintain, but create the new app in the exact same manner.  It’s quite confusing.

I also have some more general observations about much of the industry as a whole.  I’ve heard when replacing an application that “we’re going to do it right this time”.  I firmly believe that the first go-round was not preceded with the thought “let’s do it wrong this time”, yet when we identify that an app has turned out to be unmaintainable, and it needs to be replaced, why don’t we identify the reasons it became unmaintainable?  Why don’t we fundamentally change the way the new app is written because just rewriting an app using the same process as the first is going to get the same result as the first.

If an application needs to be replaced, we should analyze why it failed.  If it didn’t fail, and we just want to move to a new technology, then pieces of it should be wrapped and leveraged in the new app.  If that can’t be done, then I would say the old app failed.  It can’t be reused.  It’s life is over.  Going a step further, if you absolutely want all the code to be in the new technology, then just port the code.  If _that_ can’t be done, then the app is a failure.  The app is dead.

Agile methods, coupled with able developers,  promise (and deliver) maintainable, well-designed software that will never become a rigid legacy application.  As the word implies, the application will remain agile.

Jeremy Miller has posted a great list of tools he’s currently using in his Agile shop.  I’ve using a few, but I’d like to use more.

http://jeremydmiller.blogspot.com/2005/04/bypass-vsts-and-get-yourself-poor-mans.html

I received some good responses from my initial announcement of a party on Saturday, the day before the PreCons.

We’re only about 5 weeks away, so I need to start getting a list of people who are planning on being there.  A comment to this post is adequate.

Also, if anyone would like to help me plan the event, please chime in.

With the .Net implementation of web services, you can design the schema of a web service call without having to author WSDL by hand.  I won’t discuss contract first here.  I recognize that many are happy with the default .Net implementation of a webservice.  It is possible to easily affect the Xml format of the SOAP envelope, however.  Mainly, you need to define the Xml structure of the SOAP envelope.  By default, .Net makes nodes with your parameter names, like so:

POST /webservicetest/movie.asmx HTTP/1.1

Host: localhost

Content-Type: text/xml; charset=utf-8

Content-Length: length

SOAPAction: “http://palermo.cc/Foo”
<?xml version=”1.0″ encoding=”utf-8″?>

<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>

  <soap:Body>

    <Foo xmlns=”http://palermo.cc”>

      <firstParam>string</firstParam>

      <secondParam>string</secondParam>

    </Foo>

  </soap:Body>

</soap:Envelope>

HTTP/1.1 200 OK

Content-Type: text/xml; charset=utf-8

Content-Length: length
<?xml version=”1.0″ encoding=”utf-8″?>

<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>

  <soap:Body>

    <FooResponse xmlns=”http://palermo.cc”>

      <FooResult>int</FooResult>

    </FooResponse>

  </soap:Body>

</soap:Envelope>

What if I don’t want to expose my naming conventions in my soap message?   Moreover, I have specific names that I want for the Soap message.  I can add XmlElement attributes to the parameters to customize the Soap message:

Here is the part of the SOAP message that is changed:

<?xml version=”1.0″ encoding=”utf-8″?>
<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xmlns:xsd=”http://www.w3.org/2001/XMLSchema&#8221; xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”&gt;
  <soap:Body>
    <Foo xmlns=”http://palermo.cc”&gt;
      <ProductCode>string</ProductCode>
      <Quantity>string</Quantity>
    </Foo>
  </soap:Body>
</soap:Envelope>

Because .Net uses the XmlSerializer for Soap-object conversion, the service Xml schemas can be completely customized.  Another one of my favorite things is to return a object from a web service while ensuring the contract is explicit.  On my object, I implement ISerializable and define my format.