.NET Spider

10 C# Shorthands that improve productivity

2009-03-20T02:39:00.001-07:00

One of the best things about C# is that as the language and libraries expand thought is put into keeping things readable. Below I have listed 10 shorthands that you can use to make your code tighter and less wordy. No doubt you know one or more already — but do you currently use all ten of them ?

Visit here ..

SEO optimization

2009-03-10T21:03:00.000-07:00

If you are building a new ASP.NET application, SEO has become a big factor in how you plan the structure / code of the site. But quite an important part of the site which are often overlooked are the URL’s, and a lot of people do the basics which I’ll show below but there are a few common things people tend to miss or never thought could be a problem. I use ISAPI rewrite for most of my sites, which is an amazingly effective tool for sorting duplicate content and SEO issues which I’ll show below

6 SEO Tips For ASP.NET URL’s

Posting data to a REST service using C#

2009-02-24T06:33:00.000-08:00

As Rest services are becoming more and more common the need is arising to be able to post data to them via .net. Now normally when you want to post data to a web resource you normally would do so using a web service. And when you use a web service all the ‘plumbing’ is taking care of for you by the .Net framework. However since we are not posting to a web service there is a bit of code you need to create in order to post to a REST service. The good news is that the amount of code you need to create is not all the bad.

Lets pretend we want to post data to the following REST service http://localhost:2844/Home/PostDataTester which takes in 3 values

someValue which is a string
anotherValue which is a string
finalValue which is an Int32

Now that we know what the REST service contract looks like we should take a look at the code needed to actually connect to and post the data.

First we are going to look at the main logic which will post the data, however, this method has 2 helper methods which we also need to discuss.

public void SendMessage( string endPoint, Dictionary<> paramters)
{
var populatedEndPoint = CreateFormattedPostRequest( paramters );
byte[] bytes = Encoding.UTF8.GetBytes( populatedEndPoint );

HttpWebRequest request = CreateWebRequest( endPoint, bytes.Length );

using ( var requestStream = request.GetRequestStream() )
{
requestStream.Write( bytes, 0, bytes.Length );
}

using ( var response = (HttpWebResponse)request.GetResponse() )
{
if ( response.StatusCode != HttpStatusCode.OK )
{
string message = String.Format( "POST failed. Received HTTP {0}", response.StatusCode );
throw new ApplicationException( message );
}
}
}

As you can see from above, the code needed to actually post the data is not too bad, in fact it is fairly simple. Now that we have seen the main logic lets take a look at the various helpers methods.

The first helper method is the method which will actually create the HttpWebRequest object for us

private HttpWebRequest CreateWebRequest( string endPoint, Int32 contentLength )
{
var request = (HttpWebRequest)WebRequest.Create( endPoint );

request.Method = "POST";
request.ContentLength = contentLength;
request.ContentType = "application/x-www-form-urlencoded";

return request;
}

Pay close attention to 2 things here

The method on the request must be POST
The content type on the request must be application/x-www-form-urlencoded

The second helper method will take in a list of values which need to be posted and create the value query string for posting

private string CreateFormattedPostRequest( ICollection> values )
{
var paramterBuilder = new StringBuilder();
var counter = 0;
foreach ( var value in values )
{
paramterBuilder.AppendFormat( "{0}={1}", value.Key, HttpUtility.UrlEncode( value.Value ) );

if ( counter != values.Count - 1 )
{
paramterBuilder.Append( "&" );
}

counter++;
}

return paramterBuilder.ToString();
}

Pay close attention to the fact that we are doing UrlEnoding on our values which we are pushing to the service, this is very, very important.

As you can see, the actual code to post a message to a REST service is simple and trivial and can be implemented with very little effort.

Source: http://devlicio.us

Why get bored, when you could be coding

2009-01-21T05:19:00.000-08:00

Hi Guys,

I found this article on Spoiled Techie site. But it looks like this speaks about my mind.

There are many times in life when you have nothing to do. As a member of the civilized world, we as a people are becoming bored every day. We are a world that watches more movies everyday. I bet if the movie industry came out, we would see the statistics of movie goers have increased over the last 20 years. We are a world that technology has allowed to do many things that have taken us hours or even days to do before. Our world is speeding up and everyone wants more. They want to get done faster, finish things better and move on to the next project. People get bored easily these days because production levels have gone through the roof with the help of technology which allows us to become lazier. Life in it self is full of its bored moments. People in general have less and less to do because technology has sped up our daily tasks. I think that is one reason why more and more movies are being watched. People want more out of life and movies give you that little action and adventure that your looking for. Movies give you the ability to stop boredom. To some people, movies are a way of life.

