SimplyGold

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.

The Problem

Database access has to be my least favorite activity to code, right up there with coding public data access (to private fields). The worst thing about coding database access is — easily — the need to check for null values. I recently found a nugget in .NET that makes the process a bit less painless, and I’m putting it out here in the hopes that it will help somebody avoid this:

1. public void Read()
2. {
3. // …
4.  
5. System.Data.SqlClient.SqlDataReader rdr = new System.Data.SqlClient.SqlDataReader();
6.  
7. if (!rdr.IsDBNull(0))
8. {
9. // Yay! It’s not null.
10. }
11.  
12. if (!rdr.IsDBNull(1))
13. {
14. // Wow, the second field is not null either.
15. }
16.  
17. if (!rdr.IsDBNull(3))
18. {
19. // And neither is this one; I’m so excited.
20. }
21.  
22. if (!rdr.IsDBNull(4))
23. {
24. // This one isn’t either? Really?
25. }
26.  
27. // …
28.  
29. if (!rdr.IsDBNull(723498234))
30. {
31. // And this one’s not null either. Oh, what joy.
32. }
33. }

The Solution

Enter ??. Wait, what? ?? is an actual operator in C# and not a spelling mistake on your part? I’ve never heard of it in my entire life (okay, so maybe you did hear of it before, but I haven’t, not ’til yesterday!).

You’d code the ?? like this:

1. AwesomeObject someAwesomeObject = new AwesomeObject();
2.  
3. someAwesomeObject.AwesomeField = rdr.GetString(10) ?? string.Empty;

To read more on the ?? operator, try this MSDN article.

I finally found out that the operator is called null coalescing operator and is available in C# 2005 only. Another reason C# rocks. ; -) Any questions?