Tuesday, January 25, 2005

(Via Sean Hull)

When it comes to Web development these days, you have a lot of options. Many of these methods involve preprocessing—that is, embedding code into HTML pages with special tags that signal to a preprocessor that they contain code, and that it should do something with it. Much like a CGI, this code is then run on the server, and it returns some content, which then assumes part of the shape of the resulting HTML page sent back to the browser. Both the open source scripting language PHP and languages within Microsoft's ASP.NET framework fall into this category; JavaServer Pages (JSP) and Perl/Mason operate this way as well. More

Sean Hull is the senior consultant at his firm, iHeavy Inc., in New York City. He focuses on integrating open source technologies with commercial technologies such as Oracle, and has serviced many successful New York companies.

posted on Tuesday, January 25, 2005 10:07:00 AM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
 Sunday, December 12, 2004

Via John Mueller.

Configuration—the act of modifying the settings for an assembly—is becoming an essential part of .NET development. The .NET Framework 1.1 Configuration Utility provides a means of configuring the assemblies on your system in different ways.

This article explains why assemblies require configuration, shows how to use the .NET Framework 1.1 Configuration Utility to perform the task, and explores an alternative you can try in some cases. More...

posted on Sunday, December 12, 2004 1:17:00 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
 Tuesday, December 07, 2004

I received an article from a friend few days back, which provides evidence of Microsoft platform usage in Enterprise mission critical applications.  IT provides some interesting facts. Though I can't post the full article here, gist of the same is below..

Main points

  • Gartner Custom Research conducted the study, which is random sample and projectable across lorgs in US
  • While this does not represent the opinion of Gartner Analysts, MS worked extensively with the analysts to create the survey and validate the methodology.
  • MS have also done extensive reviews of the data with Gartner analysts, who have largely maintained J2EE + Unix dominates in the mission-critical apps space ("enterprise apps").  This data shows otherwise. 
  • Since the focus of this survey is mission-critical LOB applications, this study (at request of Gartner analysts), excludes email, meaning it does not include Windows Servers running Exchange.  

The Highlights  ( all questions are for Mission Critical Apps within lorgs US Only):

  • Server OS Usage (multi select) - Windows leads with 65%. Commercial Unixes combined add up to 58%
  • Server OS Share (single select - primary mission critical OS) - Windows leads with 36.5%. Commercial Unixes combined add up to 35.3% .
  • Application Platform Usage (multi select) - Microsoft (.net & other) leads with 41%. J2EE is right behind with 40%.
  • Application Platform Share (single select - primary mission critical platform) - Microsoft leads with 25%. J2EE follows with 22%.
  • Mission Critical Vendors - Microsoft leads with 25%, with IBM close behind at 24%.
  • Web Services Usage & Vendor - 44% of Enterprises are doing WS, Microsoft is the clear vendor leader with 45% share, followed by IBM at 20%.
  • SOA Usage & Vendor - 31% of Enterprises are doing SOA, Microsoft is the clear vendor leader with 39% share, followed by IBM at 19%.

       Interesting huh!!!

posted on Tuesday, December 07, 2004 1:48:00 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
 Monday, November 22, 2004

Today, somebody asked me about the difference between constant and readonly type declarations and about when to use which one. Here is the interesting detailed comparison with three different examples…

a) private const int EXAMPLE1 = 450;
b) private static readonly DateTime EXAPMLE2 = DateTime.Now
c) private readonly DateTime EXAMPLE3 = DateTime.Now;

 

The Difference:

First one creates a compile-time constant,
Second creates a run-time class constant,
Third creates a run-time object constant.

1) Compile-time Constants

Symbols defined as const (EXAMPLE1 in this case) are replaced with the value of the constant at COMPILE TIME. Therefore statement if (ValueInConst == EXAMPLE1) would get converted to the same MSIL as if (ValueInConst == 450). The compiler replaces the symbol with the value of the constant. This is the main point to compile-time constants.  Compile-time constants can only be used effectively for built-in integral and floating-point types (primitive types), enums, or strings. These are the only types that allow you to assign meaningful constant values as part of the initialization process.  The IL generated for a compile-time constant contains the value, not the symbol. The value is "burned in" at compile time.

2) Readonly Values

Readonly values are those constants which cannot be modified after the constructor has executed. Readonly values are different, however, in that they're set at run time. You have much more flexibility in working with run time constants. Run-Time constants can be of any type; as long as you can assign them in your constructors, they will work. I could not create DateTime values with const but I can make readonly values from DateTime structures.

Secondly, readonly values can be used for instance constants, storing different values for each instance of the class type. The main distinction is that readonly values are resolved at run time. The Intermediate Language generated when you reference a readonly constant reference the readonly variable, not the value.

