Dot Net Assemblies

 ASP.NET Assemblies in .Net

An assembly in ASP.NET is a collection of single-file or multiple files. The assembly that has more than one file contains either a dynamic link library (DLL) or an EXE file. The assembly also contains metadata that is known as assembly manifest. The assembly manifest contains data about the versioning requirements of the assembly, author name of the assembly, the security requirements that the assembly requires to run, and the various files that form part of the assembly.

The biggest advantage of using ASP.NET Assemblies is that developers can create applications without interfering with other applications on the system. When the developer creates an application that requires an assembly that assembly will not affect other applications. The assembly used for one application is not applied to another application. However one assembly can be shared with other applications. In this case the assembly has to be placed in the bin directory of the application that uses it.

This is in contrast to DLL in the past. Earlier developers used to share libraries of code through DLL. To use the DLL that is developed by another developer for another application, you have to register that DLL in your machine. In ASP.NET, the assembly is created by default whenever you build a DLL. You can check the details of the manifest of the assembly by using classes located in the System.Reflection namespace.

Thus you can create two types of ASP.NET Assemblies in ASP.NET: private ASP.NET Assemblies and shared assemblies. Private ASP.NET Assemblies are created whey you build component files like DLLs that can be applied to one application. Shared ASP.NET Assemblies are created when you want to share the component files across multiple applications. Shared ASP.NET Assemblies must have a unique name and must be placed in Global Assembly Cache (GAC). The GAC is located in the Assembly directory in WinNT. You can view both the manifest and the IL using ILDisassembler (ildasm.exe).

Stored Procedure Vs Functions

Stored procedures vs. functions

In many instances you can accomplish the same task using either a stored procedure or a function. Both functions and stored procedures can be custom defined and part of any application. Functions, on the other hand, are designed to send their output to a query or T-SQL statement. For example, User Defined Functions (UDFs) can run an executable file from SQL SELECT or an action query, while Stored Procedures (SPROC) use EXECUTE or EXEC to run. Both are instantiated using CREATE FUNCTION.

To decide between using one of the two, keep in mind the fundamental difference between them: stored procedures are designed to return its output to the application. A UDF returns table variables, while a SPROC can't return a table variable although it can create a table. Another significant difference between them is that UDFs can't change the server environment or your operating system environment, while a SPROC can. Operationally, when T-SQL encounters an error the function stops, while T-SQL will ignore an error in a SPROC and proceed to the next statement in your code (provided you've included error handling support). You

1>Procedure can return zero or n values whereas function can return one value which is mandatory.

2>Procedures can have input,output parameters for it whereas functions can have only input parameters.

3>Procedure allow select as well as DML statement in it whereas function allow only select statement in it.

4>Functions can be called from procedure whereas procedures cannot be called from function.

5>Exception can be handled by try-catch block in a procedure whereas try-catch block cannot be used in a function.

6>We can go for transaction management in procedure whereas we can't go in function.

7>Procedures can not be utilized in a select statement whereas function can be embedded in a select statement

1. Functions are compiled and executed at run time.
Stored procedures are stored in parsed and compiled format in the database.

2. Functions cannot affect the state of the database which means we cannot perform insert,delete,update and create operations on the database.
Stored Procedures can affect the state of the database by using insert,delete,update and create operations.

3 Functions are basically used to compute values. We passes some parameters to functions as input and then it performs some operations on the parameter and return output.
Stored procedures are basically used to process the task.

4.Function can not change server environment and our operating system environment.
Stored procedures can change server environment and our operating system environment.

5.Functions can not be invoked from SQL Statements. Execute. SELECT
operating system can be invoked from SQL Statements. Execute. SELECT

6.Functions can run an executable file from SQL SELECT or an action query.
operating system use Execute or Exec to run