I have noticed a trend with code auto-generated from Microsoft tools.
Here is a sample section of code as I would have viewed it in older samples:
23 [System.Data.Objects.DataClasses.EdmEntityTypeAttribute(NamespaceName = "PizzaModel", Name = "PizzaOrder")]
24 [System.Runtime.Serialization.DataContractAttribute()]
25 [System.Serializable()]
26 public partial class PizzaOrder : System.Data.Objects.DataClasses.EntityObject {
This is the exact same code, except it includes the more recent changes that I happened to notice:
23 [global::System.Data.Objects.DataClasses.EdmEntityTypeAttribute(NamespaceName = "PizzaModel", Name = "PizzaOrder")]
24 [global::System.Runtime.Serialization.DataContractAttribute()]
25 [global::System.Serializable()]
26 public partial class PizzaOrder : global::System.Data.Objects.DataClasses.EntityObject {
Notice the reference to 'global::'? Apparently, Visual Studio and ultimately the compiler can potentially be confused.
Here is a link to the Namespace Alias Qualifier:
http://msdn2.microsoft.com/en-us/library/c3ay4x3d(VS.80).aspx
According to that sample, you may have a namespace TestApp and within that TestApp namespace have a constant named Console within a class named System. The example also shows a using statement referencing the namespace System. That combination is apparently deadly to the compiler and even though Console.WriteLine() exists within the System namespace; it cannot be referenced because it conflicts with the Console constant. Here is the "non-working" code:
1 using System;
// yada yada ...
8 class TestApp {
9 // Define a new class called 'System' to cause problems.
10 public class System { }
11
12 // Define a constant called 'Console' to cause more problems.
13 const int Console = 7;
14 const int number = 66;
15
16 static void Main() {
17 // Error Accesses TestApp.Console
18 //Console.WriteLine(number);
19 }
20 }
To the rescue: We have the 'global::' namespace qualifier available which forces a namespace comparison to be based on the entire namespace starting from the root. I can only assume that namespace collisions (at least for Microsoft) happen more often than we assume; especially, when code generators are involved.
It is one thing to create and compile code within Visual Studio, but its entirely different if you are creating/ managing a code generator where you can never be sure of namespace conflicts. I happen to use CodeDOM (http://msdn2.microsoft.com/en-us/library/y2k85ax6.aspx) and understand completely how this could benefit my auto-generated code.
If you auto-generate code, it may be wise to to include a global reference similar to the new trend I am noticing. If you do not, this post may be helpful to simply understand the global reference.