My life is no different, technology has made my life so much easier than people that have come before me. My solution of boredom? People need to find a hobby. They need to find something that will keep their attention. If they don't they will inevitably become a YouTuber.

YouTuber -A person that watches excessive amounts of YouTube to pass the time. Not only applied to YouTube, but a person that does an excessive amount of anything to which they do just to pass the time. This isn't a hobby, but a time waster.

People that watch and enjoy YouTube to me are either doing it because that is their hobby or they are doing it to pass the time. I personally code as my hobby or down time. I not only do it as a hobby, but to make my life and everyone else's life a bit easier and a bit better. I am like every other programmer or hacker the does it. I chip away at making life better. I don't think I will ever be as rich as Bill Gates, but I hope to have helped as many people in my life as he has. This is where coding/hacking comes in. When I get bored I code; when I want to do something, I code. Due to technology, I get to do a lot of my hobby.

If this is your first time reading, then you wouldn't know that I usually try to have around 2-4 projects going on at once. My projects are all for making life a bit easier for me and everyone that has access to a computer and internet. I have about 15 ideas that could be implemented currently and boredom brings my code to life. Like I said before, I don't get bored, I code. Right now I am even sitting with friends and watching some football. I can keep a conversation, watch football and blog all at once. When I get bored, I code (so I am not coding, but being productive).

The point I was trying to get across: Stop being bored, be productive. Find a hobby, find something. Carpe Diem (Seize the day). Learn something, do something and retain it. When I get bored, I code. Life is not about being bored. Life is about doing something. Its about achieving something better than your self. My something better right now in my life is coding and my great girlfriend.

Source: Spoiled Techie

C# 4.0 Dynamic Lookup

2009-01-20T09:06:00.000-08:00

One of the core features introduced in C# 4.0 is called Dynamic Lookup which allows a unified approach to invoking things dynamically. Currently, when you call object methods or properties, the compiler checks that they exist and raises an error if they do not. With dynamic lookup, you can call any method or property, and they are not checked until runtime. C# 4.0 is extending towards the dynamic languages. Having an object, you do not need to worry about whether it comes from COM, Python, JavaScript or reflection, you just apply operations to it and leave it to the runtime to figure out what exactly those operations mean.

C# 4.0 will support dynamic typing through a new static type called “dynamic”. As already described, when you have an object of type dynamic you can do whatever you like with it, those operations are resolved only at runtime. Lets first see a method declaration:

public dynamic GetService()
{
// Getting some service...
}

and how to use it:

dynamic service = GetService();
service.Do("YourJob");

The C# compiler allows you to call a method with any name and any arguments because service is declared as dynamic. Scary, isn’t it? Only at runtime will you get an error if the returned object doesn’t have such a method.

Actually,,,, I don't like it

What shall I do with the GetService Method? I don’t know and neither does IntelliSense. If I mistakenly call a non existing method or even had a typo while typing an existing method, I will get a runtime error while I could know about my mistake at compile time. I can’t see one good thing here. The problem is that when running our program, we never reach all of the paths so we might never face our problem, our customer will. If it is up to me, I won’t use this feature, but I am not alone, there are third party libraries and co workers who might use the dynamic keyword and make me helpless. The dynamic keyword is open to abuse as anything could be. This feature moves us away from strong typing meaning that many years of wisdom is being thrown out of the window. What is wrong about interfaces? It gives flexibility but it keeps us from stupid mistakes as well.

I heard that Hejlsberg noted that developers should not now declare all variables as dynamic, but should continue to rely on static typing as standard, because this is safer and faster. Do you really trust C# developers so much? It makes me cringe. You can’t provide a heavy tool for everybody, many developers won’t use it correctly and wisely and the other developers will suffer from their stupidity. Why leaving an open door for unnecessary mistakes? Why?

There are some more features in C# 4.0 like Named and Optional Arguments, Covariance and Contravariance for generic types. I decided to focus on the dynamic lookup feature because I am really afraid from its consequences and can’t understand what is the benefit of it. Do you agree with me? Don’t you agree and think that I am paranoid? Comment and start a debate.

Source: http://www.dev102.com

ASP.NET Process Identity

2009-01-20T07:18:00.001-08:00

For additional security, the ASP.NET application worker process (aspnet_wp.exe) runs using an account (ASPNET) with weaker privileges than the Local System account. By doing so, an intruder will not have administrative access if security is breached. This is because the Local System account has access to almost all resources on the local computer not specifically denied to it.

