Wednesday, July 30, 2003

.NET Bugs Registry 

.NET Bugs Registry

Tuesday, July 29, 2003

Office 2K3 Style - Blog 

Got FoO - Office 2K3 Style

Thursday, July 24, 2003

Using Jump Statements in C#

The goto, break, and continue statements are known as jump statements. You use them to transfer control from one point in the program to another, at any time. In this section, you will learn how to use jump statements in C# programs.

The goto Statement

The goto statement is the most primitive C# jump statement. It transfers control to a labeled statement. The label must exist and must be in the scope of the goto statement. More than one goto statement can transfer control to the same label.

if (number % 2 == 0)
   goto Even;
   goto End;


The goto statement can transfer control out of a block, but it can never transfer control into a block. The purpose of this restriction is to avoid the possibility of jumping past an initialization. The same rule exists in C++ and other languages as well.

The goto statement and the targeted label statement can be very far apart in the code. This distance can easily obscure the control-flow logic and is the reason that most programming guidelines recommend that you do not use goto statements.

Note: The only situations in which goto statements are recommended are in switch statements or to transfer control to the outside of a nested loop.

The break and continue Statements

A break statement exits the nearest enclosing switch, while, do, for, or foreach statement. A continue statement starts a new iteration of the nearest enclosing while, do, for, or foreach statement.

The following code writes out the values zero through nine.

int i = 0;
while (true)
   if (i < 10)

The break and continue statements are not very different from a goto statement, whose use can easily obscure control-flow logic. For example, you can rewrite the while statement in the preceding example without using break or continue as follows:

int i = 0;
while (i < 10)

Preferably, you can rewrite the previous code by using a for statement, as follows:

