Monday, November 30, 2009

MicroSoft Application blocks

MicroSoft Application blocks

    Application blocks help address the common problems that developers face from one project to the next. They are designed to encapsulate the Microsoft recommended best practices for .NET-based applications. In addition, they can be added to .NET-based applications quickly and easily. For example, the Data Access Application Block provides access to the most frequently used features of ADO.NET 4.0 in simple-to-use classes, thus boosting developer productivity. It also addresses scenarios not directly supported by the underlying class libraries.

Different applications have different requirements, and you will not find that every application block is useful in every application that you build. Before using an application block, you should have a good understanding of your application requirements and of the scenarios that the application block is designed to address.

Enterprise Library–January 2006 contains the following general purpose application blocks:

  • Caching Application Block. With this application block, developers can incorporate a local cache in their applications.
  • Cryptography Application Block. With this application block, developers can incorporate hashing and symmetric encryption in their applications.
  • Data Access Application Block. With this application block, developers can incorporate standard database functionality in their applications.
  • Exception Handling Application Block. With this application block, developers and policy makers can create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications.
  • Logging Application Block. With this application block, developers can include standard logging functionality in their applications.
  • Security Application Block. With this application block, developers can incorporate authorization and security caching functionality in their applications.

Enterprise Library also includes a set of core functions, including configuration, instrumentation, and object builder services. These functions are used by all other application blocks.

fig.Interdependence of application blocks

 

All the application blocks are designed to have a limited number of dependencies so that they can be used individually as well as with other application blocks. All application blocks depend on the Enterprise Library Core, which is a logical grouping made up of the following subsystems:

  • The Common assembly, including instrumentation.
  • Configuration helper classes, design-time components, and the Enterprise Library Configuration Console.
  • The ObjectBuilder subsystem.

Downloads

This page provides an overview of Enterprise Library for .NET Framework 4.0. The patterns & practices Enterprise Library is a library of application blocks designed to assist developers with common enterprise development challenges.


Javascript Differences in Mozilla Fir...

Javascript Differences in Mozilla Firefox and Internet Explorer


document.all

Internet Explorer 4 introduced the document.all DOM (document object model) to allow access to the various parts of the web page. Soon after that the standard DOM method getElementById was introduced and is therefore available in all version 5+ browsers. This means that the document.all references are only needed to support IE4.

document.all doesn’t work  mozilla why?

Some proprietary document objects such as document.all anddocument.layers are not part of the W3C DOM and are not supported in Mozilla. (There is partial undetectable support for document.all, though, in newer versions of Mozilla. However, that functionality only exists for compatibility with sites authored specifically for IE. You should not rely on Mozilla’s document.all support on new pages.) The methoddocument.getElementById() can be used instead.

In the Standards mode Mozilla does not generate implicit top-level JavaScript variable bindings for elements with the id or name attribute. The correct way to access an element by id is to call the document.getElementById() method with the id as a string as the argument.

Also, old client sniffers can shut out new browsers. The point of having a common API (the W3C DOM) is interoperability, and checking for a particular browser defeats that purpose. When working with the DOM, it is better to check for the existence of the methods and objects you are planning on using. For example, the existence of document.getElementById() can be checked as follows:

if(document.getElementById) {
  /* code that uses document.getElementById() */
}

1. Window/Body OnLoad

When dealing with a site that uses Master Pages, you lose some control, including the ability to declare a page specific event handler. There are ways around this, and I found that the following code example works pretty well.

<script language=”javascript” type=”text/javascript” for=”window” event=”onload“>
    if (document.all)
    {
        initialize();
    }
   else
    {
        window.document.addEventListener(“DOMContentLoaded”, initialize, true);
    }
</script>

2. Get Control Inner Text

Retrieving the text of an element is done by using element.innerText in Internet Explorer and element.textContent in Mozilla Firefox.

function getText(control)
{
if (document.all)
    {
return control.innerText;
    }
else 
    {
return control.textContent;
    }
}

function setText(control, value)
{
if (document.all)
    {
        control.innerText = value;
    }
else
    {
        control.textContent = value;
    }
}

3. Element Height and Width

To retrieve an element’s height and width, use element.currentStyle forInternet Explorer and element.style for Mozilla Firefox.

if (document.all)
{
    top += parseValue(element.currentStyle.borderTopWidth);
    …
}
else
{
    top += parseValue(element.style.borderTopWidth);
    …
}

4. Source Elements

To get a reference to the element that fired an event within an event handler, use event.srcElement for Internet Explorer and event.target for Mozilla Firefox.

function getSourceElement(event)
{
if (document.all)
    {
return event.srcElement;
    }
else
    {
return event.target;
    }
}