To run the worker process using a specified account, modify the element in the root configuration file (machine.config), located in the \%windows%\Microsoft.NET\Framework\Version\Config folder, as shown below:

machine.config file

<system.web>
<processmodel>
enable="true"
userName="domain\user"
password="password"
/>

In addition to specifying a particular user account, you can also set the userName attribute to one of two specially recognized values, "SYSTEM" and "MACHINE". In both cases, you should set the password attribute to "AutoGenerate", which instructs Windows to manage the password. The default userName setting is "MACHINE", which is the worker process that uses a local account named ASPNET. This account is similar to the IWAM_machinename account used by Internet Information Services (IIS) for running instances of dllhost.exe when hosting applications built using ASP 3.0 and earlier. If you specify "SYSTEM", the worker process uses the Local System account. The ASPNET account is created during installation of the .NET Framework.

If you use a custom account, that account must have the following necessary access rights:

Read/write access is required for:

The %installroot%\ASP.NET Temporary Files directory. Subdirectories beneath this root are used for dynamically compiled output.
The %temp% directory, which is used by the compilers during dynamic compilation.

Read access is required for:

The application directory.
The %installroot% hierarchy to make it possible to access to system assemblies.
The Web site root directory (e.g., the path at which the "Default Web Site" points, typically %systemdrive%\inetpub\wwwroot).
The Global Assembly Cache, %windir%\assembly.

C# Trivia - What? No Overflow?

2009-01-17T10:30:00.000-08:00

If you've been dealing with C# for a long time, then you have probably at one point or another tried to do this:

view plaincopy to clipboardprint?
int myNumber = 9999999999;  

And you know that you can't, the compiler tells you that this number if just tooooooooo big! It can't handle that pesky giant number. Why can't it handle it? Well, that is because it is a fixed size, and passing that size will cause an overflow, right? Which is what happens when we do this:

view plaincopy to clipboardprint?
int myNumber = int.MaxValue;  
myNumber += 1;  

Right? Right? Nope. Trust me, it won't blow up. Try it, I'll wait. Okay, so you're back, and you are probably surprised that you got this:

You may be thinking to yourself, "C# doesn't do overflow checking?" And the answer to your question is "not by default" when you are using non-constant expressions. And the reason is that they wanted to squeeze every last little bit of performance out of C#. It is a good thing that the .net runtime forces array bounds checking, or they might have turned that off as well! As a side note, you can read an interesting story about the F# team trying to get around array bound checking in this post.

So, what do we do if we want to get numeric overflow checking? Well, we have two options. First, we can just put our code inside of a "checked" section:

view plaincopy to clipboardprint?
checked  
{  
int myNumber = int.MaxValue;  
myNumber += 1;  
}  

Most likely you have never even seen this keyword, but it causes integer overflow checking to be turned on inside of this block. You must also keep in mind that "checked" blocks to not affect methods that are called from this block. If we did something like this:

view plaincopy to clipboardprint?
checked  
{                  
UncheckedMethod();  
}  

The code in the "UncheckedMethod" would not get overflow checking.

SIDENOTE

The "checked" section is only for integer math. Floats (System.Single) and doubles (System.Double) will never use overflow checking while Decimal (System.Decimal) will always use overflow checking.

Your other option is to turn on overflow checking for the entire project. This can be done by going to the project properties:

Then to the "Build" tab:

Then in the bottom right corner you will find an "Advanced" button:

And once you click that a dialog will appear and you can check this button:

This will have the same effect on the entire project as the "checked" block. It will cause overflow checking on integer math only! But what if we want to have overflow checking on in the project, but we have sections that have overflow checking off? Well, they have created an "unchecked" block for us to use:

view plaincopy to clipboardprint?
unchecked  
{  
int myNumber = int.MaxValue;  
myNumber += 1;      
}  

So even though by default overflow checking is enabled for the entire project, it is not for this particular block.

I hope that you found this little bit of C# trivia interesting, even though most of us won't ever need to fiddle with these settings, it is nice to know what we have available to us.

source : http://www.codethinked.com

A DISSERTATION ON .NET PROPERTIES

2009-01-13T10:12:00.000-08:00

I’ve been meaning to write this piece for quite some time. Today we’re going to discuss properties in general, and specifically what are referred to as “trivial” properties.

The Technology Behind Properties

Chances are you can skip this part if you have any .NET development experience.

Properties are specially-demarcated methods in a given .NET class. When your class is used by another piece of code, the property looks and acts much like a field or variable.

Let’s examine a snippet of code:

public class Class1

