When writing services, I often find myself having to attach to processes manually from within VS.NET. When you can't simply run the code directly from VS.NET and step your way through it this is a common choice. Every time I have to do this though I cringe because I'm walking on thin ice. Sometimes it doesn't work, or you hang, or weird things seem to happen.
I was having a particularly difficult time with a client yesterday who was debugging through some HTTP handlers when I remember a question from one of the MCSD.NET exams that clued me into the fact that you can programmatically cause a break point - that's right - I said “programmatically“.
That nifty little class & function call will bring up a dialog box offering to allow you to attach to a new instance of VS.NET or an existing one you might have open - similar to when you get an unhandled exception. For this to work the user running the process requires UIPermission. Not surprisingly the default aspnet user that asp.net normally runs under when the machine.config processmodel section's user is set to “machine” does not have this permission by default. If you are a developer running IIS locally, consider temporarily changing it to “system” or some other user but be careful because doing so causes asp.net to run under the local system account - which is a security risk.
Too bad there is no T-SQL version of this function - maybe in Yukon.
I haven't had much chance to use many of the cool things in Windows 2003 to date, but one of the new things (that incidentally also runs on XP Pro) is a new mode of Active Directory called Application Mode - in total ADAM. I'm finally getting to do some real playing around with this for a large application I've just started working on for a client.
It's basically a standalone active directory that is ideal for storing your own users and roles etc. to be used by your application in an active directory style - even if your company isn't using active directory. If you do go to AD down the road - it's a simple migration for your app. ADAM also acts as an LDAP server as well which makes it a bit more open. You can really put whatever you want into ADAM as it's schema is extensible (not unlike Active Directory). The idea though is that you can have multiple instances of ADAM installed on your server - each containing data specific to a unique application - while AD would store more globally required data throughout the enterprise.
It's pretty typical to store this type of application specific data historically into a SQL database. While that's possible, ADAM - and more specifically the underlying AD is more geared to this type of data. A relational DB remains an ideal choice for transactionally updated data, but ADAM is a great place to store any kind of administrative data that is, for the most part, written to once, and then read frequently by your application.
I'm going to be playing more with this, and specifically doing some performance testing and seeing what kind of improvements can be made by using it in the middle tier, caching some of the data in a wrapper object that is hosted in COM+ and pooled.
As an aside, I find it kind of strange that Whidbey - and specifically the new ASP.NET membership/roles stuff that is built in doesn't use ADAM - but instead opts for the classic database solution. Fortunately the membership/role model in ASP.NET Whidbey is an extensible provider model so I may just take a crack at creating my own provider that uses ADAM.
I should probably google that now as someone has probably already been there and done that.
Wow I missed a whole month blogging. It was a busy one. I was off for a weeks vacation (which really just meant I had 4 weeks worth of work to cram into 3).
Upon my return I found out that I've been awarded the position of MSDN Regional Director. I had a meeting with the local MSDN folks last friday to discuss it and I'm quite excited about the upcoming year and honoured to be in such good company.
I also heard that Bruce Johnson was awarded with an Visual Studio.NET MVP award from MS as well. It's been an exciting month around here.
So far so good.
When we last met I had installed Whidbey and the .net framework 2.0 on my production machine along with VS 2003 and 2002.
I haven't found a problem yet. I gave a demo at the CTTDNUG last Wednesday and it went OK. Well nothing went wrong that I didn't expect to using alpha software.
Also since then I have been developing an windows application in 2003 with no problems.
Not sure what will happen when I try to upgrade to Beta.
A comment made by Udi Dehan on my most recent article (the Benefits of a Service-Oriented Architecture) got me thinking. In the comment and on his blog he has been contemplating the differences between OO and SOA and, more importantly, how programmers can adjust.
First of all, I believe that the idea that the debate is an either/or proposition is wrong. Not everything should be represented as a service. Nor should everything be represented as an object. There are times when the interface represented by a service layer is the better way to go. However, even for the more devout SOA believers, that idea that the implementation of a service won't contain objects is ludicrous.
That having been said, I believe that designing using SOA is more of a mindset than a programming style. And the trick to becoming proficient is to be aware of the differences between OO and SOA, at the conceptual level. At first glance, it might seem that the main difference devolves into an argument about Remote Procedure Calls (RPC) versus document-based method calls. However, I believe that the distinguishing characteristic is actually more likely to be statefulness than the calling technique.
In a traditional object-oriented application, the typical sequence of steps to invoke a method is as follows:
- Instantiate an object
- Optionally set some property values
- Call the method, including any necessary parameters
- Wait for a response
Inherently, these steps are stateful. An instance of the object must exist before the method can be called. Properties in the object can be set, either through the constructor or by direct assignment. The fact that these properties are available for use within a method means that the object maintains state.
But what about static methods. It is possible to define a method on a class that doesn't require an instantiated object to be used. The methods don't have access to the instance-level properties and methods. How could they? No instance has been created.
However, even static methods can be stateful. Classes can also define static properties. Static properties can be assigned values, values that can be used by static methods. Therefore the mere inclusion of static methods is not a sufficient condition for statelessness.
“But wait a second”, you say. “What if the static method didn't use any static properties? What if all of the external values required by the method are included in the parameter list? Surely that's not stateful!”
Of course, you'd be right. If all of the required information is available to a method through the parameter list at the time of the call, it is no longer a stateful operation. But here's the real kicker. Convert the parameter list into an XML document. Pass the document into the static method and you have just created the skeleton of a service. A message (the XML document) is passed into a service provider (the static method) which intrinsically knows how to process it.
And therein lies the difference between OO and SOA. It's not that the two aren't related. It's that SOA is much more demanding about how programmers interact with it. Kinda nice when knowledge sneaks up like that, isn't it?
Dave gives an in-depth look at the next release of .NET: Visual Studio .NET 2.0 (code-named "Whidbey"). This release of Visual Studio and the .NET framework will offer innovations and enhancements to the class libraries, CLR, programming languages and the Integrated Development Environment (IDE). He will share the latest material from the Microsoft PDC in L.A. and from the Bigger Better Basic tour. Attend this free event and learn how you can architect your applications today to ensure a smooth transition to the next version of .NET. More information and registration can be found at the Canadian Technology Triangle web site
Well I've done it. They warned me not to but I did it anyway.
I installed Whidbey on my machine along side 2002 and 2003.
I'll post any trouble I have right here.
I'm spending this week in Los Angeles. Not the vacation from the cold that you'd be thinking I on, however. I'm at the L.A. County Coroner installing some software that has been a while in coming. To put it into perspective, the app is in VB6 and I have SQL Server 7 on my development environment to support it. Which means that I'm unlikely to have anything blogworth based on my experiences here.
What is interesting, if you have a sense of humor about death, is the the Coroner's online store. Called Skeletons in the Closet, it offers a wide selection of Coroner emblemmed merchandise, as well as some shirts, cups, hats, key chains and mouse pads decorated with the requisite chalk body outline. Honestly, I can't accurately convey just how cool this stuff looks. Do yourself a favor and check it out at http://www.lacoroner.com. It'll knock you dead.
I just noticed that the dates for the VSLive converence in Toronto are now available. May 4-7, 2004. Mark it on your calendar, book your flights and get ready to rock. And, for those who are wondering, temperatures in Toronto are usually above freezing by that time of the year. ;)
For all those who are interested, I have just posted the latest article in my series on service-oriented architecture, called Jumping the Hurdle: Moving from OO to SOA. Read, learn, be amused, be bored. Feel free to let me know where on that spectrum you fall.