[SQLServer] SQLServer2008: Workgroup VS Standard

You might be in doubt when choosing between SQLServer2008 Standard or Workgroup edition (most people rule out the Enterprise edition since it's 7500 € or so) - here's a list of the differences bewteen the two (in red most relevant).

Reporting Services memory limits : unlimited for Standard - 4GB for workgroup

Standard features not supported by workgroup:

Standard algorithms
Data mining tools: wizards, editors, query builders
SQL Server Analysis Services service
SQL Server Analysis Services backup
General performance/scale improvements
SSIS Designer including VSTA scripting
Integration Services service, wizards, and command prompt utilities
Basic tasks and transformations
Log providers and logging
Data profiling tools
Additional sources and destinations: (Raw File source, XML source, DataReader destination, Raw File destination, Recordset destination, SQL Server Compact destination, SQL Server destination)
Business Intelligence Development Studio
MDX edit, debug, and design tools
Standard performance reports
Plan guides
Plan freezing for plan guides
Policy-based best practices
Multi-server policy-based management
Heterogeneous subscribers
Database mirroring (witness only)
Failover clustering (very limited in workgroup)
Dynamic AWE
Failover without client configuration
Automatic corruption recovery from mirror

The Workgroup edition apparently includes 5 CAL licences (a license is around 130 €) - I see that as the only possible reason you might go for it since the price of the piece of software itself is very similar (around 600 € for the workgroup against 750 for the standard).

For more details http://msdn.microsoft.com/en-us/library/cc645993.aspx

Google Chrome Drawbacks (for lazy developers)

If as a user and software engineer I am nothing less than aroused by Google Chrome release after reading the brilliant comic (Google Chrome Comic) they are using as presentation, as a mere nitty-gritty developer I am somewhat worried about the fact that we'll have to bitch with yet another browser in order to produce cross-browser web apps.

It might seems a little obtuse (or plain lazy) - but yet at the moment if you are developing a ASP.NET application and you set as a system requirement IE x - no one complains.
On the other end we all now that if you start requiring something different than IE (i.e. Firefox or Google Chrome now) complaints will flood back like crazy.

Hence you have two possible ways to go:

1) develop your ASP.NET web-app optmized for IE (short for 'we didn't even bother running it even once on Firefox or anything else, so if it breaks it is YOUR problem')
2) develop a cross-browser application (short for 'we developed it on Firefox and que serà serà')

Option 2 could now assume a hell of a new meaning (I am talking stuff like adding yet another 'if' to all your javascripts) - possibly nothing will change since the google guys are sound guys and the webkit blah blah blah and the new javascript virtual machine (V8 - that has a specific API which can be included by other browsers and so forth) hell yeah.

Anyway apart from complaining regardless (I am a developer - it's my nature), I am looking forward to put my hands on the thing and assist to a new chapter of Browser Wars (coming soon on your machines and portable devices).

[.NET] Difference between GetType and typeof

GetType and typeof come in useful when you need to mess with objects types before casting and so forth.

The difference between the two is the following:
GetType is a method of the object class - from which everything inherits in .NET - while typeof is an expression that operates on a type (same as you declare variables with).
While GetType takes into account inheritance and gives you back the actual Type of your instance at runtime - typeof just resolves the type into a System.Type object (jeez) at compiletime.

To cut a long story short: GetType extracts the Type from the object - typeof extracts the correspondent System.Type object from a type (declaration).

Have a look @ an example and it will be clearer:
////////////////////////////////////////////////
Type myType;
//the following blocks of code are equivalent
{
myType = typeof(int);
}

{
int i;
myType = i.GetType();
}
/////////////////////////////////////////////////

Good stuff - ain't it? No, it ain't - this post is child of absolute boredom.

[.NET] Difference between casting and 'as' operator in C#

This is an easy one - but it can be useful to someone so here it comes:

The 'as' operator in C# is a tentative cast - if it's impossible to cast (types are not compatible) instead of throwing an exception as the direct cast the 'as' operator sets the reference to null.

So you can have something like:

MyClass myObj = new MyClass();
MyOtherClass myOtherObj = myObj as MyOtherClass;
if (obj != null)
{
//cast was successful
}
else
{
//a little bit of a fuck-up
}

The correspondent in VB is the TryCast (usage is the same as DirectCast but it doesn't throw any exception).

[.NET] How to Simulate HttpContext Cookies

This might be useful if you're developing an ASP.NET application and you need to Unit Test (for example with NUnit or some other unit testing framework) some .NET component but you cannot do it because your classes use cookies.

using System.Web; 
using System.IO; 
using System.Web.Hosting; 
//...
//...
//...
//Initialize this stuff with some crap
string appVirtualDir = "/"; 
string appPhysicalDir = @"C:\Documents and Settings\"; 
string page = @"localhost"; 
string query = string.Empty; 
TextWriter output = null; 
//Create a SimpleWorkerRequest object passing down the crap
SimpleWorkerRequest workerRequest = new SimpleWorkerRequest(appVirtualDir, appPhysicalDir, page, query, output);
//Create your fake HttpContext instance 
HttpContext.Current = new HttpContext(workerRequest);
//Create your fake cookie 
HttpCookie myCookie = new HttpCookie("myTestCookie", "value"); 
HttpContext.Current.Request.Cookies.Add(myCookie);
//...
//... somewhere else in your code
//...
//create a cookie object 
HttpCookie anotherCookie;
//Get your cookie from the HttpContext 
anotherCookie = HttpContext.Current.Request.Cookies.Get(0);
string cookieName = anotherCookie.Name;//cookieName should be now "myTestCookie" 
string cookieValue = anotherCookie.Value;//cookieValue should be now "value" 

You can use the same strategy to stuff the HttpContext with whatever you may need - maybe your problem are not cookies but some other HttpContext property your classes use.

Anyway I didn't figure this out all by myself - most of the inspiration came from this post on Haacked: Simulating HttpContext (btw - he says he has a better version of the post in the first line but for what I needed it I do not agree).