for (int i = 0; i < 10; i++) {


Tuesday, July 22, 2003

Window/Msn Messenger Polygamy 

Msn/Window Messenger Polygamy allows you to run more than one copy of MSN messenger, as well as many accounts simultaneously. To use the program, install it, and then run it from the Programs menu - each time you run it, a new copy of MSN will be launched.

Window/Msn Messenger Polygamy

Friday, July 18, 2003


MyIE2 is the most powerful and fully customized browser. It can open multiple web pages in just one window, and come with tons of other nice features.
MyIE2 Online

Thursday, July 17, 2003

Hashes and Signing 

Hashes and Signing

Hashing is used to create a unique, compact value for a plaintext message. "Message" is a very broad term here; in terms of assemblies, the message is the assembly itself. The message is used as an input to the hash algorithm (in the case of strong naming, the SHA1 algorithm is used).

File.dll---->SHA1 Hash Algoritm---->Hash Value(SDFSDFJG2345ASDHFAS23)

Hashing is a one-way street: you can't decrypt the hash value once it has been computed. However, hashing is very useful for comparing values. If two assemblies produce the same hash value, you can assume that the assemblies are the same. Conversely, if hashing an assembly produces a value that doesn't match a previously-calculated hash, you know that something in the assembly has been changed.

Knowing the hash value for an assembly lets you check that no one has tampered with the assembly. But how do you prevent someone from tampering with the hash value? That's where digital signing comes in. While the mathematics of digital signatures are complex, the concept is fairly simple. A digital signature depends on a pair of related numbers, the public key and the private key. When data is encrypted with the public key, it can only be decrypted with the private key (and vice versa)

Strong Naming for Assembly IdentityThe combination of hashing and digital signing allows .NET to protect your assemblies from tampering. Here's how it works. First, a hash value is created from the assembly. Then, the hash value is encrypted with your private key and placed, along with your public key, in the assembly itself.

My.dll--->SHA1--->Assembly Hash--->Public Key--->My.dll+Digital Signature.

The CLR validates assemblies at runtime by comparing two sets of hash values. First, the public key is used to decrypt the encoded version of the hash. Second, a new hash is computed from the current contents of the assembly. If the two hashes match, all is well.

My.dll--->SHA1--->New Hash
My.dll+Digital Signature--->Public Key--->Original Hash

What happens if an assembly has been tampered with after it was signed? In this case, the new hash value calculated at runtime won't match the stored hash value that was encrypted with your private key. Under those circumstances, the CLR will refuse to load the assembly.

Note that the strong name guarantees the integrity of the assembly, not necessarily its safety! There's nothing to prevent someone from creating a malicious assembly and signing it with a strong name. You can use a strong name to verify that an assembly came from a particular source, and that it wasn't tampered with after it was signed. It's up to you to decide, based on whatever information you choose, whether to trust code from that source.

What's in a (Strong) Name?
In addition to a hash derived from the assembly's contents, the strong name includes three other pieces of information:

The simple text name of the assembly

The version number of the assembly

The culture code (if any) of the assembly

All of this information works together to supply a unique identity for each assembly. The CLR uses this information when deciding whether a particular assembly is the one called for by a reference from another assembly. When you set a reference from one assembly to another, the calling assembly stores a representation of the called assembly's public key. At runtime, the CLR can use this to check that the referenced assembly comes from the correct vendor.

O'Reilly Network: The Secrets of Strong Naming [Apr. 28, 2003]

Monday, July 07, 2003

Windows XP styling for yr Windows Forms 

Windows XP Styles in yr Application

Prologue: Comctl32.dll, version 6. Comctl32.dll, or the Common Controls, have been around for a very long time. This library provided basic common controls while User32.dll provided user controls. In version 6 of the Common Controls, all of the controls were put in Comctl32.dll so that all the controls could support theming. Comctl32.dll, version 6, is not redistributable, however, unlike previous versions of Comctl32.dll. In order to use the new Windows XP Visual Styles, you must be using an operating system that contains Comctl32.dll, such as Windows XP.

For supported controls, the control style is associated with a particular theme resource that is drawn in the client area of the control. For controls deriving from ButtonBase, GroupBox, and Label, these controls must use the FlatStyle.System enumeration member in their FlatStyle property so that they allow the operating system to draw the controls.

In order to tell Windows to use theming for your controls, you need to tell Windows to bind to Comctl32.dll, version 6. By default, Windows binds to Comctl32.dll, version 5. Similar to the binding policies of .NET, however, we can tell executables at runtime to bind to other assemblies, or Win32 libraries in this case.

So, add a new XML file to your project and call it .exe.manifest, where is the name of the output file your project generates, which is your project name by default. Set the Compile Type to "None", since we'll only including this in your project for simplicity.

If you used the "AssemblyInfo.cs" code above, your newly created .exe.manifest should look like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
         name="Theme Test" type="win32" />
   <description>Windows XP Styles.</description>
                  language="*" />

You should replace the first "version" and "name" attributes with appropriate values for your project, which are the AssemblyVersion and AssemblyTitle attributes respectively. The "description" element should also match your AssemblyDescription attribute.

Next, open a command prompt and change directories to your project output directory, which should be "bin\Debug" with your project directory as the root. Assuming that you have "sn.exe" in your PATH (part of the .NET Framework SDK), type the following:

sn.exe -k ..\..\KeyFile.snk

This should put a public key file named KeyFile.snk - which we referred to earlier in our AssemblyInfo.cs file - in your project directory. This public key is necessary to sign your assembly with a strong name, which is required in many situations and is recommend for every assembly.

Adding the Manifest and the Final Touches

1. You should now be in the same directory as your project output file. In my example, my application is simply "WindowsApplication1.exe", which I'll refer to later.

2. Now, back in Visual Studio .NET, click on the File->Open... menu, browse to your application such as "WindowsAppication1.exe", and click open. You should now see your resources in a tree view.

3. Right-click on the root node ("WindowsApplication.exe") and select "Add Resource...".

4. Click "Import...", browse for "WindowsApplication.exe.manifest" in your project directory, and click "Open".

5. In the "Resource Type" text box, type RT_MANIFEST and click "OK".
6. Save all files and go back to your resource view you were previously in. You should now see a folder named "RT_MANIFEST".

7. Click on the newly added RT_MANIFEST resource, probably named 101. Change its ID to 1 in the property grid and save your application again.

After closing the resource view in which your application was open, go back to the command prompt and type the following:

sn -R WindowsApplication1.exe ..\..\KeyFile.snk

The tool should print some version info and then display:

Assembly 'WindowsApplication1.exe' successfully re-signed

Run your application and see Windows XP Visual Styles at work in your .NET application!


Windows XP Visual Styles can be a very good addition to your applications and control libraries and they don't take a lot of work. Supporting this new visual style will give your application a common look-and-feel with Windows, which is always a definite plus in commercial applications. Many companies strive to keep up with Windows standards and now you can do it without a lot of work.

Just remember to set the FlatStyle property of any applicable control to FlatStyle.System and to embed the manifest resource like the boilerplate above in your executable after compiling. After having done all that, you need only finish signing your assembly, otherwise it won't pass validation if you specified an AssemblyKeyFile. If you need to test your application or have an authority sign it, you can turn off validation for that assembly by typing the following:

sn.exe -Vr WindowsApplication1.exe


Windows XP Visual Styles for Windows Forms


.NET Ideas

Software Artichitech 

http://www.modelingstyle.info for UML Diagram Tips & Guidelines
http://www.bredemeyer.com for Architecture
http://www.softwarearchitect.biz for Architetcure

My first Blog 

Today I started Blogginggggggggg!!!!!!!
And will never forgive (hey,its not forget :)) Sudhakar for introducing me to this blog.

This page is powered by Blogger. Isn't yours?