Finally, a way to pack dBase files in .NET. Something we've been looking how to do for a LONG time at work.

Really, its just a query that you call on the dBase file, and you need the Fox Pro driver, but alas - they say it works.

As a followup to my blog post yesterday, my boss decided to throw a new one at me - give an example of how we can use NUnitASP for our projects as another form of TDD during the project life cycle. Well, I hadn't used NUnitASP before, so I jumped right in following their step-by-step tutorial for newbies. Sure, the tutorial wasn't a real-world example, it did give you an idea of how things work and what needs to be done.

So, after my success with that, I decided it was time to take one of our applications for a test ride. Well, this application so happened to be built on a custom portal framework we developed, and things started to go wrong for me from the very beginning. I first tried to get to the first main page, the login page, and grab the username & password text boxes in a test.

Problem 1: NUnitASP took me to the default page, which sets a cookie and redirects the user to their homepage. Well, NUnitASP didn't do the redirect, so I was stuck with a page that had no controls. Solution was to grab the URL manually (which have a few different query string parameters that vary depending on your user/role/application using/page viewing).

Problem 2: NUnitASP needs to grab the controls via HTML ID. Ahh, so I just plopped in "tbUsername" and "tbPassword" - what? It can't find them? Solution was to fully qualify them as "_ctl5_tbUsername" and "_ctl5_tbPassword". This doesn't really make writing tests easy for data driven portals that vary on the modules that are displayed...I mean, how am I supposed to know the unique prefix that is added.

So, from my two problems I just listed, I've come to the conclusion that NUnitASP cannot (as of this blog posting) be used in Portal based webpages. My reasons are as follows:

