Sreedhar Koganti's Blog

Binary format made DataSet become more intelligent in ADO.NET 2.0

Even though we all like DataSet; as Serialization of DataSet is more expensive in ASP.NET 1.x, most of us had put lot of thought before using it!

From ADO.NET 2.0 on, we don’t need to worry that much! MS put lot off effort on improving performance on Serialization in DataSet.

In ADO.NET 1.x, the Serialization of DataSet happens in XML format. Even in ADO.NET 2.0 by default it happens in XML format. But there is an option to change the Serialization format to Binary using the property called RemotingFormat (of SerializationFormat.Binary). The Binary format improves performance a lot!

A Simple Example on How to:

DataSet DS = (DataSet)DataGridView1.DataBind;        System.Runtime.Serialization.Formatters.Binary.BinaryFormatter Frmt = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();

        using (FileStream fs = new FileStream("c:\\SampleOne.bin", FileMode.CreateNew))

        {

            DS.RemotingFormat = SerializationFormat.Binary;

            // Other wise you can go for SerilaizationFormat.XML

            Frmt.Serialize(fs, DS);

        }

Hope it helps you!

Meet your new friend ClientScript in ASP.NET 2.0

In ASP.NET 1.X for rendering client side script to client browser we took help of Page.RegisterClientScriptBlock or Page.RegisterStartupScript methods! But these methods are obsolete in ASP.NET 2.0 (As always Microsoft facilitates backward compatibility in its products, we can still use these, but these are not recommended to use)

In 2.0, we can take help of Page.ClientScript to render client side script to client browser.

Page.ClientScript property is wraps an instance of the ClientScriptManager type. This ClientScriptManager helps managing scripts.

That’s not it; there is more to know about this guy (ClientScript). Very interesting internals are there behind introducing this new ClientScript feature in ASP.NET 2.0.

If you just met ClientScript, start exploring it : )

Dear developer don’t trust VWD Web Server (of VS.Net 2005)

As we know ASP.NET applications runs under (using) ASPNET special user account, which has restricted privileges for security reasons.

But when you are making/developing ASP.NET applications using VS.Net 2005, it’s going to use built-in VWD Web server while testing the pages. This VWD Web server is going to run under NETWORK SERVICE user account while running/testing the pages. Interestingly this is going to use logged in user account privileges. In other words if you logged in as an Administrator, then VWD Web server is going to use administrative privileges for NETWORK SERVICE user account to run the pages.

So if you are making any application which needs special privileges, while testing using VWD Web server, it works fine (as it runs using administrative privileges in this case), but when you move your application to IIS, then the pages which needs special privileges many **not work** as the pages running under IIS runs using ASPNET account with restricted privileges!

Moral of the story: When moving application from VWD Web server environment (VS2005) to IIS, please make sure and give necessary permissions to the application it needs.

Quote: My dear developer don’t trust VWD Web server  :-)

[Just to feed permissions issue to your permanent part of the brain, I have stated as don't trust VWD Web server, but really VWD Web server is very flexible and useful local server for developers]

Is really I can use Multiple Programming Language in Code Folder (In 2.0)?

The Code folder is not explicitly marked as containing files written in any one programming language. Instead, the ASP.NET infers which compiler to invoke for the Code folder based on the files it contains. If the Code folder contains .vb files, ASP.NET uses the Visual Basic compiler; if it contains .cs files, ASP.NET uses the C# compiler, and so on.

If the Code folder contains only files where the programming language is ambiguous, such as a .wsdl file, ASP.NET uses the default compiler for Web sites.

Multiple Programming Languages in the Code Folder:

Because the source code in the Code folder is compiled into a single assembly, all the files in the Code folder must be in the same programming language. For example, the Code folder cannot include source code in both Visual Basic .NET and C#.

However, you can configure your Web site to treat subfolders of the Code folder as separate compilable units. Each folder can then contain source code in a different programming language. The configuration is specified by creating a <codeSubDirectories> element in the <compilation> element of the Web.config file and adding a reference to the subfolder. The following example illustrates how you would configure the subfolders named VBCode, CSCode as a separate compilable unit: (VBCode, CSCode are sub folders under Code folder)

<compilation debug="false">

         <codeSubDirectories>

               <add directoryName="VBCode" />

               <add directoryName="CSCode" />

         </codeSubDirectories>

</compilation>

Note that the reference to the VBCode or CSCode subfolders does not include any information about what programming language is contained in the subfolder. As with the Code folder itself, ASP.NET infers the compiler to use based on the files in the subfolder. As Name resolution sake I had given names as VBCode and CSCode, but really you can have code what ever the language you want!

 For Begginers on Code Folder feature, Andrew Article helps you

Visual Basic 2005 introduces new compiler checking options

Visual Basic 2005 introduces new compiler checking options. The /nowarn and /warnaserror options provide more control over how warnings are handled. Each one of these compiler options now takes a list of warning IDs as an optional parameter, to specify to which warnings the option applies.

• CLS Compliance Checking

Visual Basic now generates a warning for each line of code that contains any specification or operation that the Common Language Specification (CLS) does not support.

• Uninitialized Variable Checking

Visual Basic now generates a warning for each potentially uninitialized variable. A variable has this status if there is at least one possible execution path that does not assign any value to the variable before using it.

[

On record.... I planned to post 2.0 changes from today...!

As Beta is out and I felt it's more stable now... after testing various modules....

]