SimplyGold

Err — yeah.

You might be wondering what Genghis Kahn has to do with the template. The short answer: he doesn't. The long answer: I needed to name the template something — it was either "Red Blue White" or "Genghis Kahn," and I settled for the latter. I shall contrive to come up with a slightly more meaningful title next time. ;-)

View the template Download the template

Long-time users might notice that the design looks suspiciously familiar to one of the previous revisions of this blog. That's because — err — it had been used as the design for this blog at one point. However, I'm not using it any longer (no kidding). I didn't want to let it go for waste, however, and so I'm releasing it as a free template for anyone who wants to use it for personal or commercial site. Feel free to make any modifications whatever. However, please don't try to sell the design to anyone. :-)

While you don't need to include my name in the design anywhere, a mention and a link back is much appreciated. :-D

Look at the template

Download the files

A useful addition to ASP .NET 2.0 is the ability to register web controls in web.config. In ASP .NET 1.1, if you wanted to use a custom server control on twenty different pages, you had to register it on all twenty of those pages:

1. <%@ Register tagprefix="tagprefix" Namespace="Namespace" Assembly="Assembly" %>

In ASP .NET 2.0, you can register the server control in the controls section of web.config once and use it in whatever page you want of the web application.

1. <pages>
2. <controls>
3. <add
4. tagPrefix="MyTagPrefix"
5. namespace="My.Namespace"
6. assembly="MyAssembly"/>
7. </controls>
8.  
9. <!-- Other elements go here -->
10.  
11. </pages>

Read more on MSDN

Access modifiers, as their name suggests, control who sees what in an application. C# has 4 basic access modifiers (there’s also a 5th one, but more on that later). Here they are, listed from least restrictive to most restrictve.

1. public: accessible anywhere.
2. protected: accessible to current class and all derived classes.
3. internal: accessible to any class in the current assembly.
4. private: accessible to current class only.

Easy enough to understand.

Some Things to Keep In With Access Modifiers

1. Namespaces can’t have access modifiers. They’re always public. So: public namespace AwesomeNewNamespace { … } will produce a compile-time error.
2. Classes can be either public or internal but not protected or private. So: private class AwesomeNewClass { … } will produce a compile-time error. This makes sense if you think about it — how exactly would you use a private or a protected class??
3. Interfaces, like classes, can be either public or internal but not protected or private.
4. Methods defined in interfaces can’t have access modifiers.
5. Enums are always public. They can’t have access modifiers either.
6. By default, classes are internal. So: class NotSoCool { … } is equivalent to internal class NotSoCool { … }.
7. By default, methods in class are private. So void SomeAwesomeMethod() { … } is equivalent to private void SomeAwesomeMethod() { … }.
8. Same goes for variables (fields): private unless specified otherwise.
9. Needless to say, you can’t use access modifiers on variables inside a method: public voidMethod() { protected string someString; will produce a compile-time error.
10. Derived classes can either have the same restriction level or can be more restrictive than the base class but not less restrictive. So: internal class Base { … } public class Child : Base { } will produce a compile-time error.

Now that we got that out of the way, let’s take a look at that 5th modifier that I mentioned at the beginning. This would be the compound modifier protected internal. After looking at it for a minute, you would think that it does what other compound modifiers in .NET do. For example, protected virtual void AwesomeMethod() makes AwesomeMethod both virtual and protected, so you’d think that protected internal AwesomeClass { … } would make the class both protected and internal (i.e., it is only accessible to derived classes in the assembly) but you would be wrong. For some bizarre reason that I have yet to fathom, the powers-to-be have decided that protected internal means protected or internal (so that the method is available to all derived classes as well as all classes in the current assembly).

I’m a converted iTunes junkie. The last time I’ve opened Windows Media Player was, like, in the Dark Ages. Nothing wrong with the player, but its user interface is horrendous, especially when compared to the simple elegance of iTunes.

But I just might get converted back to Windows Media Player. Microsoft finally released the Windows Media Player 11 Beta, and I have to say, I’m impressed. :-)

Source: Microsoft

Here’s a link to the Windows Media Player 11 Beta download for those of you who want to play with it.

Something I’ve had to do often. Until now, I’ve gone through the “laborous” (hehe) process of remembering what stored procedures I’ve added and granting EXECUTE permissions to whatever user for each procedure. I was sure that there was an easier way to grant the permission on all stored procedures, and there is!

GRANT EXECUTE TO [Insert the name of the user here]

If you’re using SQL Server 2000, you don’t have it so easy. However, here’s an article on how to create a stored procedure to do the same.

A quickie. The Obsolete attribute marks a class or method as (pardon the redundancy) obsolete. Usage:

1. [System.Obsolete("This is an obsolete class; use NonObsoleteClassInstead")]
2. public class ObsoleteClassExample
3. {
4. // Internals of the class
5. }

Marking a Method Obsolete

1.  
2. public class NormalClass
3. {
4. // …
5.  
6. [System.Obsolete("This method is absolute; use NonObsoleteMethodInSomeClass")]
7. public void ObsoleteMethodExample(string blah)
8. {
9. // Internals of the method
10. }
11.  
12. // …
13. }

No, there isn’t any difference in marking a class vs. method as obsolete. I just wanted to create two code blocks, go figure. :p

When you use a class/method marked as obsolete, VS 2005 shows you a nice warning in the “Error List” pane.

The Problem

Suppose you have a static readonly string whose value you don’t know until runtime. Maybe you have to read it from FileAbcdefgh.txt when certain condition is true and read it from FileXyz.txt when it’s not. But once set, the value should never be modified again.

The Solution

I’m assuming you guessed that the solution to the problem is static constructors. You guessed right. Static constructors, like the null coalescing operator, are a C# feature I was not aware of until fairly recently.

Static constructors look fairly similar to normal (default) constructors:

1. public class StaticConstructorTestClass
2. {
3. private static readonly string someStaticString = string.Empty;
4.  
5. static StaticConstructor()
6. {
7. someStaticString = GetFromDatabaseOrWhatever();
8. }
9.  
10. private static string GetFromDatabaseOrWhatever()
11. {
12. // Do the processing here
13.  
14. return "This is a string I got from database";
15. }
16. }

The Rules:

When creating static constructors, keep these rules in mind:

1. Only one static constructor per class.
2. The constructor can’t have any parameters.
3. The constructor can’t have an access modifier (public/private/etc).
4. The constructor executes before any instance constructor.
5. The constructor executes only one time per class.