Code formatter for blog posting

After some time searching for a good code formatter i came accross this http://www.manoli.net/csharpformat/. hope this will help other as well.

OData Service Custom Security

I need to create an Odata service POC that allows to return result only to authenticated users. I google about authentication with OData and found that there are many options like

1.Windows Auth
2.Forms Auth
3.Claim based Auth
4.Anonymous Auth

what i needed is much simple and easy that is somehome related to claim based auth. i have configured a QueryInterceptor on VwUsers to check token parameter and if found return the result otherwise return error. i have used Query String to get the token you can experiment this with http headers as well.


In web.config you have to set

authentication mode="off" in authentication element

This will be the service code:

 public class CareService : DataService<NorthwindEntities>

    {

        // This method is called only once to initialize service-wide policies.

        public static void InitializeService(DataServiceConfiguration config)

        {

            // TODO: set rules to indicate which entity sets and service operations are visible, updatable, etc.

            // Examples:

            // config.SetEntitySetAccessRule("MyEntityset", EntitySetRights.AllRead);

            // config.SetServiceOperationAccessRule("MyServiceOperation", ServiceOperationRights.All);

           

            config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);

            //Set a reasonable paging site

            //config.SetEntitySetPageSize("*", 25);

            config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;

        }

        [QueryInterceptor("VwUsers")]

        public Expression&gt; OnQueryVwUsersHeaders()
        {
            var request = HttpContext.Current.Request;
            if (!string.IsNullOrEmpty(request.QueryString["token"]))
            {

   

               //token verification here

                return (VwUser p) =&gt; true;

            }

            else

            {

                throw new DataServiceException(401,

                 "The user does not have permission to view Users");

                //return (VwUser p) =&gt; false;

            }

        }

    }

MS SQL sp_executesql problem with query plan

I have been using sp_executesql to run my query to take advantage of its query plan caching and better security that prevent injection attacks on web application. but after some time working on project i found that when row counts in a table exceeds million records and your query becomes so complex that even might contain 15-30 joins in such queries i found problems with sp_executelsql.

sp_executelsql is meant to re-use compiled query plans, so it doesn't re-sniff parameters when the same query again hits it so it ends up in using a plan which might be very slow(will tell you why a slower query plan) with the current parameter values.it appears to be that sp_executesql uses a different method for choosing indexes and apparently it is a broken method compared to a plain text query running in SSMS.

For Example:

What differs is the select query on a table contains many join under a sp_executesql is fed via a chain of nested loops while the text query is fed via a chain of hash matches. The construction of the views appears identical between the two version (which I would expect). Unfortunately, the remainder is very complex and they appear to be doing radically different things in the middle; even pulling an "actual" execution plan doesn't give actual execution times for the various sub components of the query. Really, I can't see any reason for sp_executesql to be choosing anything differently, but it reliably constructs a significantly slower plan.

Solution i found so far:
Parameter sniffing is a solution to this, so you could rename the parameters names or you might even swap the column names in where clause that cause sp_executesql to recreate a query plan instead of using an old slow plan, of course this is not the solution but it won't cache a slower plan for so long.

How Reference Types are created and stored in .net

When a reference type is created (class , delegate, interface, string, or object), it's allocated onto the heap..Net has four different heaps: (gen0, gen1, gen2)(Small object Heap), and LOH (Large Object Heap). Everything that's 85k or smaller goes on one of the first three heaps, depending on creation time (moved from gen0 to gen1 to gen2, etc). Objects larger than 85k get placed on the LOH. The LOH is never compacted, so eventually, allocations of the type I'm doing will eventually cause an OOM error as objects get scattered about that memory space. These are known as managed heaps.
To create an object, all you need to do is use the new keyword; .NET will take care of creating, initializing and placing the object on the right heap, and reserving any extra memory necessary. After that you can pretty much forget about that object, because you don't have to delete it when you're finished with it.
when you create a reference type object using new keyword it is placed on heap and its reference is used mostly in current running stack. there are other possible sources where your object could be used as refrence:

1. global/static object references
2. CPU registers
3. object finalization references (more later)
4. Interop references (.NET objects passed to COM/API calls)
5. stack references(mostly used here)

These 5 are actually GC root nodes from where object reference hierarchy is formed.Imagine the classic Customer class, which usually has a collection storing Order classes. When an Order is added to the order collection, the collection itself then holds a reference to the added order. If the instance of the Customer class had a stack reference to it as well.
this is how hierarchy is formed for a complex object, this is how GC see the references.
e:g. stack-reference for Customer object -> reference to List object of orders -> reference individual orders.
anything that loose reference from these 5 roots is prone to GC.
how memory is allocated to objects is bit complex and it usally grow by time as specified http://msdn.microsoft.com/en-us/magazine/cc163791.aspx
a simple example could be:

class MyClass { 
    string Test="Hello world Wazzup!"; 
    byte[] data=new byte[86000];  }

It's easy to assume that the size of MyClass when allocated includes:
• 19 characters
• 86,000 bytes.
In fact, the object's size will only include general class stuff, and the memory required to store the object pointers to the string and the byte array (class level variables), which are then separately allocated onto the heaps. The string will be allocated on the SOH, and its object reference held by the instance of the class; the byte array will be allocated onto the LOH, as it's bigger than 85 KB.
SOH can be compacted and there will be no fragmentation in it, while LOH can have fragmentation in memory.