• You need to know the exact URL to a page to test, initially at least. If you're page's are dynamically put together with different modules based on you're user, role, and query string parameters, this could vary from time to time, thus breaking your tests which require modifying your tests...not a good practice.
• You need to know the exact HTML ID of the element you're trying to write tests against. This is a good design if you're pages are darn near static (in the sense that the way they're loaded is not data driven), and are not contained in User Controls (this may work, but the same logic applies) because you know what the HTML ID should be when writing a test. However, if you're using a portal, you will most commonly not know the unique name of the control, which could in turn change from time to time, again (revisit my last statement above, it applies here too).

Although I say NUnitASP is not a good framework for portal based solutions, I do see it as being a very viable framework for pages that are not dynamically created. Maybe this is something that will possibly change in the future, however I'm not sure if or how it would. What are your thoughts on TDD of portal based application UIs?

Update: I missed the "UserControl" tester object that can be used for accessing User Controls and controls within those. However, this will still not work for dynamically created UC's that are added that don't have a distinct ID that is set, IE - portals.

I just ran across this very well stated newsgroup posting (to microsoft.public.dotnet.general):

"I would like to share my disappointment of Microsoft with you readers. Be
aware that I'm in no way a Microsoft "basher" and that, in fact, I use their
programming technologies everyday. More importantly, I find these
technologies quite useful and, most of the time, very well done.

But I'm currently quite fed up with what Microsoft is doing with the next
generation of the .NET Framework. It has absolutely nothing to do with the
functionalities, far from that! It seems like a terrific new product. The
.NET runtime environnement really impressed me from the start and it will
continue to. But the problem here is that MSDN, and all the ressources at
Microsoft, seems to focus on a product that is not out yet.

On MSDN, the majority of articles seems to be "how to do that on Whidbey",
"How Whidbey is great for that", "How life is wonderful with Whidbey", and
bla bla bla. But hey guys, the majority of your readers can't even test the
little example you put in your great articles about Whidbey! Why should I
care? Out there we only have the .NET Framework 1.1 to work with. There's
not even a beta version of whidbey that I can use to experiment with this
great new environnement! Why focus on a product that is not out yet and,
from certains informations, will not even be in the current year!

I was a very "patriotic" reader of MSDN for the great number of quality
article that it propose. But now, I just go there from time to time to
realize, each time, that they talks about something I can't use and will not
be able to use for the next year or so. Imagine a computer hardware magazine
that do mainly reviews of product that readers will never be able to use
before one or two years? I want programming information that is useful for
me now, not hypothetically in the future..."

After reading this, I actually agreed with the poster. Although, I do have to say I do have access to the March bits of Whidbey, so I can test those examples. However, like the poster said, the majority of people cannot currently test that information. My only rebuttle to the poster is that the information is very good and right on, and when the Beta is finally released (sometime this summer), you'll have an abundance of reference articles that you can go by, and will not be having to wait around like most of us right now to get some good examples and explanations of things.

Wally just pointed out a new data provider for .NET that will allow developers to talk directly with AS/400 servers. I don't know how many times we've had to access data on AS/400 systems in a round-about way. No more will we need to use DTS in SQL Server to transfer data over on a nightly basis!

Thanks Wally!

I'm sitting here at work building an application using TDD (which by itself is another post, and may be coming later), and every time I start a new class for another piece of the puzzle, I'm hating on how I have put the keyword "sealed" class in my declaration. Now, this isn't a major issue, but it can be if you plan on releasing an API for customers to build against. What's my issue? Well, I'm wondering if the "sealed" and "notinheritable" keywords should be applied by default in Whidbey.

My proposition comes from the fact that it is good design practice to have your classes become "sealed" or "not inheritable", that way your users cannot accidently inherit and break changes with your API. In practice this is a big deal, and how often are you building an API, and you become lazy to allow the default attributes/keywords/accessors be applied to a API (classes specifically, making them public instead of private or internal/friend)? I'm almost betting very frequently.

I propose that in Whidbey, and future versions, that "sealed" or "not inheritable" be applied by default to all new class declarations created by the IDE. This way, you have to make an effort and think about what you're doing when removing this keyword, and hopefully make you think if you really need to do so. 

As of right now, I realize that this can be accomplished by editing the templates used somwhere deep within the directory structure of VS.NET, so please don't tell me I can do this now. What are you're thoughts, feelings, objections to this?

My team at work is starting to look into using the Extreme Programming (XP) model, and as such I've started to do some reading up on it...and determined that its driven highly on TDD. This is something, unfortunately, I've had no experience with.  So - I downloaded NUnit and started working with it, and (like always) I was trying to find the most streamlined way of running my tests.

The NUnit GUI wasn't bad, it does what it needs to do...however I wanted something integrated into VS.NET.  Sure enough, my praryers were answered when "NUnit Testing Integrated in Visual Studio" came out on TheServerSide.NET. So - I downloaded TestRunner, and started giving it a whirl.  Its a bit cumbersome to figure out how to make it work...its not too intuitive, as the buttons don't have any tool tips, but the FAQ does give you a description of what each does.

Anyway, I suggest using this tool, its very cool and allows you to not leave the IDE at all.

Through my normal routine of reading/responding to Microsoft newsgroups, a question came up about "100% Managed Code" phrases that companies use.  Specifically, the user was asking about a PDF component advertising it as such, and was just wondering if it was possible that they were using the Adobe APIs still.  Well, my response basically stated that since they're advertising it as "100% Managed Code", that it probably doesn't use Interop, and has built on the described api.

This has basically made me start thinking about the term "100% Managed Code", and why companies use this.  As I can see, this may be a nice selling point to business managers and what not, but it really doesn't play into a developers mindframe when they're checking out components (unless there is a defined restriction set forth by their company).  I for one have been seeing "100% Managed Code" for several years now, and always disregard what they're saying, only because I don't care.  So what, its "100% Managed Code", does it work?  If you say yes, and I don't need to purchase anything further I'm sold.

So, why is this a big deal?  Well, I feel that some companies may misuse and overuse the phrase "100% managed code" just because its hip, cool, and "the" thing right now.  Okay, okay...so does that mean I can advertise all my free server controls as "100% managed code"?  Well, sure...I mean, I use C# to build them, they need the .NET framework to run, why not.  Well - DUH - of course my controls are "100% managed code"...otherwise you really wouldn't be able to use them...which is the main reason its implicitly dubbed "100% managed code".

However, the biggest gripe I have, is with those companies that release a new component or tool, and just to add hype, they state "100% managed code" and, lets not forget "Built on the .NET framework!"  Wow, thats amazing...or is it?  In this day in age, you're seeing a lot more applications being built on the .NET framework more and more, but why are companies still overusing and misusing this phrase? I think its a increasing trend that has absolutely no affect on how I look at 3rd party components when determining if they'll work for what I need them.

So whats my point?  Think about your descriptions of components/tools, and how is it going to appeal to the common developer.  Are we going to be amazed that it works - probably. Do we care that its written entirely on the .NET framework, not as long as my previous statement holds true.  Remember that about 95% of the time, its developers that are given the task of finding a tool/component that solves a certain problem, not a business manager - so why do we need the hype?

Well, I'm sitting here, struggling...struggling to find out how to get the active build configuration from a visual studio project file.  I've been studying the XML file, and there is absolutely no where that denotes what the active build config is.  I've also looked in the project.user file as well as the solution file, still...no luck. Would anyone like to share how you determine the active build configuration?

C|Net is reporting that a new interim "technology preview" of Visual Studio 2005, aka "Whidbey", will be distributed next week at VSLive in San Fransisco.  This is awesome!  I hope they plan on releasing that same build to MSDN subscribers.  Any word from the Microsoftee's ?

Ever got this message attempting to open a solution in VS.NET 2003? Well, the full error message is "The web server reported the following error when attempting to open or create the project at the following URL: The http redirect request failed." A co-worker ran across this multiple times on Friday, and got entirely fed up with the problem that he'd have to refresh the entire project from VSS or delete the /bin directory each time. I guess the root cause of this is something with the page named: "get_aspx_ver.aspx". After a call to MS, he came back with a solution:


protected void Application_BeginRequest(object sender, EventArgs e)
{
  string ver = Request.ServerVariables["URL"].ToString();

  if(ver.IndexOf("get_aspx_ver.aspx") >= 0)
    Response.End
}


After the previous code was added to the global.asax file, our solutions started opening without any problem.

[Previously Posted on old Weblog on August 18, 2003]