Developer's Age at CodeProject Lounge

Have you ever asked yourself, " When will I stop development ? ", I am sure you've done at least once, especially when the job is getting tough, I have started this thread at CodeProject lounge, and I have found out that some developers aged 66 still work with .NET and have passion to learn .net 3.0, ain't this amazing, honestly I got surprised, I think development is a life time career now!, go to the lounge and share your viewpoint, and also read about people's experience, it's really interesting!

Developer's Age Lounge

Labels:

Microsft VHDs

Microsoft provides some of the products in VHD formats, so if you want to learn a new product or technology and want to get the installation off your shoulders; you should have a look at Microsoft VHD repository.

Microsoft VHDs

Labels:

GAC Nitty Gritty, Part 2

In the first post, we've gone through GAC, SNK, and how the CLR is loading the signed assemblies, in this post we'll examine the folder structure of the GAC, and see how the GAC is working behind the scenes, for more information please refer to the first part.

GAC Folder Structure

Global assembly cache is just a physical folder; just like any other folder, but when you browse to the default GAC location at : %WinDir%\assembly, the windows shell extension SHFusion.DLL shows you the customized GAC folder, the truth is that GAC is just a windows folder, if you hit your CTRL+R, and enter %WinDir%\assembly\gac , you will get the contents of the GAC folder, however browse one level up to %WinDir%\assembly, voila, now you can the folders under the GAC location, these are processed by SHFusion.DLL to show you the customized view of the GAC contents, now we'll examine the folder structure of the GAC



  • GAC : this folder contains .NET Framework 1.x assemblies.

  • GAC_32 : this folder contains assemblies to be run on 32bit operating systems, considering the operating system word size to be 32 bits.

  • GAC_64 : this folder contains assemblies to be run on 64bit operating systems, the word size is 64 bits, so the JIT compiler compiles these assemblies considering they will be running in 64bits environment, also note that if your OS is 32 bits so you will not have this folder in your GAC, but if your OS is 64 bits, so you will have both GAC_32 and GAC_64 folders, that is because Windows 64bit is able to running 32 bits applications through emulation or what's called WoW ( Windows on Windows ), for more information about WoW 32-bit emulator, please refer to this post.

  • GAC_MSIL : this folder contains assemblies that can run on either 32bit or 64bit platforms, they are compiled into MSIL, and in runtime, the JIT (Just In Time) Compiler, compiles them to the proper machine code ( with support for target word size ).

  • NativeImages_Vx_WordSize : whenever you compile your assemblies; they are compiled to MSIL code, and in runtime JIT compiler compiles the code to the machine language, this process is costly, so if you want to boost your application performance, you can use a .NET utility called NGen.exe, this utility compiles your MSIL assemblies to the machine language right away, saving you JIT compilation time, and this greatly boosts your application performance, taking into consideration that assemblies compiled using NGen are machine specific and not deployable, so first you have to deploy your assemblies, and then run NGen.exe on them, to generate the pre-compiled assemblies, so the native image of one assembly is the precompiled assembly, and they are saved in this folder, considering framework version ( Vx ), and word size 32bits or 64bits, ( WordSize ), so you will end up with more than one NativeImages folder according to your OS word size, and .NET framework versions you have installed, NGen is an interesting topic, to get more information about it, please refer to this MSDN column CLR Inside Out .

  • Temp folders : these are temporary folders.
Note that the Processor Architecture column in the GAC view, this reflects in which folder the assembly is saved.

So how .NET framework achieves versioning, let's take one example, if you open GAC_32 folder and then open Microsoft.SqlServer.Replication folder, you will find one folder named 9.0.242.0__89845dcd8080cc91, apparently this is the folder name is the assembly name ( without .DLL extension ) , and the sub folder follows this pattern AssemblyVersion__PublicKey, go one level down and open this folder you will find the assembly named Microsoft.SqlServer.Replication.dll


Select the file, and hit Alt+Enter ( for properties ), select Version tab, you will find the comments field under other version information -> Item Name, has the value "NT INTEL X86", this explains why the assembly is placed inside GAC_32.


