May 2004 - Posts

• New source control: The most important "feature"

  Today's news of the new Team features in VS 2005 are certainly compelling, but the most important feature has yet to be disclosed (AFAIK): Is Microsoft using the new source control? If not, will they when it's more mature (before RTM)? It's no secret that products that aren't dogfooded aren't as good as they could be. VSS is a prime example of this. The product has been essentially the same for far too long, and even the simplest of features are lacking: Create a label. Rename a labeled file. Pull the label. Oops! We've recently decided to move to Perforce (although we haven't actually done the move yet) for a number of reasons, but primarily because of VSS's branching model. The timing of the move isn't vital, but we are about to embark on a new version of our product suite and now is probably the best opportunity we'll have in the near future. If Microsoft is or will be using this new source control, it could influence our decision and potentially reduce some pain in the future. If they aren't/won't, then the decision is already made. Does anyone have the low-down on this? Posted May 24 2004, 09:24 PM by jeffreykey with 8 comment(s) Filed under: Apps, Platform

• XP vs RUP: Which is better for the less experienced?

  Martin Fowler has updated his IsAgileForAll bliki entry with a pointer to a fellow that should know: He teaches a class that uses both. Posted May 24 2004, 09:02 PM by jeffreykey with 3 comment(s) Filed under: Development

• VS 2005 -- Now with integrated testing and code coverage

  Excellent!  Read all about it. One great feature is the “generic test”, which lets you run an external app as a test. This should help cut-over time from existing apps like NUnit to the new framework. Update: Jesse Ezell points to a bunch of screen-capture demos showing off the new features of VS 2005, including three test demos. Great to see this stuff in action. These demos show: Load testing a web app Adding perf counters Setting a number of testing parameters Adding rules/validations  Smart counters that display warning and critical threshholds Binding input parameters to a database And much, much more! Library tests Things you're already doing with NUnit Code coverage Note that at least one of these requires a TechSmith codec, available for download here. Update #2: It just keeps getting better! More testing screencap demos here. Posted May 24 2004, 07:10 PM by jeffreykey with no comments Filed under: Apps, Development, Platform

• Getting the true type of a parameter passed by ref or out via reflection

  [Update: I posted a bit prematurely. Mr. Pisk called me out on it and I've since made a correction. I apologize for any confusion.] Getting the type of a parameter passed by value via reflection is simple; however, if the parameter is a ref or out, the story's a bit different. For example, a ref or out DateTime parameter's type is actually DateTime&, which is not the same as DateTime and type equality comparisons will fail. Luckily for us, the solution is easy. Instead of calling ParameterInfo.ParameterType, you need to call ParameterInfo.GetElementType(). Type also has an IsByRef property that indicates wheether you need to call GetElementType(). public static Type GetParameterType(ParameterInfo paramInfo) {     Type paramType = paramInfo.ParameterType;     return paramType.IsByRef ? paramType.GetElementType() : paramType; } Posted May 23 2004, 01:13 AM by jeffreykey with 3 comment(s) Filed under: Development, Platform

• If you're holding your breath waiting for ObjectSpaces, you better stop

  If you've been following ObjectSpaces since it was publicly acknowledge who-knows-how-long-ago, this won't surprise you: It looks like ObjectSpaces won't ship until the Longhorn time frame. Mike Gunderloy shares his thoughts and links to a Jesse Ezell post with much more information. Jesse Ezell is among those covering the removal of ObjectSpaces from Visual Studio .NET, its merge with WinFS, and its slip to the Longhorn timeframe; his entry is worth reading because several object/relational mapper (ORM) vendors post their comments as well. ObjectSpaces was announced as a Microsoft technology back in 2001, so it can now be added to the long list of things (including WinFS itself) that were promised and then not delivered anywhere near on the time scale that Microsoft led people to believe. Whether this is just a continuation of the FUD policy that once served them so well, or continued inability to come up with realistic schedules (I incline towards the latter explanation but do not rule out the former), it underlines yet again an important principle: don't base your own ship dates on what Microsoft says will be available. Posted May 22 2004, 07:34 PM by jeffreykey with no comments Filed under: Platform

• More "journalist" FUD

  It's no secret that I have almost no respect for most of the “journalists” that cover our industry. My inbox is full of reasons why every morning and today it contained yet another perfect example: Promising fast and efficient PC and network searches is the goal of BlackBall's BlackMagic, especially in the wake of Microsoft postponing the release WinFS until 2009. ZDNet's David Berlind talks with BlackBall Chief Executive Bob Brown. WinFS is postponed until 2009? A hyperlink points to an article from last week (emphasis mine): Microsoft does plan to include WinFS in the client version of Longhorn, which is expected to ship by mid-2006. And Muglia said WinFS will be included in the server version of Longhorn, slated to debut in 2007. However, "some of the functionality of WinFS and some of the scenarios may be limited in terms of what it can do. I don't know that we will have all of the scale to the level where we would like to have it, so that you could use it for very high-volume enterprise servers," he said. Eh? Wha? Some probably see this as anti-MSFT, but really I think it's just incompetency and makes me question the state of “journalism” in the industry. I need to get my industry news somehow, but things like this seem far too common and aren't confined to one or two sources. Am I missing out on a respected, competent news source? How do you keep on top of what's going on outside of your little corner of the world?  Posted May 19 2004, 10:30 AM by jeffreykey with 8 comment(s) Filed under: Beef, News

• Forget IT outsourcing, we need to outsource lawyers

  From today's WinInfo: The California lawyers who settled the state's antitrust case against Microsoft for $1.1 billion are asking Microsoft to pay as much as $3000 an hour for their services, an amount the company correctly describes as ridiculous. One lawyer who charges $3000 an hour is billing Microsoft for almost 6200 hours of work, and another 34 lawyers assigned to the case are charging the rate of $2000 an hour. The lawyers are also asking Microsoft to pay $1000 an hour for administrative work. "Extraordinary deeds warrant appropriate recompense," Lead Attorney Eugene Crew said in his request for the fees. You know what I think? People hate lawyers for a reason, and sometimes stereotypes are true. These particular lawyers are jerks. Indeed. Posted May 14 2004, 01:22 PM by jeffreykey with 5 comment(s) Filed under: News

• Extend TreeNode, place on Clipboard, do not pass Go

  File this one in the Bugs category of your long-term memory: You can extend a TreeNode and place it on the clipboard, and the clipboard will tell you it's there, but you can't retrieve it. This is a known (but not well enough) bug. It's times like this that I really wish publicly acknowledge bugs were in a place other than nested nine layers deep in a message in the newsgroups. Posted May 14 2004, 12:31 AM by jeffreykey with 4 comment(s) Filed under: Platform

• Get your hands off my queue

  Need exclusive read access to an MSMQ queue? .NET gives you an easy way to do this, but a not-so-obvious way to give up the queue. To obtain a “read lock“ on the queue, simply set MessageQueue.DenySharedReceive to true. From the docs: DenySharedReceive specifies the shared mode of the queue referenced by this MessageQueue. Set DenySharedReceive to true to indicate that only this MessageQueue should have access to peek or receive messages from the queue with the specified Path. If another MessageQueue or another application is associated with the same queue resource, that instance or application will not be able to peek or receive messages, but it can still send them. If DenySharedReceive is false, the queue is available to multiple applications for sending, peeking, or receiving messages. Unfortunately, simply setting DenySharedReceive to false didn't allow others to read from the queue. I had to unsubscribe from ReceiveCompleted and close the queue. YMMV. Posted May 12 2004, 10:49 PM by jeffreykey with no comments Filed under: Development

• Re-throwing exceptions

  I was going to write a bit about properly re-throwing exceptions, but (luckily) remembered Brad's post.  If you haven't read it yet, do it now and pass the info along to your friends.  The people reading your call stacks will thank you. Posted May 11 2004, 09:02 PM by jeffreykey with no comments Filed under: Development