Which one to use?

The main difference between const and readonly fields is in their flexibility. Suppose you've defined both const and readonly fields like below:

public class SomeValues
{
   public static readonly constOne = 2;
   public const constTwo = 5;
}

Then, in an application these values are referenced and displayed using likely sum statement.

Console.WriteLine("Sum is {0}",SomeValues.constOne + SomeValues.constTwo);

If you run above snippet, Output will be “Sum is 7”.

After few days you release a new version of the assembly with the following changes:

public class SomeValues

   public static readonly constOne = 50;
   public const constTwo = 30; 
}

You distribute the assembly without rebuilding the application assembly. You'll get an absurd result as “Sum is 55” !!!!. The snippet now uses the value 50 as constOne, and 5 (OLD VALUE) as constTwo. The const value of cosntTwo (5) was placed into the application assembly by the compiler. On the other hand, constOne was declared as readonly, so it gets resolved at run time. Therefore, the application assembly uses the new value without recompiling the application assembly. Simply installing an updated version of the Infrastructure assembly is enough. Another advantage is that using readonly constants generates smaller sized assembly. Whenever you use a const value, compiler has to inserts the value of the constant. On the contrary, when you reference a readonly value compiler references that symbol not the value. On the flip side, readonly type doesn't work to initialize an attribute. The actual value of the object must be available at compile time for the attribute to get created correctly. Therefore, only values declared as const (or enums) can be used in this instance.

One major advantage constants provide over readonly is that it can be used in places where readonly values cannot be used (as in Attributes). You can use const values as the parameters to attribute constructors but you can’t use readonly values, or variables

There are some small performance gains using const instead of readonly but if you want to have little flexibility, readonly declaration has it for you. This flexibility overrides the small performance gains from using const. Everything except attribute parameters and enums should be declared readonly.

posted on Monday, November 22, 2004 6:42:00 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
 Saturday, November 20, 2004

Via Leo

I encountered a very informative post about ASP.Net page life cycle on an equally informative blog from Leo.

Any ASP.NET developer should know the inner workings of the ASP.NET engine. The Page control is its backbone. Knowing the control lifecycle in the page considerably helps in the day-to-day and advanced development projects. read more..

Of course there are lotsa websites having articles on the similar topic but this one takes the bet because of it's beautiful graphical representation (a picture speaks thousands words :-))

posted on Saturday, November 20, 2004 11:31:00 AM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
 Monday, October 25, 2004

Microsoft has reported a security issue which affects web content owners who are running any version of ASP.NET on Microsoft Windows 2000, Windows 2000 Server, Windows XP Professional, and Windows Server 2003...

A security flaw in Microsoft's ASP.NET technology could allow intruders to enter password-protected areas of a web site by altering a URL. A fix is not yet available, but Microsoft is offfering guidelines to help ASP.NET users secure their sites against intrusion attempts. The flaw exists only in ASP.NET, not ASP (Active Server Pages). Read More.

posted on Monday, October 25, 2004 4:58:00 AM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback

I got back on line today, though temporarily I'll be blogging from a friend's place.

Probably it will be few more days when I'll be able to get DSL at my home and start netting from there.

Cheers till then!!

posted on Monday, October 25, 2004 3:52:00 AM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
 Thursday, September 30, 2004

For quiet sometime, you'll not see any post from me (ohh.. you didn't see even in past ;-) ) as I'll be in transit next week..( On my move to Dallas..).

I'll reach there on Saturday 2nd Oct. I'll be on-line once I settle there with some good speed DSL connection.....

Cheers till then!!!!

posted on Thursday, September 30, 2004 1:38:00 AM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback
 Monday, September 20, 2004

Open Source .Net IDE #develop (SharpDevelop) has got even better.  Written entirely in standards-based C#, 

the #develop version, released September 10, sets a "solid foundation for the growth" of Open Source tools for .NET development projects,

Developers at #develop, have added project-level import for VS.NET and other features to their 1.0 version of their #develop (SharpDevelop) Open Source IDE for C#, VB.NET, Managed C++ and ILAsm projects built to run on Microsoft's .NET platform.

The focus of the Open Source #develop IDE project is "on making #develop portable to other CLRs and platforms" to allow #develop to run with native look and feel on Microsoft .NET / Windows, as well as Mono on Windows and Mono on Linux. Aside from standard code creation and debugging facilities, #develop also brings a full environment to the project, including Windows Forms, testing, auto-insertion capabilities for code and tweaks and even an XML preview feature.... read more...

An IDE can be downloaded here

posted on Monday, September 20, 2004 5:08:00 PM (Central Standard Time, UTC-06:00)  #    Comments [0] Trackback