Select Digital Signatures tab, select Microsoft Corporation from Signature List, have a look at Timestamp column, then click Details button, click the Advanced Tab


Voila, Digest algorithm is SHA1, Digest encryption algorithm is RSA, and the message digest is there as well, so let's recall what we've explained in last post, in runtime CLR has the public key and the assembly contents ( MSIL + metadata ), it uses the assembly contents to generate a hash value using SHA1 algorithm, then it decrypts the encrypted message digest to get the original hash value ( message digest ), then it compares the one it generated first, to the one that 's just decrypted, if they are equivalent so it loads the assembly ( or installs it in the GAC if the assembly is to be installed in the GAC ), otherwise the installation or loading of the assembly is discontinued.

Now, everything is clear and we know how CLR manages versioning, so for target="_blank" each and every assembly version you install in the GAC, one folder is created behind the scenes to hold this new assembly version.

GacUtil.exe

This post is not intended to teach you how to use the GacUtil.exe, however it is very simple to install and uninstall one assembly, for detailed information about the command line of Gacutil.exe please refer to MSDN, Global Assembly Cache Tool.

Tip: one of the differences between GAC in .NET 1.x and 2.0, is that when you use GacUtil /u AssemblyName.dll, it fails to uninstall the assembly, the right way to uninstall one assembly is to just pass the assembly name with no extension, and also it's worth mentioning that you can access the GAC through a set of APIs.

References and Related Readings
I hope I could make it clear, however if you have any comments, inquires, or you find any inconsistent information, please leave me a comment.

Labels:

GAC Nitty Gritty, Part 1

Intro

Global Assembly Cache, is one of the most important scapes of .NET framework, however there are so many tips and tricks, and guidelines that you should be aware of, unfortunately most of developers when asked about GAC, they barely would tell what it stands for, GAC is a major scape of .NET architecture, and I believe that understanding what .NET is so important as I have seen so many people around arguing about .NET inner workings and how insignificant to know, I believe that if you know how .NET is doing the magic for you, this would help you so much, everyone can write code, but how many people know the architecture of .NET, not so many people, however in this post I will try to deliver my knowledge and my experience with GAC, I have read so many articles, blog posts, forums discussions, and MSDN documentation, and at the end of this post I will mentioned related readings so you can follow and get more knowledge about GAC.

GAC, Why ?

"GAC is built specifically to be a machine-wide repository for system and custom assemblies, with support for versioning", this is the ultimate objective for GAC, one location for global assemblies, so each and every .NET assembly can access the global assemblies stored in the GAC, plus you can have versioned assembly inside the GAC, and this is how .NET solved the DLL Hell classical problem , so inside the GAC you can have more than one assembly with the same name but with different versions, and in the next lines we will explain throughly how .NET achieves versioning for GAC assemblies, so to recap; GAC is a repository in which we keep global versioned assemblies!, one more thing is worth mentioning is that default machine polity grants "full trust" to all assemblies installed into the GAC, and this is a very cool feature I remember that I developed a custom ASP.NET 2.0 WebPart that I wanted to use at Sharepoint Server 2007, when I was adding the WebPart assembly in the default web application bin folder, I had to write policy file to grant my assembly permission to be used from inside MOSS 2007, whilst instaling the assembly into the GAC, it just works and you don't care about any code access security for your assembly.

GAC, How ?

To get your assembly installed into the GAC, you have to digitally sign it by generating a strong name key by launching Visual Studio 2005 Command Prompt, enter "sn -k filename.snk", this writes the file into the current location from which you are running the command, and if you build a class library project from VS.NET you can right click the project from solution explorer and click Properties, select Signing, check the Sign the assembly, from the dropdown list you can select either to create a new strong name key through VS.NET or browse to the one you've created before using the VS 2005 command prompt.

SNK, Why and How ?

