Archive for the ‘Development’ Category

I have been asked this question many times so I thought I could blog about it. It is a bit confusing until you know the differences. Visual Studio .Net provides us with two options for compiling and creating builds for our application. They are Build Solution and Rebuild Solution options which can be accessed from the Build menu. The differences between these two options are1. The Build Solution option compiles only those project files and components that have changed since the last build. For example consider that you have two projects Proj1 and Proj2 in your solution MySolution. When you compile the solution using Build Solution option after making some changes to Proj1 only Proj1 will be compiled and built but Proj2 will not be compiled since there are no changes to it. On the other hand the Rebuild Solution option builds all project files and components irrespective of the changes made to them. For example consider that you have two projects Proj1 and Proj2 in your solution MySolution. When you compile the solution using Rebuild Solution option after making some changes to Proj1, both Proj1 and Proj2 will be compiled and built even though there are no changes made to Proj2.

Frans Bouma summarizes a war that has been brewing since the popularity of ORMapping and Code Generation.

You’d think that by now everyone would have said everything that you can say about Stored Procedures vs. Dynamic SQL, but apparently Eric Wise and Jeremy Miller disagree with that and have started another iteration of this Never Ending Story^TM.

As it’s Friday and you’re probably looking forward to the weekend and wonder what to do till it’s time to go home, sit back, get a soda or two and read yourself through the afternoon with the following Stored Procedure vs. Dynamic SQL masterpieces of all time :

• Rob Howard‘s post which started a debate about this topic some years ago: Don’t use stored procedures yet? Must be suffering from NIHS (Not Invented Here Syndrome).
• Yours truly’s reply to Robs’ remarks: (I admit, [TongueInCheeck(true)] has to be applied here) Stored procedures are bad, m’kay?
• My lengthy article about the subject over at TheServerSide.NET: Mind Your PQs (Parameterized Queries)
• Jeremy’s start of another episode: The YAGNI Development Assistent
• Eric’s reply: The Pragmatic Adhoc SQL vs Stored Procedures Discussion
• Of course, Jeremy had to answer: Why I do not use Stored Procedures
• Eric wanted the last word on this: In Response To No Stored Procedures

I was asked the question lately on what is the difference between interfaces and abstract classes. I found it very difficult to explain so I decided to blog about it.

Interfaces and abstract classes are a concept that I found very hard to understand when learning OO. I struggled with finding differences between the two and where one would be better to use over the other.

I will attempt to define each of these terms and show when to use them with code samples.

Abstract Class

Abstract classes are classes that contain one or more abstract methods. An abstract method is a method that is declared, but contains no implementation. Abstract classes may not be instantiated, and require subclasses to provide implementations for the abstract methods.