5. Firing Events

You can call fireEvent on an element in Internet Explorer, but it’s more complicated in Mozilla Firefox, requiring an event to be instantiated, initialized, and dispatched.

function fireClickEvent(control)
{
if (document.all)
    {
        control.fireEvent(“onclick”);
    }
else
    {
var clickEvent = window.document.createEvent(“MouseEvent“);
        clickEvent.initEvent(“click“, falsetrue);
        control.dispatchEvent(clickEvent);
    }
}

6. Window Height and Width

Internet Explorer exposes the visible content area dimensions usingdocument.body.offsetHeight and document.body.offsetWidth, whereasMozilla Firefox uses document.body.offsetWidth and window.innerWidth.

function getWindowHeight()
{
if (document.all)
    {
return document.body.offsetHeight;
    }
else 
    {
return window.innerHeight;
    }
}

function getWindowWidth()
{
if (document.all)
    {
return document.body.offsetWidth;
    }
else 
    {
return window.innerWidth;
    }
}

7. Why doesn’t Mozilla display my alt tooltips?

Contrary to a popular belief stemming from the behavior of a couple browsers running on the Windows platform, alt isn’t an abbreviation for ‘tooltip’ but for ‘alternative’. The value of the alt attribute is a textual replacement for the image and is displayed when the image isn’t.

Mozilla doesn’t display the alt attribute as a tooltip, because it has been observed that doing so encourages authors to misuse the attribute.

  • * When the alternative text is shown in a tooltip, some authors write badalt texts, because they intend the text as auxiliary tooltip text and not as a replacement for the image. (‘Bad’ in the sense that the textual alternative is less useful for people who don’t see the image.)
  • * When the alternative text is shown in a tooltip, other authors don’t want to supply textual alternatives at all, because they don’t want tooltips to appear. (Again, making things harder for people who don’t see the image.)

There is another attribute that Mozilla shows as a tooltip: title. In fact, the HTML 4.01 specification suggests that the title attribute may be displayed as a tooltip. However, this particular display method is not required and some other browsers show the title attribute in the browser status bar, for example.

At this point some people feel compelled to post a “But IE…” rant in the newsgroups or in Bugzilla. Please note that Mac IE 5 behaves in the same way as Mozilla when it comes to the alt and title attributes. Windows IE also shows the title attribute in a tooltip.

8. Does Mozilla support downloadable fonts?

Downloadable fonts are not supported.

Downloadable fonts are usually used on sites using writing systems for which proper support has been missing in browsers in the past. These sites (for example some Indian sites) code the text in Latin gibberish and then use a font that to the browser and operating system seems to be a Latin font but has eg. Devanagari glyphs, so that when the Latin gibberish is rendered with the font it seems to a human reader to be intelligible text in some language.

Obviously, that kind of ad hockery falls apart when Unicode-savvy browsers come along and render Latin gibberish as Latin gibberish (since that’s what is coded in the file from the Unicode point of view). Instead of providing support for downloadable fonts, Mozilla is addressing the real issue: support for various Unicode ranges.

However, there are still bugs related to support for Indic scripts on some platforms. For example, on Mac OS X Mozilla does not use the Devanagari font that comes with the system but can use a third-party font like TITUS Cyberbit.

lot of work has been put into Mozilla’s Unicode support. Supporting downloadable fonts in a cross-platform way would also be a lot of work and would potentially require navigating past a bunch of patents but the rewards would be small. For the purpose of rendering non-ISO-8859-1 characters Mozilla already provides Unicode support that, in the long run, is a lot better approach than using pseudo-Latin downloadable fonts separately on each site.

9. In Mozilla Firefox my style sheet doesn’t work! Why?

Here’s the check list:

  • 1. Does the HTML document validate? Styling misnested markup may cause strange effects.
    • * The <link> and <style> elements should be inside the <head> element.
  • 2. Does the CSS style sheet pass the syntax check? The CSS error handling rules require erroneous parts to be ignored rather than fixed by guessing.
    • * Lengths other than zero should be followed by a proper unit without a space between the number and the unit (eg. 1.2em).
    • * The character to use between the property name and the value is the colon—not the equal sign.
    • * HTML markup, such as <style>, does not belong in .css files.
    • * font-face is not a real CSS property. The property is font-family and@font-face is an at-rule.
    • * If @import is used, it should be the first thing in a CSS file.
    • * In Mozilla 1.8a4 and later (not in Firefox 1.0) CSS parsing errors are reported to the JavaScript console.
  • 3. Is the server sending the proper Content-Type header for CSS style sheets?
  • 4. Class names and ids are case-sensitive.
  • 5. The element selectors are case-sensitive with XML.
  • 6. Style sheet processing instructions are only allowed in the prolog of XML documents. Also, they only work in XML documents—not in documents served as text/html.
  • 7. width and height do not apply to non-replaced inline elements such as (by default) <span>.
  • 8. text-align: center; centers inline content within a block. It does not (and should not) center the block box itself. A block is centered by setting its margin-left and margin-right to auto and its width to a value that makes the block narrower than its containing block.

