Friday, November 14, 2014

Design Patterns

Design Patterns


In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

Uses of Design Patterns


Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.
In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.

Cont...

Monday, November 3, 2014

Difference between var and dynamic in C#

Introduction

The type keyword 'var' was introduced in C# 3.0 (.NET 3.5 with Visual Studio 2008) and the type 'dynamic' was introduced in C# 4.0 ( .NET 4.0 with Visual Studio 2010). Let us see the difference between these two

Background

Variables declared with var are implicitly but statically typed. Variables declared with dynamic are dynamically typed. This capability was added to the CLR in order to support dynamic languages like Ruby and Python.
This means that dynamic declarations are resolved at run-time, var declarations are resolved at compile-time. 

Table of difference 

vardynamic
Introduced in C# 3.0Introduced in C# 4.0
Statically typed – This means the type of variable declared is decided by the compiler at compile time.Dynamically typed - This means the type of variable declared is decided by the compiler at runtime time.
Need to initialize at the time of declaration.
e.g., var str=”I am a string”;
Looking at the value assigned to the variable str, the compiler will treat the variable str as string.
No need to initialize at the time of declaration.
e.g., dynamic str;
str=”I am a string”; //Works fine and compiles
str=2; //Works fine and compiles
Errors are caught at compile time.
Since the compiler knows about the type and the methods and properties of the type at the compile time itself
Errors are caught at runtime
Since the compiler comes to about the type and the methods and properties of the type at the run time.
Visual Studio shows intellisense since the type of variable assigned is known to compiler.Intellisense is not available since the type and its related methods and properties can be known at run time only

e.g., var obj1;
will  throw a compile error since the variable is not initialized. The compiler needs that this variable should be initialized so that it can infer a type from the value.
e.g., dynamic obj1;
will compile;
e.g. var obj1=1;
will compile
var obj1=” I am a string”;
will throw error since the compiler has already decided that the type of obj1 is System.Int32 when the value 1 was assigned to it. Now assigning a string value to it violates the type safety.
e.g. dynamic obj1=1;
will compile and run
dynamic obj1=” I am a string”;
will compile and run since the compiler creates the type for obj1 as System.Int32 and then recreates the type as string when the value “I am a string” was assigned to it.
This code will work fine.

Wednesday, October 29, 2014

Customised OutputCache with VaryByCustom

Customised OutputCache with VaryByCustom

In ASP.NET (MVC or not), it is possible to easily cache the rendering of a web page.
Take the case of an ASP.NET MVC project :

   1:  [OutputCache(Duration = 3600, Location = OutputCacheLocation.Client)]
   2:  public ActionResult Index()
   3:  {
   4:      return View();
   5:  }

We use the attribute "OutputCache" to cache the page. This case is very simple, the page is cached for one hour (3600 seconds) on the client side.

Now imagine that the "Index" view contains the actual time...

   1:  <p>@DateTime.UtcNow.ToLongTimeString()</p>

If you debug your website, you will see that the time is the same after a refresh. You can try this during an hour, it will still be the same.
Now we change the view's code with this:

   1:  <p>@DateTime.UtcNow.ToLongTimeString()</p>
   2:  <a href="?parameter=1">test</a><br />

And the controller's code with this:

   1:  [OutputCache(Duration = 3600, VaryByParam = "parameter", Location = OutputCacheLocation.Client)]
   2:  public ActionResult Index()
   3:  {
   4:      return View();
   5:  }

If you debug your website and you click on the link "test", you will have 2 cached versions : one with no parameter and one with "parameter=1". If you change the value of "parameter", you will have another cached version. This kind of functionality can be useful with query parameters (attention: choose the good time of caching according to your needs...). If you need to put more than one parameter, you can separate each parameters like this : VaryByParam = "parameter1;parameter2;parameter3"

When I was developing the homepage of a project (and the layout of the website), I encountered the following problem : I wanted to cache the homepage in the same way but there was the name of the current user in the top of the page (or nothing if there were not an authenticated user...).

You can see here a part of the top of the page:

   1:  @if (User.Identity.IsAuthenticated)
   2:  {
   3:      <li class="dropdown">
   4:          <a href="#" class="dropdown-toggle">@User.Identity.Name</a>
   5:          <ul class="dropdown-menu">
   6:              <li><a href="#">Account parameters</a></li>
   7:              <li><a href="@Url.Action("LogOff", "Account")">Log off</a></li>
   8:          </ul>
   9:      </li>
  10:  }
  11:  else
  12:  {
  13:      <li><a href="@Url.Action("Register", "Account")">Register</a></li>
  14:      <li><a href="@Url.Action("LogOn", "Account")">Log on</a></li>
  15:  }

