Advertisement

  • Assemblies in Dot Net
    Assemblies are the fundamental building blocks of a .NET Framework application. They contain the types and resources that make up an application and describe those contained types to the common language runtime. Assemblies enable code reuse, version control, security, and deployment.
    Put simply, an assembly is a project that compiles to an EXE or a DLL file. Although .NET EXE and DLL files resemble their predecessors externally, the internal structure of an assembly is quite different from that of an EXE or DLL created with earlier development tools. An assembly consists of four internal parts:
    The assembly manifest, or metadata. This contains information about the assembly that the common language runtime uses to obtain information about the assembly. The type metadata, which exposes information about the types contained within the assembly.
    The intermediate language code for your assembly.
    Resource files, which are non-executable bits of data, such as strings or images for a specific culture. The assembly manifest contains the metadata that describes the assembly to the common language runtime. The common language runtime then uses the information in the assembly manifest to make decisions about the assembly's execution. An assembly manifest contains the following information: Identity.
    It contains the name and version number of the assembly, and can contain optional information such as locale and signature information. Types and resources. It contains a list of all the types that will be exposed to the common language runtime as well as information about how those types can be accessed. Files: It contains a list of all files in the assembly as well as dependency information for those files. Security permissions
    The manifest describes the security permissions required by the assembly. If the permissions required conflict with the local security policy, the assembly will fail to execute. For the most part, the developer does not have to be concerned with the contents of the assembly manifest. It is compiled and presented to the common language runtime automatically. The developer does, however, need to explicitly set the metadata that describes the identity of the assembly. The identity of the assembly is contained in the AssemblyInfo.vb or .cs file for your project. You can set identity information for your assembly by right-clicking the AssemblyInfo icon and choosing View Code from the drop-down menu. The code window will open to the AssemblyInfo code page, which contains default null values for several assembly identity attributes. The following code example shows an excerpt from the AssemblyInfo file.
    Creating Class Library Assemblies
    You will frequently want to create class library assemblies. These represent sets of types that can be referenced and used in other assemblies. For example, you might have a custom control that you want to use in several applications or a component that exposes higher math functions. Such an assembly is not executable itself, but rather must be referenced by an executable application to be used. You can create class library assemblies and control library assemblies by using the templates provided by Microsoft Visual Studio .NET.
    The class library template is designed to help you create an assembly of types that can be exposed to other applications, and the Microsoft Windows control library template is provided to assist you in building assemblies of custom controls.
    Creating Resource Files
    The .NET Framework includes a sample application called ResEditor that can be used for creating text and image resource files. The ResEditor application is not integrated with Visual Studio .NET-it must be run separately. In fact, it is supplied as source code files and must be compiled before it can be used.
    The ResEditor source files are located in the FrameworkSDKSamplesTutorialsresourcesandlocalizationreseditor folder, which is in the folder that Visual Studio .NET is installed in. You can build the application using either the batch file supplied in that folder or by adding the source files to an empty Visual Studio project, configuring, and then building them.
    Embedding Resources
    Once you have created resource files, you can embed them in your assembly. This allows you to package resources into the same assembly as the code files, thus increasing the portability of your code and reducing its dependence on additional files. To embed an externally created resource into your assembly, all you have to do is add the file to your project. When the project is built, the resource file will be compiled into the assembly.
    Creating Resource Assemblies
    You can create assemblies that only contain resources. You might find this useful in situations where you expect to have to update the data contained in resource files, but do not want to have to recompile your application to update it.
    Creating Satellite Assemblies
    When creating international applications, you might want to provide different sets of resources for different cultures. Satellite assemblies allow different sets of resources to automatically be loaded based on the CurrentUICulture setting of the thread. You learned how to automatically generate applications for localization in Chapter 8. In this section, you will learn how to create additional satellite assemblies and incorporate them into your application.
    Visual Studio .NET allows you to effortlessly create satellite assemblies. All you need to do to create a satellite assembly is to incorporate alternate sets of resource files that are appropriately named into your application. Visual Studio .NET does the rest upon compilation.
    To be incorporated into a satellite assembly, your resource file must follow a specific naming scheme based on the culture it is designed for. The name of a resource file for a specific culture is the same as the name of the resource file for the invariant culture, and the culture code is inserted between the base name and the extension. Thus, if we had a resource file named MyResources.resx, a resource file containing alternate resources for neutral German UIs would be named MyResources.de.resx. And a version of the file containing German resources specific for Luxembourg would be named MyResources.de-LU.resx.
    Once these alternate versions of the file are added to your solution, they will automatically be compiled by Visual Studio .NET into satellite assemblies, and a directory structure for them will be created. At run time, the culture-specific resources contained in these files will automatically be located by the common language runtime.
    Retrieving Resources at Run Time
    At run time, you can use the ResourceManager class to retrieve embedded resources. A ResourceManager, as the name implies, manages access and retrieval of resources embedded in assemblies. Each instance of a ResourceManager is associated with an assembly that contains resources.
    You can create a ResourceManager by specifying two parameters: the base name of the embedded resource file and the assembly in which that file is found. The new ResourceManager will be dedicated to the embedded resource file that you specify. The base name of the file is the name of the namespace that contains the file and the file without any extensions.
    The assembly parameter refers to the assembly that the resource file is located in. If the assembly that contains the resources is the same assembly that contains the object that is creating the ResourceManager, you can get a reference to the assembly from the type object of your object.
    Understanding Private and Shared Assemblies
    Most of the assemblies you create will be private assemblies. Private assemblies are the most trouble free for developers and are the kind of assembly created by default. A private assembly is an assembly that can be used by only one application. It is an integral part of the application, is packaged with the application, and is only available to that application. Because private assemblies are used by one application only, they do not have versioning or identity issues. Up to this point, you have only created private assemblies.
    When you add a reference to a private assembly to your project, Visual Studio .NET creates a copy of the DLL containing that assembly and writes it to your project folder. Thus, multiple projects can reference the same DLL and use the types it contains, but each project has its own copy of the DLL and therefore has its own private assembly.
    Only one copy of shared assemblies, on the other hand, is present per machine. Multiple applications can reference and use a shared assembly. You can share an assembly by installing it to the Global Assembly Cache. There are several reasons why you might want to install your assembly to the Global Assembly Cache. For example:
    Shared location. If multiple applications need to access the same copy of an assembly, it should be shared.
    Security. The Global Assembly Cache is located in the C:WINNT (Microsoft Windows 2000) or WINDOWS (Microsoft Windows XP) folder, which is given the highest level of security by default.
    Side-by-side versioning. You can install multiple versions of the same assembly to the Global Assembly Cache, and applications can locate and use the appropriate version.
    For the most part, however, assemblies that you create should be private. You should only share an assembly when there is a valid reason to do so. Sharing an assembly and installing it to the Global Assembly Cache requires that your assembly be signed with a strong name.

    more

  • c sharp and vb.net a compariosn

    Advantages VB.NET:

    Has support for optional parameters which makes COM interoperability much easy.

    With Option Strict off late binding is supported.Legacy VB functionalities can be used by using Microsoft.VisualBasic namespace.

    Has the WITH construct which is not in C#.

    The VB.NET part of Visual Studio .NET compiles your code in the background.

    While this is considered an advantage for small projects, people creating very large projects have found that the IDE slows down considerably as the project gets larger.

    Advantages of C#

    XML documentation is generated from source code but this is now been incorporated in Whidbey.

    Operator overloading which is not in current VB.NET but is been introduced in Whidbey.

    Use of this statement makes unmanaged resource disposal simple.

    Access to Unsafe code. This allows pointer arithmetic etc, and can improve performance in some situations. However, it is not to be used lightly, as a lot of the normal safety of C# is lost (as the name implies).This is the major difference that you can access unmanaged code in C# and not in VB.NET.

    System exceptions and application exceptions:

    All exception derives from Exception Base class. Exceptions can be generated programmatically or can be generated by system. Application Exception serves as the base class for all application specific exception classes. It derives from Exception but does not provide any extended functionality.

    You should derive your custom application exceptions from Application Exception. Application exception is used when we want to define user defined exception, while system exception is all which is defined by .NET.

    Preventing de compilation of dot net DLL:

    By design .NET embeds rich Meta data inside the executable code using MSIL. Any one can easily decompile your DLL back using tools like ILDASM (owned by Microsoft) or Reflector for .NET which is a third party. Secondly there are many third party tools which make this decompiling process a click away.

    So any one can easily look in to your assemblies and reverse engineer them back in to actual source code and understand some real good logic which can make it easy to crack your application.

    The process by which you can stop this reverse engineering is using "obfuscation". It's a technique which will foil the decompilers. There are many third parties (XenoCode, Demeanor for .NET) which provide .NET obfuscation solution. Microsoft includes one that is Dotfuscator Community Edition with Visual Studio.NET.

    more

  • asp.net Validation Controls
    A validation control enables us to validate an input and display an error message if necessary. It is very much like other server-side controls with certain additional methods and properties. First, the server treats it as an invisible control.

    After the user has entered erroneous data, it becomes visible. It is a powerful, rapid application development feature; however, a developer needs to understand its behavior and the methods thoroughly before he or she can appreciate it.

    There are certain rough edges in the Beta 2 version, which hopefully will be polished in the final product.The best strategy to learn the family of controls is to learn them one at a time, and finally to apply the summary validation.

    Various types of validation controls are as follows:

    1. RequiredFieldValidator Checks if the input control has any value.
    2. RegularExpressionValidator Checks the value against a regular expression (pattern).
    3. CompareValidator Checks if the value is acceptable compared to a given value or compared to the content of another control.
    4. RangeValidator Checks if the input control’s value is within a specified range.
    5. CustomValidator Allows you to develop custom validation.
    6. ValidationSummary Reports a summary of all errors.

    By default, each of the validation controls performs the validation task at the client-side as well as at the server-side. Except for the RequiredFieldValidator, all other validation controls treat an empty field as a valid field.Therefore, we will need to apply a RequiredFieldValidator to every input field that we want to validate.

    You can attach more than one validation control to an input.

    For example we may use a RequiredFieldValidator and a RangeValidator to ensure that an input
    is not empty and falls within a specified range.

    There are a number of common properties in these controls.The major ones are:

    1. ErrorMessage In case of an error, the system displays this message at the location of the control, and in the summary report, if any.

    2. Display A validation control is kept invisible until a bad input is entered. In case of a bad input, the system has to display the error message.

    The display mechanism can be handled in one of three ways.

    1. Display= “static” Initially, enough room in the page is reserved for the expected error message.

    2. Display= “dynamic” No room is initially reserved. In case of an error, the message is displayed by displacing existing contents of the page.

    3. Display=“none” The message won’t be displayed at the location of the control; however, it will be reported in the summary report, if any.

    more

Subscribe to: Posts (Atom)