It is also possible, although not very likely, that you are seeing a bug.


Log4Net

Log4NET

Step 1:

DownLoad log4net.dll


Step 2:

Add below entry in web.config

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net"/>
  </configSections>
<log4net>
    <root>
      <level value="DEBUG" />
      <appender-ref ref="LogFileAppender" />
    </root>
    <appender name="LogFileAppender" type="log4net.Appender.RollingFileAppender" >
      <param name="File" value="e:\movieticket\log.txt" />
      <param name="AppendToFile" value="true" />
      <rollingStyle value="Date" />     
      <staticLogFileName value="false" />
      <DatePattern value=".yyyyMMdd"/>
      <layout type="log4net.Layout.PatternLayout">
        <param name="ConversionPattern" value="%-5p%d{yyyy-MM-dd hh:mm:ss} – %m%n" />
      </layout>
    </appender>
  </log4net>
</configuration>

Step 3:

using log4net;
using log4net.Config;

public partial class TestPage : System.Web.UI.Page
{
    private static readonly ILog logger = LogManager.GetLogger(typeof(TestPage));

    protected void Page_Load(object sender, EventArgs e)
    {
        DOMConfigurator.Configure();       
    }
    protected void btnRefresh_Click(object sender, EventArgs e)
    {
        logger.Debug("Here is a debug log.");

    }
}

Step 4:

Download Viewer



Friday, September 25, 2009

WSE 3.0 and WCF

How to Get Ready for WCF

Most developers are understandably ambivalent about a major upcoming release such as WCF. On the one hand, we welcome advancements in technology and the improvements in functionality and productivity that it will hopefully bring. On the other hand, we dread having to learn a new way of doing things, and we wonder whether we will be able to migrate our existing code to the new infrastructure.

These are valid concerns, especially with WCF. But the issue is less about WCF changing things than it is about things needing to change. Developers today are faced with multiple and often competing technologies for building distributed applications, including the classic choice between XML Web services vs. .NET Remoting. Certainly, there are cases where there is no overlap and no ambivalence and where one technology is clearly the better choice than another. But these technologies share too much in common to be treated differently. They are simply variations of the same technology. In the case of XML Web services and .NET Remoting, they are both concerned with remote distributed object and service invocation over a defined transport channel.

Microsoft is starting to address developer concerns by providing guidelines for how to get ready for WCF. It is already making sure to bring this topic up at professional conferences, and it will certainly continue to do so until the release of WCF. There has simply been too much investment in existing technologies for it not to.

WCF is obviously not a replacement for the entire set of .NET Framework functionality. Instead, it is focused on supporting distributed service-oriented applications with security, transaction support, and reliable messaging. WCF primarily extends four core technologies that are available today:

  • ASP.NET Web services (built with .asmx pages)

  • Web Services Enhancements (WSE)

  • System.Messaging

  • System.EnterpriseServices

Microsoft has stated that it will make the migration to WCF from current technologies a straightforward process. Here are some guidelines on how to get ready for WCF based on professional conferences, published white papers, and conversations with members of product development teams:

  • Build services using .asmx pages.

  • Use WSE 3.0 for additional, extended functionality, including security, policy, and secure conversation.

  • Build qualified XML schema files for all custom data types used by the service.

  • Use managed framework classes for integrating your services with MSMQ message queues and with COM+ components. Use the managed System.Messaging namespace for MSMQ, and the System.EnterpriseServices namespace for COM+ components.

  • Avoid using the HTTP Context object in your .asmx pages.

  • Avoid using .NET Remoting sinks and channels.

Given that WSE 3.0 is such an important part of this book, let's look in more detail at how you can use the toolkit to prepare for WCF

WSE 3.0 and WCF

WSE 3.0 allows developers to become early adopters of the next generation of service-oriented application technology. Every hour that you spend working with WSE 3.0 is an hour that you have contributed toward WCF. Applications that are built using WSE should migrate smoothly to the WCF framework, with only minor modifications required. If you choose to implement WSE today, then you should expect to accommodate changes to WSE between now and the release of WCF. It is unclear how many revisions WSE is expected to undergo prior to the release of WCF, but it is likely that we will only see service packs released, and they are not expected to negatively impact compatibility between WSE 3.0 andWCF. If anything, they should only make the compatibility tighter.