If I test this code with a OutputCache attribute with a duration of one hour, I will get a bad result : imagine that I try to debug the website and the user is already authenticated... We will see his name on the top of the page and that is normal. Now I click on the logout link : the "LogOff" action will redirect me on the homepage and I will still see the name of the user on the top of the page. He is not authenticated but the homepage is in cache for one hour and I will get the same result with or without an authenticated user.

I could try a workaround with a parameter but I found a simpler and cleaner solution: theVaryByCustom parameter in OutputCache attribute.

Finally, here is the code of my controller :

   1:  [OutputCache(Duration = 3600, VaryByCustom="UserConnected", Location = OutputCacheLocation.Client)]
   2:  public ActionResult Index()
   3:  {
   4:      return View();
   5:  }



And the last thing that we need... Put the following code in Global.asax.cs:

   1:  public override string GetVaryByCustomString(HttpContext context, string arg) 
   2:  {
   3:      return arg.ToLower() == "userconnected" ? User.Identity.Name : string.Empty;
   4:  }

With this custom parameter for OutputCache attribute, we can have a cached page when there is no authenticated user and one cached page by User. It is perhaps not the solution to all your problems but it shows a nice utility of "VaryByCustom".

Facebook C# SDK and logout on Windows Phone

Facebook C# SDK and logout on Windows Phone


(Facebook C# SDK version: 5.4.1.0)

Most tutorials explain how to connect to Facebook for a Windows Phone application... But the logout is rarely mentioned while it is a very important feature for the users of your application.

So, how can you propose the possibility of logout to your users? We suppose that you already have a WebBrowser used for the login: we will call it "FacebookWebBrowser".

To make a logout from this WebBrowser, you just have to do that:

   1:  FacebookWebBrowser.Navigate(new Uri(String.Format("https://www.facebook.com/logout.php?next={0}&access_token={1}", _loginUrl, _accessToken)));

The _loginUrl comes from the "GetLoginUrl" method (from the Facebook C# SDK) and the_accessToken comes from a previous login on Facebook.

Nothing complicated but very useful to know!

Windows Azure and Application Pool Timeouts

Windows Azure and Application Pool Timeouts


This article may help you if you use Windows Azure and you want your application to always responds as quickly even after a long period without use...

With default parameters, your app pool is shut down after 20 minutes of inactivity and your application will take a bit more time to respond.

You can simply change the settings if you want your application pool is never shut down:

- First step: create a new folder called "tasks" at the root of your Web Project and add a new file called "timeout.cmd" with this line of command: 

   1:  %windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00

Once the file created, you need to put the "Copy to Output Directory" property to "Copy Always".



- Second step: add this into ServiceDefinition.csdef (at same level than "<Sites>", "<Endpoints>", ...):

   1:  <Startup>
   2:        <Task commandLine="tasks\timeout.cmd"
   3:              executionContext="elevated" />
   4:  </Startup>

Programmatically remove HTTP response headers

By default, all the responses of your server will be sent with some embarrassing details...



For an ASP.NET MVC web application, you have these headers :


  • Server: which is added by IIS.
  • X-AspNet-Version: which is added at the time of Flush in HttpResponse.
  • X-AspNetMvc-Version:which is  added by MvcHandler in System.Web.dll.
  • X-Powered-By: which is added by IIS.

Hackers will be happy to know the exact version of the used Framework: if your server has not been updated for a while and a major security vulnerability was found for the version of the Framework you are using, you will help them...

Moreover, these headers add a weight to all your responses (a few bytes, but I like optimizing...)

If you want to remove these headers, here are the steps to follow:

1) Removing the Server header: go to Global.asax.cs, add the Application_PreSendRequestHeaders event with this code:

   1:  protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
   2:  {
   3:      var app = sender as HttpApplication;
   4:      if (app == null || !app.Request.IsLocal || app.Context == null)
   5:          return;
   6:      var headers = app.Context.Response.Headers;
   7:      headers.Remove("Server");
   8:  }

2) Removing the X-AspNetMvc-Version header: go to Global.asax.cs, modify theApplication_Start event with this code: 


   1:  protected void Application_Start()
   2:  {
   3:      ...
   4:      MvcHandler.DisableMvcResponseHeader = true;
   5:      ...
   6:  }

3) Removing the X-AspNet-Version header: edit the web.config and add this element in the system.web section:

   1:  <system.web>
   2:      ...
   3:      <httpRuntime enableVersionHeader="false" />
   4:      ...
   5:  </system.web>

4) Removing the X-Powered-By header: edit the web.config and add this code in the system.webServer:

   1:  <system.webServer>
   2:      ...
   3:      <httpProtocol>
   4:          <customHeaders>
   5:              <remove name="X-Powered-By" />
   6:          </customHeaders>
   7:      </httpProtocol>
   8:      ...
   9:  </system.webServer>

The work is done, the responses of your server will be lighter and will not give important information about its versions.