Here is an example of an abstract class:

  abstract class Animal {      public void eat(Food food)      {           // do something with food....       }       public void sleep(int sleepLengthInMinutes, DateTime sleepStartTime)      {           // do something with sleeping      }       public abstract void makeNoise(); } 

This class ‘Animal’ is abstract. It contains two methods with ‘content’ and one method that is simply a ‘contract’ (makeNoise).

Since the ‘abstract’ keyword is used on the class, the class ‘Animal’ cannot be instantiated and must be sub-classed.

For all classes that subclass ‘Animal’, they must implement the ‘makeNose’ class.

Here is an example of two classes:

 public class Cat : Animal {      public override void makeNoise()      {           Console.WriteLine("Meeeeoooowwww!");      } }  public class Duck : Animal {      public override void makeNoise()      {           Console.WriteLine("Quack! Quack!");      } } 

Both the Cat and Duck class can use the ‘eat’ and ‘sleep’ methods from the base class.

Interface

An Interface is a reference type and it contains only abstract members. Interface’s members can be Events, Methods, Properties and Indexers. But the interface contains only declaration for its members. Any implementation must be placed in class that realizes them. The interface can’t contain constants, data fields, constructors, destructors or static members. All the member declarations inside an interface are implicitly public.

Here are two examples of an Interface:

public interface IAnimal

{

string MakeNoise();

string Sleep();

string Eat(Food food);

}

public interface IMammal

{

int GetAppendageCount();

}

The Interface is just a contract of an implementation. methods that are described in the Interfaces above must be implemented in any classes that inherit from them.

Classes can inherit from multiple interfaces. (This cannot be done with abstract classes).

Here is an example of a class inheriting from these two Interfaces:

public class Dog : IMammal, IAnimal

{

public string Sleep()

{

return “..zzzzzzzzz”;

}

public string Eat(Food food)

{

return “Chomp…this “ + food.Description + ” is good.”;

}

public string MakeNoise()

{

return “Bark!� Bark!!”;

}

public int GetAppendageCount()

{

return 4;

}

}

You can see that this class Inherits the two interfaces in the class declaration. The class also implements the required methods from the interfaces.

Now that you have seen the definitions of an Interface and an abstract class, I will explain some of the differences between them.

Microsoft has included a new Reporting Control ‘ReportViewer’ based off of the Microsoft Reporting Services framework.

The control is great but there is a problem with using it and the new WebApplication addon. The control has a problem finding embedded reports. You can only use the .ReportPath property of the object to tell the control what folder the report is in. This is annoying if you do not want to deploy the actual .rdcl report files with your project.

Since the WebApplication addon will be included in Visual Studio 2005 Service Pack 1 (due next month), hopefully they will fix this at that time.

This post will describe the differences of throw();  and throw(ex); when dealing with Exception handling in .NET.

I did not know of the subtle differences before reading this on Matt’s Site.

The difference is that throw; preserves the original stack trace and throw ex; truncates the stack trace below the method in which the throw ex; call is located. For example, here’s some driver code and the generated output:

Output:

Notice how the stack trace from the ThrowMethod() call includes ThrowSample.ThrowSample.ExceptionMethod()? This portion of the stack is conspicuously absent from the ThrowExMethod() stack trace.

Now, we’re lucky we’ve got the PDBs handy so we get line numbers in the exception message. What if we didn’t? It certainly would be harder to find the true source of the exception using the stack trace from throw ex;, especially if the ThrowExMethod method was more complicated than it is.

Let’s take this one step further, and assume there are several method calls between ThrowExMethod and ExceptionMethod, any or all of which could be throwing their own exceptions. Using the stack trace from throw ex; there’d be no wayy to know where the exception actually came from. See why it’s important to understand the difference?

All that being said, using throw ex; isn’t always bad. But you should only be using it when you have something to add to the exception that was caught. In which case, you should be throwing a new exception instance, initialized with the caught exception as the inner exception. For example:

Now the stack trace is nicely preserved:

Exception caught from ThrowExMethod:
System.ApplicationException: Uh-oh! —> System.Exception: DOH!
at ThrowSample.ThrowSample.ExceptionMethod() in
C:\ThrowSample\Program.cs:line 65
at ThrowSample.ThrowSample.ThrowExMethod2() in
C:\ThrowSample\Program.cs:line 54
— End of inner exception stack trace —
at ThrowSample.ThrowSample.ThrowExMethod2() in
C:\ThrowSample\Program.cs:line 58
at ThrowSample.Program.Main(String[] args) in
C:\ThrowSample\Program.cs:line 21

This is such a cool feature of ASP.NET 2.0 and I can’t believe I didn’t know about. Thanks to InfinitiesLoop.I am now using this in Kinetic CRM.

CodeExpressionBuilder
Expression builders allow for some pretty interesting interaction with the ASP.NET compilation model.

For example, new to ASP.NET 2.0 is the ability to reference appSettings declaratively. Lets say you wanted the text of a button to be based on a value in the appSettings section of your web.config. Piece of cake:

<asp:Button id="cmdSubmit" runat="server" Text="<%$ appSettings: ButtonText %>" />

This is made possible by the built in AppSettingsExpressionBuilder. Lets say you wanted to display a localizable string, which is stored as a resource. In ASP.NET 1.1 it was sort of a pain. No longer:

<%$ resources: ResourceKey %>

That’s the ResourceExpressionBuilder hard at work. Nice!

There’s also a ConnectionStringExpressionBuilder so you can refer to Connection Strings defined in the new connection strings section in the web.config. That is extremely helpful when working with the new declarative data controls:

<asp:SqlDataSource id="data1" runat="server"
ConnectionString="<%$ ConnectionStrings: MyConnectionString %>"/>

Pretty useful.

Now lets take it one step further. Have you ever seen this exception?

The dreaded “Server tags cannot contain constructs” exception.

That’s because you probably tried to do something like this:

<asp:Label id="lbl1" runat="server" Text=<%= CurrentUserName %> />

Perhaps you tried to fix it by putting it in quotes:

<asp:Label id="Label1" runat="server" Text="<%= CurrentUserName %>" />

… Only to be thwarted once again, as the literal text, including the <%= %> construct, ended up in the page:

Putting <%= %> in quotes doesn’t help much.

If all you want to do is show the result of this code as a string, you could quite simply just get rid of the label:

<%= CurrentUserName %>

That would work. But perhaps you need the label server control for some other reason, or perhaps you need to set a string property of some other type of server control in this way.

The problem is you have incorrectly (although intuitively) tried to assign the property of a server control using the <%= %> construct. Unfortunately that is simply not supported by ASP.NET, 1.1 nor 2.0. If you ask around about your problem, someone may tell you that you will have to convert to using the <%# %> databinding construct instead. That is advice that I have given myself. But it requires that you are calling DataBind() on the control, AND, it will cause you to bloat your viewstate.

You can just go ahead and assign the value in your code-behind, say.. in the OnInit method.. but that too will bloat viewstate. I’m afraid there’s no super simple solution unless you don’t mind disabling viewstate on that control. That may work in some scenarios, but sometimes you really need the ViewState enabled! What’s a web developer to do?

Let me back up a little and give a more concrete example. You want the text value of a CheckBox to be the current date and time. For whatever reason, you can’t disable viewstate on the CheckBox (say, because you need the CheckChanged event, which doesn’t work without viewstate). How on Earth are you going to get the current date and time into the Text property on the CheckBox, WITHOUT BLOATING VIEWSTATE? By “Bloating ViewState”, I mean causing data to become serialized in the __VIEWSTATE hidden form field when it isn’t necessary to begin with. There’s no reason to put the current Date and Time into serialized viewstate, is there? It’s going to be reassigned on the next request. You’d just be making ASP.NET serialize it, then making the user’s browser pull the serialized string down the pipe, then making them push it back up the pipe to the server on a postback, then making ASP.NET deserialize the value — ONLY FOR IT TO BE REASSIGNED? How rude! How wasteful and inefficient. For a single control its not a big deal, what’s a few bytes? But that is not a path you want to start down my friend. Ideally, you want the functional equivalence of this:

<asp:CheckBox id="chk1" runat="server" Text="<%= DateTime.Now %>"/>

That is ideal, because the ViewState StateBag is not tracking changes when ASP.NET assigns declared attributes, so our beloved ViewState remains optimized. And, we didn’t even have to disable ViewState. AND we can do it declaratively! Woohoo! Right. Well, it won’t work.

The CodeExpressionBuilder comes to the rescue! Another great thing about ExpressionBuilders is that you can roll your own. So, I created a CodeExpressionBuilder, one that allows you to use raw code to assign values to control properties. Using the CodeExpressionBuilder you can do this:

<asp:CheckBox id="chk1" runat="server" Text="<%$ Code: DateTime.Now %>"/>

Now that is nice. And to think the darn thing is only a few lines of code! The trick is to use the CodeDom’s CodeSnippetExpression to convert the given string into a CodeExpression. Here’s the entire class:

[ExpressionPrefix("Code")]

public class CodeExpressionBuilder : ExpressionBuilder {

public override object ParseExpression(string expression, Type propertyType,

ExpressionBuilderContext context) {

return expression;

}

public override CodeExpression GetCodeExpression(BoundPropertyEntry entry, object
parsedData, ExpressionBuilderContext context) {
return new CodeSnippetExpression(parsedData.ToString());
}
}

To use it, or any custom ExpressionBuilder for that matter, you must register it in the web.config expressionBuilders section. Now... how you do this part sort of depends on how your project is setup. If you have a standard ASP.NET Web Site project, then you will be defining the CodeExpressionBuilder class in the app_code directory, and the "type" will just be "CodeExpressionBuilder". However, if you are creating a Web Application Project (read about it here), then the CodeExpressionBuilder is just another class in your project, with its own namespace. For that you will need to define the whole type string (or, if you define it in a reusable library, you'll need the fully qualified type and assembly name). In my case that is "Infinity.Web.Compilation.CodeExpressionBuilder". Like this:

<compilation debug="true">

  <expressionBuilders>

    <add expressionPrefix="Code" Type="Infinity.Web.Compilation.CodeExpressionBuilder"/>

  expressionBuilders>

compilation>

And to see it in action:

<asp:CheckBox id="chk1" runat="server" Text="<%$ Code: DateTime.Now %>" />

ExpressionBuilders are truly a thing of beauty! Use any expression you want!

Also try:

<%$ Code: DateTime.Now.AddDays(1) %>

<%$ Code: "Hello World, " + CurrentUserName %>

<%$ Code: CurrentUserName.ToUpper() %>

<%$ Code: "Page compiled as: " + this.GetType().AssemblyQualifiedName %>

Just be careful what combination of quotes you use. If you have literal strings in your code expression like in two of the above examples, you will need to use single quotes (') to surround the entire <%$ %> expression if it is within a server control declaration. If you don't you will get the "Server tag is not well formed" error.

In the beginning I said ExpressionBuilders were an interesting way to plug into the ASP.NET compilation model. Well this really illustrates that... put a break point in the expression builder, and debug the page. You will hit the break point once, and only once, even after you refresh the page several times. The Date and Time will continue to update, but the expression builder breakpoint will only activate the first time you hit the page. The reason is because the ExpressionBuilder is used when ASP.NET compiles the page. Once the page is compiled, that's it. That's the reason why ExpressionBuilder returns a CodeExpression, and not an actual object. In essence, the builder tells ASP.NET what code it needs to run to get the value, instead of giving it the actual value. It's the old adage, teach a man to fish, and he eats forever. How geeky is that? Too cool.

PS: The one thing this ExpressionBuilder doesn't do... it won't work in "No-Compile" pages. Seems like a reasonable limitation.