You might wonder about the need for generating the strong name key file and assigning it to the assembly whilst building it, at the first place any assembly to be placed into the GAC, it has to be built with snk file, but note that it's always good to sign your assemblies regardless of being installed into the GAC, so even if you don't intend to install your assembly into the GAC; you can still sign it using a strong name key, snk gives a unique indentity to your assembly just like the GUID was a unique identifier for COM objects, also when you digitally sign your assemblies using strong name key is preventing spoofing or tampering your assemblies, that may be hacked by any malicious source, for example if you have BizTalk Server 2006 installed on your machine, check your GAC at %windir%\assembly, you will find out that almost all BizTalk Server assemblies hold public key token ( more about this later ), as 31bf3856ad364e35, this tells the .NET CLR of your machine that these assemblies are coming from the source they are coming from ( I know it's somehow difficult to grasp ), now we'll examine the contents of one digitally signed assembly strong name; the strong name of one assembly consists of the following :

  • Public Key Token: also know as the public key ( example: 31bf3856ad364e35 ).
  • Assembly Name: it's the assembly name after suppressing ".dll", ( example: Microsoft.BizTalk.Messaging).
  • Assembly version: standard pattern is, Major.Minor.Build.Revision, ( example: 3.0.1.0 ).
  • Culture : culture identity value, ( example : Neutral ).
  • Digital Signature: this is hash value, more about that later, encrypted using the private key.
The process of the signing and verification can be depicted using the following process diagram:



Compilation Time
  1. When you create snk file using the SNK.exe, the public and private keys are written into the file, and one more thing to notice, that you can protect your snk file using a password.
  2. After binding your assembly with the strong name key, and when you compile your assembly, the compiler generates a "Hash Value", using the assembly IL code and meta data as an input and the algorithm used for hashing is SHA-1 Hash algorithm.
  3. Compiler reads the private key from the snk file, and takes the hash value generated in step 2 as an input for encryption, compiler uses RSA Public Key Algorithm to generate the digital signature that will be shipped with the assembly, while the private key is never included in the assembly metadata, it is always kept in a secure place.

Run Time

  1. Whenever the CLR loads an assembly that's digitally signed, regardless of being in the GAC or not, CLR reads the digital signature and tries to verify it, then it compares the digital signature included in the assembly, to the one that it evaluates at runtime if they are equivalent the CLR continues loading the assembly, otherwise the assembly is not loaded, first step CLR carries out is to generate a hash value from assembly contents, IL + metadata, this is done using the same hashing algorithm used by the compiler it's SHA-1.
  2. CLR decrypts original hash using the public token/key and same encryption algorithm used before, RSA Public Key algorithm, remember the digital signature is just an encrypted hash value using the private key.
  3. CL compares original hash value ( from step 2 ) and current hash value ( from step 1 ), if they are the same, CLR loads the assembly, otherwise it's not loading the assembly, and if the hash values are not equal, that means the assembly contents have been changed or they are not signed using the correct snk, that's coming from specific publisher/source.
Note that the assembly that is strongly named undergoes the runtime CLR signature verification every time it is getting called by another assembly , on the other hands this process is done only once for GAC assemblies while installing the assembly into the GAC, and then the CLR doesn't check it every time it's getting called, considering it's coming from a trusted source, because you wouldn't install an assembly into the GAC if you don't have administrative rights on the target machine.

Inside GAC

GAC is located at %windir%\assembly if you try to browse to this location, windows shell extension will load and show the contents of the GAC, the shell is named SHFusion.dll, and it's worth mentioning that the first codename for GAC versioning was Fusion, however after you browse to the GAC location you get the assemblies listed as shown below:


I will stop at this point and the next post I will go deeper into the GAC, and explain how the .NET framework is achieving the versioning behind the scenes.

Disclaimer: In part 2, I will gather and mention references and related readings.

Labels:

First Gulf MSDN Newsletter

First gulf MSDN newsletter has been released, you can subscribe for free and get all the region's events, technical resources, news, blogs, webcasts, and last but not least presentations, it's very nice to have a regional newsletter, it's a very good step on the road of making the community of developers in the gulf more lively and active, and thanks for the efforts that the Gulf team is doing to build better Microsoft community!

Labels:

Microsoft XML Paper Specification


XPS is the new Microsoft format that competes PDF, I am sure you've heard about it before, however XPS is the Microsoft standard for electronic documents, if you install Office 2007 you can save any office application document as XPS ( you need to install one Office 2007 Add-in to get this option, you can get it from here ), by hitting the main menu button and then select 'Save As -> PDF or XPS', select XPS and then if you double click the document from Windows explorer you will get it opened inside the IE, also if you install the XPS pack, that includes XPS generator and viewer from Microsoft site, here, you can save any file from any application as XPS, for example if you want to save a Notepad document as XPS you can select 'Print' and then you select 'Microsoft XPS Document Writer' printer, and this gets me back to the pdf995 third party application that used to install a printer driver and from any windows application you can save your file into PDF, this printer driver is installed with Vista by default, as Windows Vista is 100 % compatible with XPS standard, also XPS has a SDK, you can manage the document using its object model that's coming with .NET 3.0, and I am sure that you want to pose the question that comes to mind, what is the difference between XPS and PDF, from my perspective Microsoft released this standard to compete with PDF, nevertheless Office 2007 has built-in support for PDF standard, in a nutshell XPS is based on OpenXML standard, which implies that the XPS is no more than an OpenXML compliant package; that holds so many XML files, in turn this means that you can edit the document contents in a text editor such as Notepad, ain't that cool !, however if you are eager to get a complete sheet that compares both standards you can check this blog post http://www.amyuni.com/blog/?p=8 , and soon one white paper will be released that addresses all the pros and cons of each, but I think Microsoft will give a great support for XPS in the next generation of her products; for me as an OpenXML fan; I think XPS is more manageable for developers!, to get started with XPS you can visit the official Microsoft XPS site at : http://www.microsoft.com/whdc/xps/default.mspx, and it's worth mentioning that the XPS is coming by default with the .NET Framework 3.0, so if you have it installed no need to get the XPS pack.

Note: I have saved one bulky word file as XPS, then I opened it in IE, loading was so fast, and also I found no margins or formatting issues, also search was so performant, navigating from one page to another was unexpectedly fast, one more thing else to add; Microsoft is providing most of documents on her site as XPS by providing a link about what XPS is, downloading the generator and viewer, go and get it , use it , I am sure you will like it!.

Labels:

.NET Reference and Value Types

Today's post sounds very basic, maybe you guess so, but I have seen so many developers around misuse these terms, so let's ask the classical question: "what is the difference between passing parameters to a method by value and by reference?", the answer that you may get from most developers is : if you pass a parameter by value the value of this parameter will not change after calling the function/method, though it gets changed inside the function implementation, the reason behind that whenever you pass a parameter by value the parameter's contents get copied into the method, and upon return of the method the calling code will be having the same value it had before calling the method, regardless of the inner implementation of the method, on the other hand whenever you pass the parameter by reference if the parameter gets changed inside the method implementation, and when the method returns the parameter's passed value will get affected depending on the method's implementation, so this is the answer you would get when you ask this question, but I have seen so many people just answer the question without being aware of the inner workings of ByVal and ByRef, so I decided to post this post to clear out the confusion by giving practical examples.

Value types are saved in an area in the memory called "Stack" where it's very efficient to update, read, delete the values quickly, on the other hand the reference types' references or "pointers" are saved in the "Stack", but the contents of these reference types are saved in the "Heap", basically all processing on the reference types are done on the pointers or references of the reference types not the values, and it's worth mentioning that Garbage Collector works on the Heap by removing, periodically, items that have no references, however GC works behind the scenes by removing these unusable data, but if you want to force GC to clean unusable memory you can call GC.Collect, let's examine this example to see all possible combinations by which you can manage reference and value types, also don't forget that the structure is a value type and the enumerator as well, but all objects are reference types.

Open your Visual Studio, and create a new C# Console application, give it any meaningful name such as ByValVsByRef, and then copy the following code into your Program.cs



1 using System;


2 using System.Collections.Generic;


3 using System.Text;


4 using System.Collections;


5


6 namespace ByValVsByRef


7 {


8 class Program


9 {


10 static void Main(string[] args)


11 {


12 /// start : Calling Value Type such as string by value and by reference


13 string greeting = "Hello From Main!";


14 Console.WriteLine("Value of string variable BEFORE calling byVal function is : {0}", greeting);


15 ValueTypeByVal(greeting);


16 Console.WriteLine("Value of string variable AFTER calling byVal function is : {0}", greeting);


17 Console.WriteLine("Value of string variable BEFORE calling byRef function is : {0}", greeting);


18 ValueTypeByRef(ref greeting);


19 Console.WriteLine("Value of string variable AFTER calling byRef function is : {0}", greeting);


20 /// end : Calling Value Type such as string by value and by reference


21


22 /// start : Calling Reference Type such as Hashtable by value and by reference


23


24 Hashtable ht = new Hashtable();


25 ht.Add("1", "1");


26 Console.WriteLine("Items' count of hashtable variable BEFORE calling byVal function is : {0}", ht.Count.ToString());


27 RefTypeByVal(ht);


28 Console.WriteLine("Items' count of hashtable variable AFTER calling byVal function is : {0}", ht.Count.ToString());


29 Console.WriteLine("Items' count of hashtable variable BEFORE calling byRef function is : {0}", ht.Count.ToString());


30 RefTypeByRef(ref ht);


31 Console.WriteLine("Items' count of hashtable variable AFTER calling byRef function is : {0}", ht.Count.ToString());


32 /// end : Calling Reference Type such as Hashtable by value and by reference


33 Console.ReadLine();


34 }


35


36 static void ValueTypeByVal(string s)


37 {


38 s = "Hello from inside the ValueTypeByVal method!";


39 }


40 static void ValueTypeByRef(ref string s)


41 {


42 s = "Hello from inside the ValueTypeByRef method!";


43 }


44


45 static void RefTypeByVal(Hashtable ht)


46 {


47 ht.Add("2", "2");


48 ht.Add("3", "3");


49 ht.Add("4", "4");


50 }


51


52 static void RefTypeByRef(ref Hashtable ht)


53 {


54 ht.Add("5", "5");


55 ht.Add("6", "6");


56 ht.Add("7", "7");


57 }


58 }


59 }


The output of the above code is as depicted in the following screen shot:


In the above code we set a string variable's value and then call two different methods in which we modify the contents of the variable, also for the reference type we declared a HashTable and added an initial item, then we passed the variable to two different methods the first takes the reference type by value and the second by reference, if you have a look at the code you will get to the following rule,

  • Passing a value type variable by value doesn't affect the variable's value.
  • Passing a value type variable by reference changes the variable's value.
  • Passing a reference type variable by value changes the variable, because the variable's or object's contents are not passed, but the object's pointer or memory location is getting passed to the method, and the method works on the pointer that ultimately changes the object's contents.
  • Passing a reference type variable by reference changes the variable, because in this case the pointer of the object's pointer is getting passed to the method, and in this case it yields the same behavior as in passing the reference type by value.
Very Important Note:
For the reference types if you are overwriting the object inside the method and the object reference is passed by value, then the calling code will not have the updated object data, in this case you have to pass by reference to get only the data that’s, to clarify this point add the following line at the beginning of both functions RefTypeByVal and RefTypeByRef:

ht = new Hashtable();

Then run the application; you will get the following output:

As you see the count doesn't change after the byVal call because the pointer is overwritten, whilst after the byRef call the count is only 3 not 4 because the reference's reference is overwritten, obviously this is why most of the developers think that the reference types should be passed byRef rather than byValue, especially when the object is overwritten inside the function.

That was a peek into value and reference types, because whilst developers use and instantiate everyday's .NET types they forget the basic concept, so I tried to clear it out in this post, hope you have enjoyed it.!

Labels: