Varad, The .NET Guy!

ASP.NET::Compilation

 Technical details on how ASP.NET pages are compiled to native code when requested.

1. Machine boots.
2. Request for MyPage.aspx comes in (first time).
3. MyPage.aspx compiles to an assembly (we'll call it MyPage.dll).
4. The portions of MyPage.dll that are needed for execution are JITed to memory.
5. Page execution completes. The JITed code stays in memory.
6. A new request for MyPage.aspx comes in. The page hasn't changed. The JITed code that is still in memory runs.
7. The source for MyPage.aspx changes.
8. A new request for MyPage.aspx comes in. MyPage.aspx compiles to an assembly, JITs, and executes. The JITed code stays in memory.
9. A new request for MyPage.aspx comes in. The page hasn't changed. The JITed code that is still in memory runs.
10. IIS is stopped and started.
11. A new request for MyPage.aspx comes in. The page hasn't changed. Because IIS was stopped and started, the JITed code is no longer in memory. The existing MyPage.dll JITs and executes. This new JITed code stays in memory.

The JITing process is similar with any .NET code, including .DLL's in your ASP.NET application and .DLL's and .EXE's in WinForms applications. Since there's no page, and since the assembly is already created, these steps don't take place. Instead, methods in the assembly are JITed to native code in memory when they're called (step 4 above), and unloaded from memory when the calling application (the Windows .EXE, or IIS and the ASP.NET worker process as in step 10 above) is closed.

Please Note:

• Step 3: Note that a code file (.CS for C# code, .VB for Visual Basic code or no code) gets created from the .ASPX page first, then this file gets compiled into an assembly (.DLL).
• Step 3: The MyPage.dll assembly won't have a friendly name like that. Expect more like "yxgq4-hz.dll". Whatever it's called, it will be under a directory called something like "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files".
• Step 4: "JITed" is shorthand for "just-in-time compiled." In .NET, methods from your assemblies are compiled into native binary code when they are called. In ASP.NET, this happens when pages are requested by the web browser--at runtime, and thus, just in time before serving the response. Contrast this with COM components, which must be compiled to binary code ahead of time, before they can be called.
• Step 4: This is just a one-time performance hit, and even so, it shouldn't be of concern. In Scott Guthrie's words: "Note that in practice, the cost of dynamic JITing the first access of a page's code is minimal. Because most of the overall page code path actually lives within [.NET] Framework libraries (for example: the code within the page base class, the code within System.Data, System.XML, etc.), the number of instructions generated from your actual code are pretty minimal. Because we can dynamically JIT millions of instructions to native code per second, this one-time cost ends up being noise in the grand scheme of things."

[via aspalliance/Peter]

AUG 28, Software Freedom Day

Software Freedom Day, a new concept developed by the grassroots groups to promote wider use of Free and Open Source Software (FOSS) falls on Saturday, August 28.

The LinuxInsider News reported that the groups are making all efforts to make the day a memorable one in Asia, one of the largest regions where IT is booming as a producer and consumer. The countries which will have software giveaways are Bangladesh, India, Malaysia and Vietnam, among other countries.

The event organised by smaller groups will be publicised by some heavy hitters like the International Open Source Network (IOSN), the United Nations Development Program and the Asia-Pacific Development Information Program.

In New York City, events are being organized by the group NY Linux Scene, which plans to rent space in Brooklyn churches and put on presentations on OpenOffice, K3p and Evolution.

Read more here http://economictimes.indiatimes.com/articleshow/msid-829609,curpg-1.cms

Microsoft DevDays 2004 Contents Online!

Now you can access recordings of the Microsoft DevDays 2004 sessions. Microsoft DevDays 2004 is mainly based on best practices for Web development, smart client development, and writing secure code.

Java Virtual Machine (JVM) for .NET

TIP:: Int32.Parse

Eg: int32.Parse("F", Globalization.NumberStyles.AllowHexSpecifier)

For more information -> http://support.microsoft.com/default.aspx?scid=kb;EN-US;835454

SQL Server 2005 (YUKON): Finer Points

A Beta testers review Yukon's finer points:

Several changes that Microsoft made to the SQL Server architecture have made the DBMS more robust, Don Watters (a senior database administrator with the Walt Disney Internet Group) said. Data transformation services (DTS) boost extract, transform and load (ETL) capabilities in SQL Server, making ETL much easier to use.

HOW TO: Retrieve information of Stored Procedure in SQL Server

I was trying to list down the list of  information about the Stored Procedure like parameters and their type etc. I found the following solutions to achieve that:

To get the list of user stored procedures, use the following query:

Select * from sysobjects where sysobjects.xtype='P' and sysobjects.category = '0' order by name

for xtype:Object type. Can be one of these object types:

C = CHECK constraint
D = Default or DEFAULT constraint
F = FOREIGN KEY constraint
L = Log
FN = Scalar function
IF = Inlined table-function
P = Stored procedure
PK = PRIMARY KEY constraint (type is K)
RF = Replication filter stored procedure
S = System table
TF = Table function
TR = Trigger
U = User table
UQ = UNIQUE constraint (type is K)
V = View
X = Extended stored procedure

To retrieve the information of a stored procedures, the following query can be used:

SELECT     TOP 100 PERCENT dbo.sysobjects.id, dbo.sysobjects.xtype, dbo.sysobjects.name, dbo.sysobjects.uid, dbo.sysobjects.category, dbo.syscolumns.name AS ColName, dbo.systypes.name AS ColType, dbo.syscomments.text AS Command
FROM         dbo.sysobjects INNER JOIN
                dbo.syscolumns ON dbo.sysobjects.id = dbo.syscolumns.id INNER JOIN
                dbo.syscomments ON dbo.sysobjects.id = dbo.syscomments.id INNER JOIN
                dbo.systypes ON dbo.syscolumns.xtype = dbo.systypes.xtype
WHERE      (dbo.sysobjects.category = 0) AND (dbo.sysobjects.xtype = 'P')
ORDER BY dbo.sysobjects.name, dbo.syscolumns.name

The best way to retrieve information of Stored Procedure and their parameters is to use a mix of sysObjects and OpenSchema:

SELECT Name FROM SysObjects WHERE xtype = 'P' AND Category = 0 ORDER BY Name

            Set rstInfo = New ADODB.Recordset
            rstInfo.Open strSQL, pconConnection, adOpenStatic, adLockReadOnly
            Do Until rstInfo.EOF
                strSPName = rstInfo.Fields("Name").Value
                Set rstParam = pconConnection.OpenSchema(adSchemaProcedureParameters, Array(Empty, Empty, strSPName, Empty))
                Do Until rstParam.EOF
                    strParamName = rstParam.Fields("PARAMETER_NAME").Value
                    strParamName = Replace(strParamName, "@", "")

.........

continue to get the further details of the SP.

For more information about OpenSchema method of ADO Connection object visit:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;309488

Datasets in .NET Framework

In .NET Framework, there are two basic ways to use the DataSet objects: untyped and typed. When using untyped datasets, you use the base BCL-provided DataSet objects and pass the relevant information that specifies which table, column, row, and so on that you're working with. The main drawback to untyped datasets is that the code is not type-safe. In other words, mistakes made in your code, such as misspelling the column name or passing an incompatible data type, will only be realized at runtime.

Typed datasets, on the other hand, are classes that are generated from a specified data store. It's important to realize that these classes are still directly derived from the ADO.NET base classes. However, they contain members specific to the data store schema and, as such, allow for compile-time error checking. The main benefits to typed datasets are better readability and compile-time type checking—as each column is a class member that is associated with its correct type within the class.

The following explains you the detailed advantages of Typed Datasets against UnTyped Datasets:

Advantages of typed datasets:

Compile-time type checking— Reduces runtime errors by having members based on the data's actual schema as opposed to untyped datasets, where you call a generic function and can pass an object of any type.

Schema-specific members— Typed datasets define properties for getting and setting values where the property name is the same as the underlying column name. They also define properties for determining if the column is null and methods for searching the table via primary key(s).

Data binding support in VS.NET— Only useful with Windows Forms applications, but bears mentioning if you plan on doing development based entirely on .NET in addition to the mixed-mode programming that is the focus of this book.

Intellisense support— When using untyped datasets, you have to know beforehand the names of the columns and the types that the respective columns work with. With typed datasets, as soon as you enter the name of the type, Intellisense displays its members, thereby saving you development and debugging time.

Disadvantages of typed datasets:

Versioning— Typed datasets can actually increase development time in situations where your schema changes, because you'll need to update the typed dataset information manually. This is obviously the same problem we've battled for years with CRecordset classes—having to modify them manually when the underlying schema changes.

Tightly coupled— In its current design, typed datasets are difficult to extend and can't be modified (as they're auto-generated each time the project is built). In addition, they force a tight coupling of client to data access code, which might not be best for all situations.

Advantages of UnTyped Datasets over Typed Datasets:

Untyped datasets allow you to see more easily what is really going on in code snippets as the client code explicitly states table and column names, store-procedure parameter names, and so on, as opposed to the actual database entity names being hidden in a class.

Untyped datasets allow for shorter, more focused code snippets and demos. Otherwise, each demo would require extra steps to create the typed datasets and then would require a lot of cross referencing between the main code and the typed DataSet class code.

For more information visit http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbcondatasets.asp

Indian Bloggers:Happy Independence Day

My hearty Independence Day wishes to all my fellow INDIAN Bloggers...

We are celebrating the 58th Independence in our Nation. I am very much proud that our country has developed in all aspects especially in Information Technology after the Independence.

JAI HIND!

Resolving file upload problem in ASP.NET

I recently had problems with file uploads in ASP.NET. While uploading large files, the browser simply displays the "Page not found" error page, but it worked for smaller files. I found the solution to resolve this problem in this article: http://www.microsoft.com/resources/documentation/iis/6/all/proddocs/en-us/qss_wss_troubleshooting.mspx

The problem explanation can be found by searching for "413" on the page. Or scroll down to the heading:

Client Cannot Negotiate Request and Returns an HTTP 413 Error

In short, the following steps must be done in order to upload files (or total posted data size) > 4MB,
1) Type in command line: cscript adsutil.vbs set w3svc/1/uploadreadaheadsize <N>  where N is the max. upload size in KB.
2) Change the MaxRequestLength setting to greater than or equal to the above value (N) in machine.config file.