Skip to content

Iloggable

  • in net
  • 1 min read

VS.NET 2k5 final and Nullable types

Got the official release installed and had to make a couple of changes to my nullable code that was written against Beta 2. All good, though. It was just taking out hacky crap that branched on INullableType in generics code. Glad to see that nullable types are null when boxed now. Way to go CLR team!

However, the ADO.NET stuff isn't quite there yet. But at this point it's not so much a nullable type thing instead a matter that DBNull just isn't null, so you can't just cast a return value to a .NET type. Still makes writing typed DB interfaces a bit annoying. But with generics, it's at least worlds better than it was before.

  • in rant
  • 1 min read

Joe Jobbed

Looks like claassen.net got Joe jobbed. For the past two weeks or so some bastard spammer has been using claassen.net as their return-address domain. And so i've been getting a lot of bounce mails from all over the world. Fun.

First thing, of course, i made sure I wasn't compromised and my hosts was actually being used for the spam. From examining the headers of the messages bounced to me, it looks like the originating hosts are a bunch of zombies, so there isn't even any use in contacting the owners of the hosts that sent the spam.

For now, i'm just going to sit tight and filter incoming messages. Hopefully, the next rev of the zombie moves on to some other unlucky domain owner. And equally hopefully, i won't be on some blacklist because someone didn't check the origination of the spam. Ho hum.

  • in net
  • 2 min read

Nullable Types and ADO.NET don't like each other

Hopefully this will quickly be proven to be out of date, but at least as of the June CTP of C# 2.0, nullable types are not welcome by SqlParameter objects. This strikes me as extremely odd. Personally, I thought the whole reason to add nullable types to C# 2.0 is to finally get rid of the Value Type/Database Type disconnect over null values.

The biggest frustration building type-safe database interfaces has always been that value types cannot be null, but any column in a database can be null. I should stop here and also point out that 99% of the time columns in database are marked as "allow null" when they shouldn't. A column should only allow null if that null has a special meaning. Half the time people just use null to mean 0 for ints and then you get a lovely mix of 0 and null in there that means the same to business logic, but you have to treat watch out for when you run your reports against that table. Don't use null, unless you mean it! But I digress...

Type-safe database interfaces want to pull datatypes from the DB as their native types. So an int in the DB shoud be an int in code. But what do you do when that int allows null, to mark an unset value for example? Do you create a magic number like 0 that means null? Do you store it as object internally after all and throw exceptions when someone tries to access the null value? None of the solutions are all that appetizing.

Then C# 2.0 introduced nullable types. Value types that could have a null value. Yay, the disconnect has been plugged! Or so I should until i tried executing my first SqlCommand that had an SqlParameter with a nullable int passed in. It promptly threw an invalid cast exception.

So for the time being, at least, I get to do a fun little dance of checking for is INullableValue and then casting the value to INullableValue so I can check HasValue and use Value to get the underlying type. We'll see what happens with the release version of Visual Studio 2005 in December.

  • in geek
  • 1 min read

Emacs Keybindings in VS.NET 2k5

Just discovered that VS.NET 2k5 has a preset under Keyboard mapping scheme's for Emacs... Yay! It only remaps things that exist to Emacs commands, i.e. you don't get a killring on Ctrl-Y, but it's something.

  • in net
  • 1 min read

VS.NET 2003 to 2005

I recently started playing with VS.NET 2005 Beta 2, mostly because I wanted to see the Class Designer in action. The first, pleasant surprise was that it co-exists peacefully with VS.NET 2003. I was afraid i might hose my daily dev environment with this experiment, but it seems to be ok. Haven't tried ASP.NET yet, since the switch, but i hear that IIS is the one bone of contention with peaceful co-existence.

But enough about the pleasantries. Converting some work projects, i came across a C# language change that I'm not sure is a change or a fix for a bug. Either way it makes me change my code...

namespace ConsoleTester
{
    public class Base
    {
        protected Base()
        {
        }

        protected Base(string x)
        {
        }
    }

    public class Child : Base
    {
        private Child()
        {
        }

        public Base MakeBase()
        {
            return new Base("foo");
        }
    }
}

This works in C# 1.0, but in C# 2.0 i get Cannot access protected member 'ConsoleTester.Base.Base()' via a qualifier of type 'ConsoleTester.Base'; the qualifier must be of type 'ConsoleTester.Child' (or derived from it). So is this a change in the spec, a bug in 1.0 or a bug in 2.0?

  • in geek
  • 1 min read

The new math.. er--trig

A friend of mine just pointed out DIVINE PROPORTIONS: Rational Trigonometry to Universal Geometry. Having had to refresh my Trig understanding for a number of recent projects (basically any time graphics are involved), I like the concept of getting rid of sin, cos, etc. in favor of simpler rational math.

But what's even more interesting about Divine Proportions are its implications for graphics processing. Being able to get rid Trig functions in 3D calculations and replace them with simple squares and fractions should allow some significant speed increases in processing. Curious how this plays out.

  • in net
  • 1 min read

String Formatting in C

I google this every time, i need to put a float inside of a String.Format() call. Never found a good reference, so i made a note to the place i got the answer from.

Those days are over! Steve Tibett has an excellent article on the subject

Update: Updated the link, as Steve Tibbet's blog software changed and with it the url.

  • in net
  • 1 min read

Detecting ASP.NET

I've been wondering for a while how you could reliably tell if you are currently running under ASP.NET. This is really only of interest to be because of the ThreadSingleton vs. Static Singleton issue. The best way I've found so far is:

bool isASP_NET = ( System.Web.HttpContext.Current == null )?false:true;

Kind of annoying, because you have to reference System.Web in your Project, which you wouldn't otherwise.

I looked through most of classes that come out of the System and mscorlib assemblies but couldn't find anything good and reliable (i.e. didn't want to use AppDomain and see if the config file was called web.config.. Sounds like an accident just waiting to happen.) Still, there's got to be a better way.

  • in net
  • 2 min read

Building custom configuration section handlers

Been playing around with creating my own configuration section handlers. Call me crazy, but i just have a distaste for storing my hierarchical application configurations in some kind of artificially derived flat Key/Value pair scheme.

I see a lot of applications doing something like:

<AppSettings>
  <add key="MyApplication.SomeValue" value="foo" />
  <add key="MyApplication.DB.Host" value="localhost" />
  <add key="MyApplication.DB.Password" value="secret" />
</AppSettings>

when it would be so much cleaner to do:

<my_application>
  <some_value>foo</some_value>
  <db>
    <host>localhost</host>
    <password>secret</password>
  </db>
</my_application>

The answer to this is System.Configuration.IConfigurationSectionHandler and then you stuff the result in a singleton. A couple of pitfalls with this approach are:

Application vs. ASP.NET: The singleton needs to determine whether it's running as an application or under ASP.NET, so it can decide whether it needs to be a thread singleton or can just be a static variable. Easiest solution here is to allow a way to manually initialize the singleton with a flag. Then you can use Begin_Request in global.asax to tell it to use a thread singleton and default to a static variable otherwise

Allowing for config relocation like AppSettings: AppSettings lets you externalize your name/value pairs via . This can easily be handled in System.Configuration.IConfigurationSectionHandler except that you need to look at the path to see if it's relative and then you need to figure out how to get that. The best way to determine the directory that's the same between Console, WinForms and ASP.NET is using AppDomain.BaseDirectory and just appending the relative path to it.