{

public int PublicValue;

private int myValue;

public int Value

{

get { return myValue; }

set { myValue = value; }

}

In this code, we define a very simple class. This class has one public “field” and one public “property.” The property defines a “getter” and “setter” for its data. When using this class, we might use code such as:

public static void Main()

{

Class1 c = new Class1();

c.PublicValue = 5;

c.Value = 10;

}

So from the client programmer’s perspective, a public field and a public property more-or-less look the same. What’s the difference “under the hood?”

If you use ILDASM (the Intermediate Language Disassembler, which ships with the .NET Software Development Kit), you will see the following fields (cyan rectangle) of Class1:

PublicValue : public int32

myValue : private int32

You’ll see the following methods (purple rectangles):

.ctor : void()

get_Value : int32()

set_Value : void(int32)

And the following property definition:

.property instance int32 Value()

The property definition ties the two get/set methods together as a property for .NET languages. You can see this if you look at the MSIL definition of the property:

.property instance int32 Value()

{

.get instance int32 DemoClasses.Class1::get_Value()

.set instance void DemoClasses.Class1::set_Value(int32)

} // end of property Class1::Value

OK, so what does writing the extra code for a property actually buy you? You have the ability to add logic to the property, to ensure business rules are followed. You can also use it, on reference types, to ensure that no null values are returned.

Also, if you want to use object binding, you have to use properties – you can’t use public fields for binding.

Designing Properties

So now you know the basics of how properties work. What are some basic guidelines?

I believe that properties exist to make your life, and the lives of the client developers using your class, easier. To this end, here are John’s Simple Rules of Properties:

Properties shall never return null, unless there is a damn good reason to do so. If your property has to return null for some reason, then document it – use the documentation feature of C# or VB to do so.

Generally, properties should enforce business rules. If you have a numeric value with logical minimums and maximums, enforce them. If the string must have a certain length, enforce that. It’s OK to throw exceptions from the set block, or – if applicable – modify the value accordingly (truncation, etc). However, document any and all side effects which are possible.

Trivial Properties

Which brings us to “trivial” properties. Trivial properties are ones such as that which we wrote above – there’s no logic, no nothing, the get simply returns whatever value is in the backing store and the set simply sets the backing store.

I am generally against trivial properties. I’m not against writing the code, but I am against using a property without taking advantage of its benefits.

Automatic Properties

Starting with Visual Studio 2008 and .NET 3.0, C# provides the concept of “automatic” properties. “Automatic” properties look something like this:

public class Class1

{

public int Value

{

get;

set;

}

public string Text

{

get;

set;

}

Notice that we wrote almost no code there. When we compile, the compiler will generate the full property for us. Let’s see what the disassembly looks like.

First there are the fields. We didn’t define any in our class, but we have some:

k__BackingField : private string

k__BackingField : private int32

These are the backing stores for the properties. As for the property methods themselves:

get_Text : string()

get_Value : int32()

set_Text : void(string)

set_Value : void(int32)

And finally the properties themselves:

Text : instancestring()

Value : instance int32()

That’s all well and good, but what do these properties actually do? Well, simply put, .NET’s automatic properties create “trivial” properties – the bare minimal get/set blocks. Running the code through ILDASM, here’s the output for the Text property:

.method public hidebysig specialname instance string

get_Text() cil managed

{

.custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )

// Code size 7 (0x7)

.maxstack 8

IL_0000: ldarg.0

IL_0001: ldfld string DemoClasses.Class1::'k__BackingField'

IL_0006: ret

} // end of method Class1::get_Text

.method public hidebysig specialname instance void

set_Text(string 'value') cil managed

{

.custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )

// Code size 8 (0x8)

.maxstack 8

IL_0000: ldarg.0

IL_0001: ldarg.1

IL_0002: stfld string DemoClasses.Class1::'k__BackingField'

IL_0007: ret

} // end of method Class1::set_Text

Looking at the MSIL, they do nothing but set and return the backing store. There is no logic, no null checks, no nothing. We can confirm this by running the entire class through Reflector. (Every .NET developer should have Reflector installed.) Here’s the output:

public string Text

{

[CompilerGenerated]

get

{

return this.k__BackingField;

}

[CompilerGenerated]

set

{

this.k__BackingField = value;

}

When using this class, therefore, it’s entirely possible to have null returned – so the client developer potentially has to do null checks to avoid NullReferenceExceptions. This violate’s John’s First Rule of Properties.

Conclusion

So in conclusion, properties in general are good and useful, but only if you’re using them effectively. Automatic properties are, in my mind, to be avoided as they generate trivial properties.

source: http://codeheaven.info

ASP.NET Performance Tips

2009-01-11T07:15:00.001-08:00

In the post below I am going to run down a short-list of some of the less-popular performance tips and the reasoning behind them. There are loads of blog postings and articles on asp.net performance enhancements, and I urge you to check those out as well. Onto the good stuff...

Session.ReadWrite versus Session.ReadOnly

It goes without saying that using the Session object will incur some performance overhead so if possible it should be turned off in the web.config.
That said, If you’re using the Session object to maintain session in your application...
Ensure Session.ReadOnly is true rather than using Session.ReadWrite across the application. There is more information in the link below, however the short story is there is no ReadWriterLock done if Session.ReadOnly = true. From this MSDN link, “ReaderWriterLock allows multiple threads to read a resource concurrently, but requires a thread to wait for an exclusive lock in order to write to the resource.” This will make a fairly significant difference if sessions are being managed in a state database, in which case only one-trip to the database is made when using ReadOnly, rather than two while using ReadWrite...which leads me to...

Optimizing your Session when using Out-Of-Process (E.g., State Server or State Database) Session Management

When using out-of-process session management methods objects must be serialized on their way into the state server or state database. Naturally, this means the data within the session object must be deserialized on the way back out [to the application]. In order for this to work you'll need to add the [Serializable] attribute to the beginning of the class that needs to go into the session object. For example...

[Serializable]

public class User{

    public string firstName; //Small text field

    public string lastName; //Another small text field

    public string usersLifeStory; //Is a large text field

As you may infer from my not-so-clever comments, there may be a problem with this. Let's say the user object needs to be stored in my session object [and therefore needs to be serializable], but there are some large, or otherwise inefficient fields in this object (such as non-primitive types). For the purposes of this example, let's also say that I don't need to store my user's life story in my session object because it's only displayed on one page where I can pull it from the application's database. The .NET framework makes it very easy to exclude properties within my object from being serialized. In fact, it's as easy as adding a few more attributes.

[Serializable]public class User{    public string firstName; //Small text field    public string lastName; //Another small text field    [NonSerialized]  //Prevents usersLifeStory from being serialized    public string usersLifeStory; //Is a large text field}

Easy peasy. Note that this means the "usersLifeStory" variable will not be accessible via the session object, of course.

Cache and...

think about your caching strategy before you go developing pages or user controls willy nilly. This will make using the .NET frameworks caching features much easier and will hopefully prevent you from having to make some logic work differently just so you can cache...this will make life especially easy when using features like output cache substitution and creating methods/strategies for querying your DB. Again, caching is something you should be thinking about before you launch your IDE.

There are tons of resources for learning about output caching, data caching, and the other features the .NET framework provides, so I'm going to skip that. I am, however, going to mention a really easy way to automagically cache return values from WebMethods/Web-services because I don't see it mentioned very much.

public class ExampleService{    //The cache duration attribute handles ALL caching for you        [System.Web.Services.WebMethod(CacheDuration=60)]    public string GetSomethingFromSomewhere(){        //Logic to get some data from a data-source    }}

That's it...Just add the CacheDuration attribute and you're good to go.

Update [1/5/2009]: Scott Mitchell has just posted a great, and concise article on per-request-caching. This is easy-to-use and powerful functionality. Read the article here.

Use HTTP Compression!!!

Maybe it's the luck of the draw here, but in my experiences most developers/sys admins/etc for some reason or another don't enable HTTP Compression, either deflate or GZIP. I'm sure there are some legitimate reasons for not enabling this functionality for some applications, but everyone else should absolutely have it turned on. Yes, it's going to cost some CPU but you can play with the settings. Bottom line is you will see a dramatic difference in page response times. Keep in mind you can configure HTTP Compression to compress a number of file-types, including CSS/JS/HTML/ASPX/ASMX/ASHX etc.

Also, I came across this post doing some research the other night - looks like Mads did some testing on GZIP versus Deflate. The results are interesting...I have yet to do some testing on my end.

For some reason or another the IIS6 team didn't give us an GUI to turn on/off HTTP Compression, so you need to go into the metabase. It's really only confusing the first time you do it. There are a number of good tutorials on the web. I think this is the one I used. You'll probably want to ensure HTTP Compression is on by using a tool like HTTPWatch, or its FireFox equal...the name of which currently slips my mind. Google is your friend :)

Be careful with the App_Themes folder!

I don't have any screen shots handy, and I'm not at my office so you're going to have to trust me on this but...Be careful what you put into app_themes. No matter what you reference in your pages using the