Reminder for Others - VS.NET 2005/2003 ASP.NET Compatibility

As Dave Totzke has noted in the past, one of my reasons for blogging is to remind me of things that I'm likely to forget in the future and that I had a difficult time finding solutions for in the first place.  This particular blog is intended to help both me and anyone else trying to run ASP.NET.

The situation is as follows:

I'm running both VS.NET 2003 and VS.NET 2005 on the same machine, because I'm doing a little bit of work in both environments.  This particular project had me creating a web service in VS.NET 2003.  Tried to debug the web service and ran into a problem, that being an "Error while trying to run project: Unable to start debugging on the web server" message.  Now my memory was jogged.  The problem is related to the fact that the installation of 2005 meant that all ASP.NET apps were running using the 2.0 version of the framework.  So my search became more along the lines of "how do I fix this?"

The ultimate answer is to run the aspnet_regiis command for the Framework version that you want to debug against.  But that isn't the best solution.  An an alternative, take a look at Denis Bauer's ASP.NET Version Switcher utility.  Using this tool, you can target particular virtual directories making them work against the Framework version of your choice.  Very nice if you're mixing your development platforms. 

Defining Alerts for Sharepoint Users

Here at ObjectSharp, we use Sharepoint on a regular basis to collect documents, discussion threads and tasks about the different projects that we work on.  One of the problems I've always had is that, although it is simple to add a new workspace and add users to it, the users had to log into the workspace in order to start receiving notifications.  John Lam's term for this (OK, it's probably not his term, but he uses on a regular basis :) is 'friction'.  And friction keeps things from happening.

Given this not ideal state of affairs, imagine my joy when I came upon a blog entry by Jan Tielens describing a web part that will fulfill my fondest dreams.  Or at least this one. Thanks Jan for making my life a little bit easier.

Risk: It's a 4 letter word

Risk is bad. But it doesn't have to kill you if you acknowledge, plan for and manage it. The most important part of risk management is to avoid the evil consequences as soon as you can in your project. Having risks show up the day before a delivery date (or later) is really really bad.

Both the Rational Unified Process and the Microsoft Solution Framework do good jobs at addressing perhaps one of the most important project management practices. I recommend to clients to make risk management a part of their team meetings - weekly if not more often. As a team, we need to identify, analyze and prioritize risks so that we can plan to deal with them effectively.

As part of identifying and analyzing risks is to accurate assess the consequences of the risk should it happen, and while this might seem silly, an accurate description of how we know the risk has turned into a problem. That may be a drop dead date, or some other description.

A good way to prioritize risks (using MSF) is to rank the impact of a risk should it actually happen. Combine that with a probability of the risk occurring and multiple them you get a probable impact or in MSF terms, Exposure. Ranking by Exposure will help you quickly identify what risks you should spend some resources on trying to mitigate.

All of this is described in more detail in the MSF Risk Management Discipline v. 1.1 pdf.

You can also download a couple of nice spreadsheets as part of the MSF Sample Project Lifecycle Deliverables which includes a huge array of other types of documents related to MSF. But I recommend starting with the Simple Risk Assessment Tool.xls at the very least.

BizTalk 2004: New Training Course for Developers

We now have a course available for BizTalk 2004 in our Toronto office. I get so many of these requests about BTS2K4 these days. Matt Meleski, who is our BTS guru is teaching the first one on July 5th. Matt's been using BTS 2004 right throughout the beta.  BTS has improved dramatically over 2002, it's quite amazing. I hope I have a chance to sit in on part of it.

White-box Unit Testing - in whidbey

James Newkirk shows how to write a white-box test in Whidbey He shows how to test the value in a private field and invoke a private method. While you can (not so) easily do that today in NUnit, he demonstrates the PrivateObject class that lets you easily invoke private methods and look at private fields.

Could this “PrivateObject“ class be used for evil? Yes it could be used for evil - I imagine - but no more evil than that of reflection.

James has some great holy war type feedback about Should I or Shouldn't I white-box test. Those who say no probably haven't fought with unit testing a singleton class where we have to test it under multiple configurations that *normally* get set during the initial (private) constructor and/or the private methods called by the constructor. So yes, I can see a use. Is this an excuse? I haven't really thought of another technique....but to quote Michaelangelo, “I am still learning...” (via a silly set of fridge magnets I saw at Chapters today). The silly part of course is how one can learn from (and quote) a famous historical figure through something as silly as a fridge magnet.

Smart Client Deep Dive

Myself and Adam Gallant delivered an MSDN Deep Dive last week about developing Smart Client applications. I covered the overview & secure data access sections. The samples and IssueVision (1.0 C# & VB) along with the slides are available over here. Thanks to those who came out.

Update: If you want to take advantage of getting this stuff (and more) on the DevDays CD, you can fill in the form here.

TechEd (Day 3): Hands On Lab Manuals downloads available to the public

No need to have a TechEd commnet password. You can download ALL the pdf's for the plethora of topics. Some good stuff to see how the newly announced stuff (Team System, etc.) works.

Update These links are broken, give this a try: http://www.msteched.com/TechEdLabManuals.aspx

TechEd (Day 1): Balmer's Keynote & Announcing VS 2005 Team System

It's official. I'll post more thoughts and analysis about this as time permits, but, things you should know.

  • Microsoft now has a new Team version of Visual Studio to be delivered “Next Year“ according to Balmer.
  • new source control - more details to follow.
  • Project Management - so dev's will be able to see “Work Items“ in their IDE. There is also supposed to be a sharepoint portal of some kind that dev's & pm's can go to see a dashboard view of a project, milestone's, etc. integrated with MS Project Server.
  • Unit Testing - yes, a very NUnitish thing built right into visual Studio.
  • Code Coverage - yes in the editor you can see what code was executed and what was not.
  • Static Code Analysis - a la fxCop integrated right inside of visual studio.
  • Check in Source control process policy, so a manager type can say “if you check in something, all tests must pass, all static analysis rules must pass, and your code coverage must be 100%“.
  • Also showed was some Load testing stuff that is going to be better than Application Center Test - more on that later.

Of course whitehorse class modeling & SOA designer were showed quickly. Nothing new to announce yet on that front that wasn't covered at PDC....although the guy doing the demo kept saying “Services Oriented APPLICATION” designer. Is this new? Is he changing the acronym from Architecture?

TechEd (Day 0): BOF36: Integrating Unit Testing Tools and Practices Into the Software Development LifeCycle

This BOF went pretty well and a huge thanks to Jim Newkirk for assisting in the delivery. He's a real authority on the practices around NUnit and a good guy to have a round. If you buy his new book on Test Driven Development with Microsoft .NET onsite at TechEd, you can probably catch him at the MS Pavillion to sign a copy.

Some interesting points discussed:

  • Using Unit Tests to drive “example code“ for a framework or class library would be a nice to have.
  • While Code Coverage statistics may satisfy external parties that we've tested what we've developed, percentages are not an accurate measure of code quality.
  • If you write your tests after you do you coding, you already have too much information about your classes that negatively affects how you test.
  • Testing first can really influence (positively) the design of your classes.
  • Developers will work aggressively against source-code check in policies that stipulate a % of code as been covered in unit tests, and that the tests pass, and that they pass static code analysis.
  • It's difficult to test User Interface code, and for a bunch of reason's, not a really good idea or worthwhile investment because the only person who can see your application from the outside in, is through the eyes of a specific user - and you'll never be able to approach that.
  • At the end we also got into some of the difficulties of testing against a database and a bit about Mock objects. That would probably be a good bof on it's own.

Jim might have more comments, but the general feeling I got was that people still need more education about automating unit tests and that not a lot of people are doing it today, let alone Test First. Jim also mentioned that he didn't think it was possible to lecture to somebody and convince them about Test First, but more that it was something that they just really needed to see for themselves. I agree.

Objects and Web Services

I've  been asked this question enough both on-line and in person that I thought a blog might be a better way to clear up a common misconception. Consider the following situation.  Your application has implemented a class as follows:

public class Dog
{
   public string Breed;
   public string Fetch()
   {
      return "stick";
   }
}

As well, the application has a web service method defined like the following:

[WebMethod]
public Dog GetDog()
{
   return new Dog();
}

So let's move to the client side. In a typical .NET application, you would add a web reference pointing to the web service that includes the GetDog method just described.  Under the covers, Visual Studio .NET invokes wsdl.exe to generate the proxy class. Because of the magic of this tool, not only is a proxy for the web service created, but so too is a class that represents the Dog class that is returned from GetDog.  This means that, on the client side, there is no need to deploy the assembly that implements the Dog class on the server-side.  Or does it.

If you open up the .cs file generated by adding the Web Reference (you might have to “show all files” in the Solution Explorer then navigate to below the Reference Map in the Web Reference - the file is called Reference.cs), you will find a class called Dog defined. Does the automatic addition of the Dog class make it easy for developers to work with web services?  Yes. Does it cause some level of confusion?  Definitely.  Which is the reason for this post.

Take a close look at the Dog class in Reference.cs.  What you will see is a class that contains all of the public properties that were exposed by the server-side Dog class.  What you will *not* see is any of the business logic that might have been implemented in the server-side Dog class.  Nor will you see any methods, public or otherwise.  In other words, these two classes are absolutely not the same class, regardless of the similarity in naming. 

What kind of problem does this cause? Say you actually deploy the server-side assembly onto the client and try to pass an object of that type (the server-side Dog class, that is) into the web service method call.  The result is that an apparently inexplicable InvalidCastException error gets thrown.  The reason for the exception is because the server-side Dog class is not the same Dog class defined in the proxy class.  That should make sense now, but it throws a lot of new web service developers for a loop.

There is a solution to the problem.  Once the proxy class has been created, edit the Reference.cs file directly.  Remove the Dog class from that file and change the return type for the GetDog method to match the server-side Dog class.  Now the InvalidCastException will go away.  Keep in mind that, should you decide to refresh the Web Reference, then you will have to make these changes again.  So when I do this kind of manipulation, I would typically use wsdl.exe manually to create the proxy class file and they add it into the project.  This eliminates the potential for wiping out the changes accidentally.