Feature Comparison of WSE 3.0 and WCF 



The main feature that is lacking in WSE 3.0 (compared to WCF) is that it does not provide wide system-level or infrastructure-level support for the enterprise aspect of service-oriented applications. Specifically, it does not provide support for transactions or reliable messaging. Certainly, WSE 3.0 provides many of the required parts, but it does not provide the whole. For example, WSE 3.0 provides support for message addressing, and it also integrates with MSMQ via the System.Messaging namespace classes. So WSE 3.0 gives you the ability today to custom build a service-oriented application that implements "reliable" messaging (via MSMQ) and which can process message addressing information and provide message correlation. But this is not the same as a built-in support infrastructure that manages these tasks for you.

These limitations are not a weakness of the WSE 3.0 technology. They simply underscore two things:

  1. Infrastructure support for message-based, service-oriented architecture is most effectively handled at the operating system level.

  2. WSE 3.0 allows early adopters to start designing and building their code for the future WCF infrastructure. More importantly, it gets developers thinking about application design in new ways. There is a large conceptual jump between traditional RPC-based applications and message-based, service-oriented applications.

With this being said, let's review the major feature areas of WSE 3.0 (which you should by now feel very familiar with) and explain where they fit within the WCF framework:

  • Security and policy specifications: The WS-Security and WS-Policy specifications are supported by the WCF connector.

  • Messaging specificationsWCF provides Messaging services that subsume the functionality currently provided by MSMQ. In addition, it provides support for reliable messaging. WSE does not currently provide comprehensive support for the WS-Reliable Messaging specification, but it does provide some of the component parts that you can cobble together to approximate the specification. Specifically, WSE includes support for WS-Addressing, and it integrates with MSMQ via the managed System.Messaging namespace.

  • Routing and referral specificationsWCF includes these within its Messaging services functionality.

  • Alternate transport channelsWCF provides support for several transport channels, including HTTP, TCP, and IPC. WSE 3.0 currently provides support for the same three channels, so you can begin coding with them today.

In closing, we hope that this book has ultimately convinced you of three important things:

  1. Message orientation and service orientation are the way to go.

  2. WCF provides a welcome level of support for this technology, which will increase developer productivity and minimize confusion by unifying today's disparate technologies.

  3. WSE 3.0 is an excellent way for developers to become early adopters for WCF.

Good luck with your future adventures in service-oriented architecture!




Saturday, September 19, 2009

OOPS


Difference between Abstract class and Interface in C# .Net

Interfaces are essentially having all method prototypes no definition but Abstract class can contain method definations also.

In short Interface is a abstract class having all methods abstract.

If you create a abstract class writing the abstract keyword in the declaration part then You only can inherit the class. You can not create an instance of this abstract class but can inherit the class and with creating the instance of the derived class you can access the method of the abstract class.

If you use a virtual keyword in a method then you can override this method in the subclass if you wish..

If you create a abstract method then you must override this method in the subclass other wise it shows error in the program.

You cannot instantiate Abstract Classes and Interfaces

An interface has all public members

 You can inherit abstract classes to other class

Abstract :
=========================================
1. Abstract class cannot be instantiated.
2. Abstract class may contain abstract methods and accessors.
3. Abstract modifier can be used with classes, methods and properties.
4. A non-abstract class derived from an abstract class must include actual implementations of all inherited abstract methods and accessors.
5. Abstract method declarations are only permitted in abstract classes.
6.Abstract class can contain abstract methods, abstract property as well as other members (just like normal class).
7.Interface can be used to achieve multiple inheritance; abstract class can be used as a single inheritance
8.Abstract class are known as partial abstract class whereas interface is known as fully abstract class
***********************************************************
Interface :
=========================================
1.Interfaces are similar to classes.
2.They can have member properties and methods.
3.All the properties and methods of interfaces are abstract.
4.They have no body, just the declaration.
5.Public, Protected, Private, Friend, Shared, Overrides, MustOverride, NotOverridable are permitted inside an interface.

6.It’s a pure abstract class.



Runtime polymorphism

using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
A objA = new A();
B objB = new B();
sendmsg(objA);
sendmsg(objB);
Console.ReadLine();
}
public static void sendmsg(imsg objmsg)
{
objmsg.displaymessage();
}
}

interface imsg
{
void displaymessage();
}
class A : imsg
{
public void displaymessage()
{
Console.WriteLine("this is class A displaymsg()");
}
}

class B : imsg
{
public void displaymessage()
{
Console.WriteLine("this is class B displaymsg()");
}
}
}

WCF OverView PPT