Archives / 2006 / February
  • Why must Microsoft tools work against me?

    Let me say that Visual Studio 2005 is a huge step forward in a lot of ways, especially for Web developers. What still sucks though is database handling quirks.

    For example, I just want to open a query window against a SQLEXPRESS database in my Web project and fire off some SQL. You know, the way we did in the old days. I want to create a table from SQL commands, and it tells me, "The CREATE TABLE SQL construct or statement is not supported." Then below that is says the query can't be represented graphically in the diagram and criteria plane. Well no shit, that's why I turned it off.

    So then I figured I'd fire up SQL Management Studio and just attach to the database. Yeah right. I try to attach to the file, and the file dialog doesn't let you type in a path, and won't navigate beyond the user name in the Docs/Settings folder (I happen to have the project on a desktop folder).

    I eventually went back to the VS IDE and did a mass check-out from source control, and suddenly the table create query runs. That's not surprising since the database is probably read-only while checked-in, but why didn't VS tell me that instead of telling me CREATE TABLE isn't supported?

    Nothing annoys me more than fighting the tools for ridiculous amounts of time to do simple things. And that's the way it always is with Microsoft tools. Usually 95% of what you do is powerful and easy, but then you lose all of that saved time with dumb shit like this.

  • Unit testing programmatic web.config edits

    Perhaps there's some easier way with VSTS's testing, but because I know not everyone has that, I'm trying to write unit tests for the programmatic manipulation of web.config data.

    So on one hand, you've got...

    System.Configuration.Configuration config = System.Web.Configuration.WebConfigurationManager.

    in your configuration editing junk. Works like a champ when you call Save() on that object. The problem is that HttpRuntime.AppDomainAppVirtualPath has no value in a unit test. The weird thing though is that you can call the above code from the test and call it's Save() and it throws no errors. It sure thinks it's saving some config data somewhere, but I can't figure out where.

    I know I'm being nutty here, but I really want to be able to test this stuff. Any suggestions?

    EDIT: Actually, the test is manipulating web.config in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG folder. That's odd.

  • Due to caching and moderation, it may not be displayed right away.

    We have an internal CS blog here at my current gig. You get this when you comment:

    "However, due to caching and moderation, it may not be displayed right away."

    Am I the only one troubled by this as being generally bad form? In techie circles, sure, whatever, I can deal with that, but would John Q. Pornsurfer care about the technical implementation? And even if they did, why wouldn't the update cache-bust the data anyway?

    Maybe one of the Telligent folks can explain the thinking on this.

  • How do you unit test an HttpModule?

    I would think that blasting through Google I could find an answer to this, but I'm not finding anything useful at all. How does one unit test an HttpModule? I can't imagine that it's not possible. I'm not sure how to fire off and test the various events or simulate the request/response lifecycle.

  • File change behaviour in v2 not so good

    As you'll see in this post from Scott, app restarts now occur whenever you add or delete a folder. That's bad news. I know of at least one application that I've written that has to add or remove folders from time to time.

    We should be able to turn this off. It seems like an arbitrary and not well thought out change.

  • More confusion about custom Membership and Profile providers

    OK, so help me out here. I was looking at the default system-generated database, and it stores the membership user reference for the profile table as uniqueidentifier. How can it do that if the current Membership provider uses some other data type? As I mentioned in my last post, I don't understand how this can be. MembershipUser.ProviderUserKey is an object, so it can take anything. It's not limited to guid's.

  • How to store the ambiguous "object" used as key to Membership records

    The ASP.NET Membership API calls for System.Object to the be the type used as the ProviderUserKey. This way, your provider can use whatever you'd like as the key field for your user records. The built-in SQL Server provider, for example, uses a Guid.

    The provider I wrote uses an int instead. That part doesn't concern me... it's what I use in other calling code. For example, I might have an Orders table that is associated with Membership users. But how do I keep it provider agnostic? Sure, the object representation in .NET can simple be System.Object, but when it's time to store something in that Orders table, how do I get object to the database?

    Any suggestions?

  • The death of People and full adoption of Membership and Profile

    Way back in early 2004, when I began writing my book, I wrote Membership and Profile providers that acted as wrappers to the People class in POP Forums, which I used for a very long time to store user data. It seemed like a good plan at the time, because then anyone could jack into the forum's user management using the familiar interface. They couldn't do the opposite though, because all kinds of junk was dependent on People, and there were several relationships in the data there too.

    But alas... what I've always wanted was that two-way street for integration. The provider model makes this easy enough, but you more or less have to let this user data live in its own little world. That was always obvious to me, but I've let my own sites and projects dictate the best way to rewrite the forum, which is stupid. That's the very reason I've had to shoehorn things into that format.

    So taking a clean-sheet approach, I've spent the last few evenings refactoring the providers and ditching People entirely. It's liberating. There will be some SQL scripting to deal with when it comes time to deploy in my own sites, but when it comes to user data, it should be the last time I ever have to do it. The benefits are already clear with some peripheral projects I want to do, and even a theoretical single-login system across all of my sites. Good times!

    I've been so energized to write code again lately. Not sure why. It's odd that when I was slacking, er, being self-employed, I wasn't motivated to do much of anything. Now that I've gone back to a day gig and talk to people smarter than me, I'm spending my free time writing my own stuff again. My personality is seriously odd.

  • Going to Mix06!

    Quite unexpectedly, I got an invite to attend Mix06 in Las Vegas next month. Normally this conference costs a grand to attend. So I'm in, no matter what it costs to get there and stay at the Venetian (where Blue Man Group also lives, I might add).

  • Locking up my code in the Vault

    After screwing around with, what did I call it, The Steaming Pile of Crap that is Visual SourceSafe 2005 in Internet mode, I remembered that SourceGear's Vault was still free for the single user. So I installed that on my server, installed the client, works like a champ from within Visual Studio 2005.

    I don't quite understand why VSS has been so neglected over the years. Aside from the HTTP capability that only works under perfect circumstances, it really hasn't changed in at least five or six years. I hope it wasn't for the sake of using Team System, because God knows anyone outside of a major corporation can't afford the server product.

  • VSS 2005 Internet install a steaming pile of crap

    Wow, who signed off on this complete piece of crap? Seriously, if you Google for "sourcesafe 2005 internet" you'll see just how many hoops people had to jump through to get the damn thign working.

    I haven't actually tried it myself, but it shouldn't be any harder than pointing a new Web site in IIS to the directory where the ASP.NET app resides. Why the hell is it so hard to get it setup.

    I haven't even tried to connect to it via Visual Studio. Can't wait to see how that goes.

  • The torture of the application recycle

    I always read about this kind of thing, but can't imagine why anyone has the problem. Right now, it's happening to my current employer's test box.

    The ASP.NET process is recycling frequently and seemingly at random. We can't figure out why. However, we did fire up the new health monitoring code in our web.config, and the app restarted because, it said, the "configuration changed."

    Well, that certainly qualifies as one of the reasons an app will restart, but no one is molesting any configuration. Any theories?

  • Exploring the hobby to middle market

    I think about the middle people a lot. I'm one of them. I'm not an enterprise architect, but I'm not a PHP script monkey either. I don't get rich off of the sites that I maintain, but I make a good chunk of change that supports my expensive gadget habit. The bulk of people like me use the LAMP stack, if you're inclined to believe the analysts and consultants. That's a bummer.

    Let's face it, I use Microsoft's platform because it's what I was exposed to, much in the same way that we typically adopt the religion practiced by our parents. Now that I'm older and wiser (hahahaha, yeah right), I tend to feel that having made a choice to go from ASP.old to ASP.NET was a good one, and sticking with my own brand of Christianity seems to be working OK too.

    But here's the thing... I don't feel like I'm being served well by Microsoft and the community in terms of getting what I need. I get along any way, but that's because of my tenacity for knowing as much as I can, regardless of what practical use I put that knowledge to. Let me explain.

    First there's the product at the core of our world: The .NET Framework and the visual tools. Best stuff ever as far as I'm concerned. This is one area where Microsoft has done a good thing, giving away the express products. That took some real balls to get the stuff out into the open for free. It's a good first move, even if they haven't done a good job about getting the word out about it.

    Then there's the issue of education. I have a lot of mixed feelings on this, and I'm sure purists will tell you that .NET, an object-oriented development platform, just isn't intended for the hobbyist and middle markets. I think that's a load of crap, because while there is a huge shift in thinking that script monkeys have to make, it's not impossible to grasp. But getting there is insanely difficult because Microsoft documentation tends to all be high level, and it's hard to read if you're a n00b. Articles around the Net also tend to talk over the new or transitional person. I'm not sure how you address this, though I think there's room for three kinds of documentation to satisfy different levels of experience.

    Books help, but far too many beginner books treat ASP.NET like a variation on script, which is not helpful. I tried to address the totally ignored middle-people segment with my book, and while people seem to like it, it hasn't been well marketed by the publisher. Then the high-level books tend to just be re-hashes of Microsoft documentation.

    I guess where I'm going with this education thread is, how do we get people beyond asking the same old questions over and over again in forums? Who really owns that responsibility anyway? Honestly I don't know.

    Finally there's the issue of good applications we can use for free, as either a base for various projects or as a learning tool. I admit that burden falls on people like me and higher. There's a lot of mediocrity at one end, and brilliance at the other end that's too hard for the middle folk to understand given their experience. I've been on a real "simple is better" campaign as of late, but it's funny how different people see "simple" as different things.

    Am I making any sense here? I want people like me to embrace .NET the way I have, but it seems hard. It wasn't easy for me, and had I not been laid off like a hundred times, I doubt I would've gotten there (let alone write a book).

  • The little Internet business that could

    There are a lot of little businesses on the Internet. Some are electronic extensions of real-world things like garage sales (eBay "workers") while others are totally new ideas that have reached critical mass (Digg). The important thing to note here is that there was little to no cost involved in getting these businesses started.

  • Testing at the end? You can't be serious

    I noticed a link to this Waterfall Conference that also a keynote called "Put Testing Where It Belongs-- At The End." I'm in awe that anyone would say something that, to me at least, is so fundamentally stupid. And yeah, I know this is a joke, but people out there actually think this way.

    Let me start that I don't get into religious arguments, whether it be about New vs. Old Testament, Linux vs. Windows or Agile vs. Everything Else. Those discussions just aren't interesting to me. However, the bigger an application gets, and the more people involved, the more I feel that test-driven development is absolutely essential to building something that works. I honestly could care less about most of the tenants of XP or agile, but TDD has saved my life.

    And I do get why people are skeptical. The gig I just started has a lot of people skeptical about unit testing in general, mostly because it's considered an afterthought. It really is a cultural shift. People think it's more work, but no one can ever ask the fundamental question, "How do you know the change you made didn't break something you haven't thought about?"

    When I first started a gig at Big Ass Auto Insurance® as a consultant, they were buying into everything agile. The paired programming thing annoyed me, and I hated it, but the test-driven stuff fascinated me. Here you could fire off the tests from the entire solution, testing tens of thousands of lines of code, and if something you did broke something, you knew about it. In fact, if you didn't run the tests, the continuous build process would tell you that something was broken. Without this testing facility in place, you had to rely on poor metrics like a lack of compile errors, peer reviews that assume someone in the room knows the rest of the system, etc.

    This doesn't even get into the trouble that is test bias. You can't write unbiased test code if you've already written the code. You're too close to it. While unit testing assumes you're doing thorough tests and driving the design of your classes from those tests, it still gives you confidence your stuff works.

    Now regarding the waterfall methodology, most of the instances where I've been around it, it fails, or delivers low quality software. Again, I'm not religious about any one methodology, but anyone who has written one line of code knows that stuff comes up, and specifications frequently have to change. I don't know why people try to fight that. Keep the stakeholders involved at all times and the change management is tolerable. That's one of the things I like about a more iterative process, is that you can refactor to a place that you get what you want and need, not what you thought three months ago you wanted and needed.

  • Directions on forums and writing

    After I finished my first book, I started to think about what I'd write if I did another one. I wouldn't write anything if it wasn't something I was interested in, so it had to be relevant to my interests. I discussed a book with a couple of publishers that was based around the end-to-end creation of a significant ASP.NET application, namely POP Forums. At the time, v8 wasn't much more than a idea (and still is hardly where it needs to be), so it seemed like a good idea at the time.