What Does that .NET Namespace Mean: System.* and Microsoft.*

image I need your feedback… I am chatting with some co-workers about the perception of in the .NET Community of what the System.* and Microsoft.* namespaces mean.    So I had the crazy idea of just asking you!  

For this exercise, I’d like you to think about a new "feature area" of the .NET Framework… Would you instinctively draw any conclusions about that area based on if the namespace where System.* or Microsoft.*?  If that feature area were in the Silverlight subset of .NET, would that change your mind at all?

There are basically three schools of thought among my co-workers  — which one is closer to your perception? 

1) They are the same or it really doesn’t matter.    The root namespace between System.* and Microsoft.* have no meaning…  Microsoft appears to be arbitrary about when functionality goes in one or the other. 

2) Part of the Framework vs.  Addons. 

System.* indicates stuff that is logically part of the framework.  It is 100% supported, solid-long term design that will not need to churn, safe to bet on, stable, likely will get great tooling support.  Designed to be very interoperable and could work anywhere .NET is.  This may ship as part of the redist or maybe an out of band (such as ASP.NET MVC, ASP.NET AJAX, etc). 

Microsoft.* is the bleeding edge stuff or value-add.  It is typically very cool stuff that adds on to the framework and enhances it, but maybe a work in progress… over time you might expect some of those concepts to go into the framework.    As an example, the great work patterns and practices does often falls into this bucket. 

3.) Part of the core redist vs. addons

System.* means it ships in the core redist.  You are not able to ship it with your application.  System.* stuff only ships when the redist revs.   You would not expect Microsoft to do any out-of-band releases in the System.* namespace for example. 

Microsoft.* means it is not part of the core redist.   A note: as we move stuff into the core redist you’d expect us to change the namespace from Microsoft.* to System.* meaning you’d have to tweak any calling code *if* you wanted to take advantage of the new version.


So, what do you think?  Which one best fits your thoughts this?  I’d love any other comments…

Comments (82)

  1. Alan Dean says:

    I personally think that System.* ought to refer to types that are part of the CLI.

    Of three choices provided, I would vote for (3) from a pragmatic perspective.

  2. davidacoder says:

    I always thought that stuff in System.* would not really have a dependency on other MS technology, i.e. might in general also be available in Mono. Stuff in Microsoft would be much closer coupled to other MS products, like COM+ support, or Office or something like that. Maybe also stuff where MS has patents and will guard them in the sense that Mono might not be allowed to implement it. I have no clue whether that interpretation actually makes any sense 😉

  3. Actually, none of these captures my intuition about the difference, which I formed in the early days of .NET. I’m much closer to davidacoder.

    I always thought of System.* as the completely platform independent part of the .NET Framework, and Microsoft.* as the part that had various dependencies on Microsoft products or Windows features. My expectation was that anything in Microsoft.* was much less likely to be placed in a version of the .NET Framework for another platform (such as Compact Framework, or Mono).

    That’s one of the reasons why I tended to avoid the Microsoft.VisualBasic namespace, even though I do all my development in VB.

    This interpretation may be obsolete based on the evolution of the platform, but it’s how I started thinking about it and nothing has really been put out there to chance my perception.

  4. int19h says:

    In practice, it is really #1.

    #2 doesn’t work because all VB runtime is in Microsoft.*, even though it’s clearly a part of the framework (it’s installed with .NET redist and supported as part of it, etc). Also CodeDOM providers for VB and C# are parts of framework (they are specifically guaranteed to be there by MSDN), but also live in Microsoft. And of course Microsoft.Win32.* namespace. None of those are identifiable as "value-add" nor as "bleeding edge".

    #3 is similarly not true – see the list above of what’s in core redist. And of course PLINQ, MVC are add-ons, but are in System.*

    As to what I would prefer – System.* should refer to stuff that is covered by the most-current ECMA spec, and should be reserved for future revisions of that spec. _Everything_ else (this includes ASP.NET, ADO.NET, WinForms, WPF etc) should be in Microsoft.*.

    This is a pretty purist approach, of course, and something unlikely to happen… a more pragmatic one would be this: System.* should only contain things that are inherently cross-platform. For example, WinForms shouldn’t be there, because it’s closely tied to Win32 (Control.Handle, Control.WndProc etc); but WPF should, because its APIs do not have Windows tie-ins.

  5. Peter Ritchie says:

    I agree with davidacoder, and think it’s none of the three.  I have always viewed types in the Microsoft namespace as types that encapsulated concepts that are Microsoft-OS dependant or are specific to Microsoft-proprietary technologies or products.  Microsoft.Win32: types in that class could only really be expected to work on a Win32 implementation (which is Microsoft specific), or Microsoft.CSharp: specific to a Microsoft C# implementation.

    Regarding point 1: I think there’s a clear deliniation between the two namespaces.

    Regarding points 2 & 3: this falls apart if you look at the Microsoft.CSharp namespace, it’s part of the "framework" and the core redist.

  6. Shameel says:

    I personally feel that System.* is the implementation of the CLI specifications and therefore is platform independent. Microsoft.* are platform specific extensions.

  7. barryd says:

    Another vote for the ideal being System.* being the CLI classe and namespaces.

    But right now it’s simply a big mess. And don’t get me started on duplicate class names between System.Web and System.ServiceModel…

  8. I definitely think of System.* and Microsoft.* in terms of three – core platform and redistributable add-ons. I would also assume that the Microsoft.* stuff had reached a certain quality bar, but had not necessarily gone through all the hoops required by something "in the box".

  9. Gene says:

    #2 is closest to my perception.

  10. Laurent Debacker says:

    My feeling is that System is for general stuff, while Microsoft is more about Microsoft-specific technologies (VB because it is not an ECMA-standard, Windows oriented stuff). Consequently, I would expect System to be extremely portable, while Microsoft would be more tied to a specific platform.

    Also, I don’t expect classes to go from one to the other since it would require more work to ship new applications based on older ones.

  11. John Noss says:

    +1 on System.* being CLI and standards based and Microsoft.* being proprietary platform extensions

  12. barrkel says:

    +1 again on none of the three, with System.* being standards-oriented platform agnostic CLI, and Microsoft.* being proprietary stuff.

  13. I have always thought about them as you do on the third option. I expect the System.* namespaces to be always supported by the core of .NET, so they must be available in every single computer my applications run, being Linux, MacOS or Windows the underlying OS.

  14. Henrik says:

    Definitely 3.

    But I have to say, that the only time I’ve seen the Microsoft namespace is in the Enterprise Library, which is an addon, that for me, is something I should be certain to ship with my app. The rest should be in the framework downloads.

    When something is added to the framework (as Ajax in 3.5) the namespace should be System.

    Where is the MS namespace currently used, besides Enterprise Lib?

  15. Anders Haahr says:

    Hmm. Interesting question. I’d turn to you and Cwalina for good answers in such cases 😛

    I think 3 is the best match to how I’d explain it if someone asked me and I had to answer without first looking for some kind of definition. I beleive it’s the best match for what I learnt when I began looking into .NET.

    I regard the Micosoft.* namespaces as being stuff that relates to the Windows platform and to MS Apps in general.

    The P&P stuff belongs in the Microsoft namespace even though it has nothing to do with MS’ platforms or apps as such because I regard their purpose being Microsoft showcasing how one build netfx based software using patterns and best practices (I know there’s more to it than that).

    I’ve never used Mono, but I’d expect a System.* Namespace bearing heavy resemblance to netfx’s.

    Both 2 and 3 would work for me. If something tied closely to the .NET framework, like ASP.NET MVC, had to be put on hold until the next scheduled rev then it would be to no one’s advantage (MS couldn’t get their stuff out and consumers couldn’t use it). If it had to have the Microsoft namespace it wouldn’t integrate as seamless.

    It seems to me that you don’t feel like coming up with new namespaces, and the difference between your case 2 and 3 seems to be whether the Microsoft.* or the System.* should be the positive defined namespace (or category) where everyone knows exactly what’s in. Either it’s "System.* is the stuff you get when you download a version of the netfx" or "Microsoft.* is the stuff that’s tied to MS’ platforms, Office e.t.c" and then you’ll put the blurry stuff that doesn’t really fit 100% into one of the namespaces into the namespace that is not defined positively, or rather that is defined negatively as being the stuff that doesn’t belong in the positively defined namespace (category).

    I think my opinion is that 2 is fine if the add-ons are meant to be merged into the core redist when it is possible. If it is not meant to be a part of the core redist never, and you think it’s more System.* than Microsoft.*, then maybe you should consider a third namespace for those cases 😉

    P.S. I decided to go for the Sony X1 mobile phone after reading the user comments on that other post of yours 😛

  16. John Rie says:

    I echo some of the other posts which has kind of turned in to option 4.

    Option 4

    System.* – for platform independent parts of the framework

    Microsoft.* – for technologies specific to Microsoft and MSFT products

  17. Thomas Danecker says:

    I also associate licensing stuff with it:

    System.* is part of "the framework". free to use everywhere you want to. you don’t have to worry about anything.

    Microsoft.* otoh is something coming "from microsoft", with all the implication like limiting licenses, etc.

    this makes me fit best into the 2nd box, but more like "the framework" vs. "from microsoft"

    still, the implementation of the framework is coming from microsoft, but everything named "the framework" may also be implemented from others (like Mono).

    Stuff in a Microsoft.* namespace is clearly not intended to be implemented from others.

  18. I think the answer is System.* is part of the .NET and C# standards as a language, regardless of Microsoft as a company.

  19. I think the answer is System.* is part of the .NET and C# standards as a language, regardless of Microsoft as a company.

  20. David Nelson says:

    I agree with int19h: currently it is #1, basically random, but ideally I would like to see System.* reserved for the ECMA spec. The problem with that is that there are Microsoft-specific members on types which are defined in the CLI spec; these obviously cannot be segregated into their own namespace. But generally I would try to keep that separation.

  21. BradA says:

    Great – some good points so far… I can see this is going to be a good discussion, and very difficult to categorize the answers!

    I hear some folks talking about what is MicrosoftWindows specific or not..  so it sounds like if we were going to ship something that is NOT specific to windows (like say some new controls for Silverlight), you’d see that going into System.*?  

    Some of you asked for examples of stuff in the Microsoft namespaces… the Ajax control toolkit and P&P stuff are good examples…  If we shipped some controls outside of the core redist but they were very mature, fully supported, would you expect them in the System.*?    Conversely if we shipped them in the Microsoft.* namespace would your knee jerk reaction be that they may be less “baked”??

    As I read the comments, I wonder if you are somewhat more careful about adoption technologies in the Microsoft.* namespace?  Do you think of those as different somehow?  

  22. Matt says:

    I echo the option 4 people.

    The very name suggests "Standards" vs "we own this"

  23. KKI says:

    I wish MSFT to release all Microsoft.* as OpenSource. 🙂

  24. Henry Boehlert says:

    Looking at "option 4", from davidacoder to John Rie, new Silverlight controls fall into the "Microsoft.*" bucket as they are not portable, no necessary part of the (initial) framework and are not publically depended on by "System.*" code.

  25. ludovic says:

    Somehow, it’s option 4 for me too… "System" means everything that is or could be standardized, open, designed for cross platform use, etc. "Microsoft" is all the stuff that is proprietary to Microsoft, including platform specific things (Windows, Zune, XBox, etc.) and source code that is not supposed to be open (patented stuff, etc.).

    Arguably, WinForms could have been in a "Microsoft" namespace.

    I don’t think a namespace should in any way suggest whether a given library is stable or a work in progress, or anything. Say I released a highly experimental set of collections and containers… I would still put it in "System.Collections.*" because that’s just where people would expect to find those classes. It also makes my stuff more discoverable.

    I can see how some people would put it in "MyCompany.Collections.*", but that’s not how I would personally do it, unless that code won’t run everywhere, or is somehow super secret and only my company is supposed to know how it works.

  26. JFalcon says:

    I would tend to think that the System.* namespaces should be reserved for anything that is meant to be cross platform and easily reused.  However, what category would you assign to a .NET API (i.e. Silverlight) that has been deliberately watered down in the sense that you can share some code (from a textual standpoint), but other code you cannot because there were features stripped from the framework?

    Perhaps System.* would make more sense if it can be used by all applications, and then perhaps make platform specific namespaces, like Silverlight.* so that people don’t get confused and think those namespaces are interchangeable.  This, in my humble opinion, is one of the disappointing things about Silverlight; it’s lack of support in functionality between same namespaces.

    I know Silverlight 2, while RTW, is still an emerging technology.  However, it takes some effort to write code and organize it in such a way that it can be shared between .NET 3.5 applications and .NET Silverlight applications.  It would help if the developer didn’t have to worry about the distinction and could use the appropriate namespace as the need demands.


  27. DThrasher says:

    Judging by the comments so far, if there isn’t a difference, there _ought_ to be one. Otherwise, why would Microsoft use a different name?

    I’d assumed that the naming convention had something to do with the redistributable packages, but apparently that’s not a consistently good indicator.

    It’d be somewhat disappointing if the answer were something dry and practical like, "We just used different namespaces whenever class names might collide…"

  28. Steve says:

    To me….

    If it’s in the .net framework install it should all be ‘System’

    If it’s a separate install – ie. Ajax Toolkit – then definitely Microsoft.

    Another example would be an API for a product – ie. Microsoft.Sharepoint.*

    These are separate releases.  

    Now, if you decide to move the Ajax Toolkit into the .NET framework, you’d need to be consistent and rename it to System

    This would clear up much confusion, and I could look at my reference, able to see clearly, what is ‘part of the framework’ vs. ‘what is an additional ‘addon’ or extension’

  29. John P. Grieb says:

    I think that #2 best matches my view of System.* vs. Microsoft.*

    However, I do think of System.* as the core of the .NET Framework and that the System.* classes should be shiped as part of the core redist. I don’t like changing namespaces from Microsoft.* to System.* as that would break backwards compatability. Also it seems that in the past functionality has not so much "moved" from the Microsoft.* classes into the framework as they have been integrated into it.

  30. Ashic says:

    I don’t think that’s actually the case (though I don’t know if there’s evidence to disprove it either) but I would think anything ".Net" would be System and anything "Microsoft" would be Microsoft. So, a cross platform Silverlight control should be System. An Office library or a Windows specific library would be Microsoft. It does seem like sme libs created entirely by MS but put up on Codeplex do get named Microsoft, but I’d like to see the namespace name be about what it does as opposed to who it’s from. After all, MS is MS and not some 3rd party control dev who need to tell everyone using their bits that they created the control in every source file…

  31. Jason says:

    First off, thanks for asking for our input Brad.

    I pretty much agree with davidacoder above.

    I would expect to see new Silverlight controls make it into System.* once they are fully baked, now that SL is a shipped product and is platform independent.

    When I see types in the Microsoft.* namespace I assume it is one of the following:

    1. Not fully baked (CTP, or released on Codeplex). I expect that this type might move to System.* in a future release if it is common enough to be part of the framework.

    2. Addons (Enterprise Library)

    3. Platform specific

    In regards to #2, I think this is in-line with the practice of the namespace starting with the company name. It just so happens that the company is Microsoft, but the product is not coming from one of the .Net Framework teams.

    Maybe others would find this boring, but I would like to see some of these arguments in a video up on Channel 9.

  32. I always thought that System.* is part of the Framework and Microsoft.* are extensions like the one from the P&P Team.

    So far I would say #2

    All Microsoft.* I used so far where not part of the distribution (as I remeber). In this case it would not matter if it moves to System.* because I deploy it myself.

    I also use third party libraries and they are replaced step by step with the core framework if it fits my needs. So changing the namespace is a kind of refactoring for better solution and would be ok for me.

    But after reading the above comments I realized that I was wrong because parts of the framework are placed in Microsoft.* so the answer is #1

    Maybe there should be a strict definition what is part of the framework and what is an extension.

    Should an extension be part of the distribution?

  33. Pilotbob says:


    I always thought quite the opposite of what people here are saying. I always assumed that System was the BLC features that wrapped Win32 like functionality… like IO, COM, Threading, Memory, etc. And Microsoft. was more meta classes and those that build ontop of the API such as WinForms, ASP.Net, WPF, Cardspaces etc.


  34. DM says:

    I say #3 would make much more sense in the future.

    System.* vs Microsoft.* is a big mess at this moment.

    Yes, I tend to be more careful about adopting technologies in the Microsoft.* namespace unless I know for sure that they’re part of the "Framework" (therefore, I flip a bit and my brain sees them as if they were in "System.*" 😉 ).

    By the way, are you going to fix "Presentation*" and bind it to "Microsoft" or "System" ?

  35. David Nelson says:

    I don’t agree with putting "less baked" features into Microsoft.*. Namespaces are supposed to be about categorizing features so that they are easily discoverable; they not be about what stage of development a technology is in. For the same reason I would vote very strongly against moving types from Microsoft to System. Types should be put in the namespace where they make the most sense, and they should stay there.

  36. Ravi Pahuja says:

    System.* reminds me of .net classes which are independent of platform( 🙂 ), only depended on .net framework, but when I think of Microsoft.* that seems to be depended on Microsoft Platform.

  37. Adwait Ullal says:

    Going forward, Microsoft should adopt #2 as a principle regardless of what it mean currently.

  38. RichB says:

    Microsoft.* means something that’s a tight wrapper around Windows OS functionality, and is unlikely to be generic enough to be implemented on another OS.

    I know this definition breaks down with WinForms and in other scenarios. But the most used Microsoft.* API is probably the Windows Registry – which is where most people get their ‘understanding’ of what Microsoft.* means from.

  39. Oran says:

    If it starts with Microsoft.* it seems like it’s less likely to be MS-PL’d or end up in Mono, which when it comes to Silverlight/Moonlight would be a Bad Thing.

    Why would anyone want to brand their libraries as Microsoft.* rather than System.*?  Is it a "leaving our mark" kind of thing?

  40. I agree with most people, System.* is common and platform-independent stuff and Microsoft.* is a MS-coupled stuff.

    In addition to this, Microsoft.* on a new thing means that it is not finalized and I should pay special attention to the license — it may be "preview use only, no production".

  41. Abhilash says:

    Frankly, it doesn’t matter. It’s either that or #3. The tooling matters though, so as long as the tool knows where things are and I can reach my type using intellisense, it shouldn’t be a problem. But as you have mentioned, type relocation has got it’s own cost too.

  42. Abhilash says:

    Frankly, it doesn’t matter. It’s either that or #3. The tooling matters though, so as long as the tool knows where things are and I can reach my type using intellisense, it shouldn’t be a problem. But as you have mentioned, type relocation has got it’s own cost too.

  43. Ricciolo says:

    The third because System.* is common and platform-independent

  44. Quentin O' Donell says:

    I think System.* refers to the standardized types & their members guaranteed to work accross all .net versions accross different platforms(Mac,Mono,Windows etc) while Microsoft.* refers to namespaces which use/are dependent on some Microsoft propreitary Technology and not all Microsoft.* namespace members are guaranteed to work across all platforms

  45. Mark Ingram says:

    It’s got to be (3).

    System.* is stuff that’s supported out the box via the redist. Microsoft.* is extra functionality you can download and ship externally. Useful, but not part of the core .NET framework.

    Makes a lot more sense like that.

  46. Closest one …. option (3)

    System.* ist Plattform independent and shipped with the Framework. Whereas Microsoft.* ist specific to a certain MS Technologie without a redistribution package for 3rd party developers.

  47. Thomas Broyer says:

    I would expect System.* to be available on all .NET redists (be it Microsoft’s, Mono or any other that might exists/appear) while Microsoft.* is "internal" to Microsoft’s redist and/or specific to Microsoft products.

    I.e. you can use them but your app might then be locked to the Microsoft’s redist, or eventually might break with a later version (depending on whether the class/method/property is documented or not, and how).

    This seems to actually be the case: documented in Microsoft.* are IE, IIS, Exchange, JScript, VB.NET, MSBuild, TabletPC (Ink and StylusInput), Windows, etc.

    C# wasn’t an ECMA standard when Microsoft.CSharp first shipped, so it lives in Microsoft.CSharp; and moving it to System.* would be a breaking change that’s not worth it.

    The SQLServer data provider living in System.Data.* is fine, because an application running on Linux or Mac could very well talk to a SQLServer database. The classes for coding in .NET within SQLServer have been moved to Microsoft.SqlServer.Server in .NET 2.0, and that’s a good thing.

  48. I think 3.

    But also, I would expect Mono to support System.* rather than Microsoft.*.

  49. Same as @davidacoder and Rev. Billy Hollis.

  50. int19h says:

    > As I read the comments, I wonder if you are somewhat more careful about adoption technologies in the Microsoft.* namespace?  Do you think of those as different somehow?  

    I think of those mainly as "not quite as portable" – i.e., I wouldn’t expect Mono to have that stuff. I certainly don’t think that it’s somehow automatically lower-quality than System.* (I look at where the assemblies come from instead – e.g., in general, I expect the same quality for all stuff that comes as part of .NET redist, whether System.* or Microsoft.*).

  51. ggreig says:

    I think I’m with the option 4 people. System.* should have a high degree of portability, while Microsoft.* can have a reliance on Microsoft products.

    System.* needn’t necessarily be universally portable – for example, I wouldn’t object to desktop- or server-focused functionality being there just because it couldn’t be ported to a mobile environment or Silverlight – but it should, at least in principle, be portable to third party environments without any prejudicial assumptions. Of course, whether or not a third party implementation is subsequently developed would be out of your hands.

    Of the options in your original post, I am closest to #2. APIs under System.* should change seldom or not at all, but there’s no reason why they shouldn’t be added to out-of-band, so long as the out-of-band additions also meet those expectations. Out-of-band releases should subsequently be an integral part of the next major release.

  52. My perception is closest to #2…

  53. My vote goes to "2) Part of the Framework vs.  Addons.", but found Matt’s comment on November 16, 2008 5:34 PM pretty straight: "’Standards’ vs ‘we own this’"

  54. My vote goes to "2) Part of the Framework vs.  Addons.", but found Matt’s comment on November 16, 2008 5:34 PM pretty straight: "’Standards’ vs ‘we own this’"

  55. I think System.* are the standard implementations which are more ore less available on all platforms.

    Microsoft.* are platform specific extensions.

    e.g. Like it has been handled in .NET Compact Framework for Windows Embedded CE

  56. ncage says:

    I really don’t understand those who perceive System.* as Cross Platform Independent. Maybe this is the way it should be but its definitely the case (WinForms for example). I view System.* as the CORE framework available to all languages that use the CLR. The Microsoft.* is anything extra thats not a core part of the language. For example Visual Basic stuff. Yes you can reference it from your C#/F# projects but its not really part of the core "System". Also interfaces to visual studio itself or anything to do with MSBuild. So i think its closer to #3.

  57. GregUzelac says:

    Microsoft. for things that are Windows-specific, and probably have no equiv in Mono, etc

    System. for low-level OS-related, but not OS-specific, items

  58. I would think that the System.* offerings are conform the CLI spec and do not require any additional software. The Microsoft.* items are either out-of-band, platform specific, or require additional software. Good examples are the AjaxToolkit or the Office interp assemblies. I think when people talk about platform independence they are referring to Silverlight, the Mobile Framework, and maybe even Mono. Generally, I wouldn’t think that the Microsoft.* offerings are any "less baked", but I would expect them to NOT be bundled with the .Net reditributabled package.

  59. ShadowChaser says:

    I agree with the others:

    Restrict System.* for CLI and other non-platform specific classes. Do not use System.* outside of the .NET Framework Redistributable (ie/ NET_FX)

    Use Microsoft.* for releases not part of the .NET Framework or Microsoft-specific technologies (ie/ classes that expose Window Handles as IntPtr or other "deep rooted" Microsoft tech)

    Name the assemblies themselves after the "main" namespace of the file. For example, System.Net.Dll. The .NET Framework 3 assemblies are a horrible mess and will be difficult to locate going forward (ie/ looks like a bunch of COM/ActiveX guys named them!).

    The original .NET 1.0 betas had it right – for example, it used to be Microsoft.Windows.Forms. It was changed to System.Windows.Forms at the last minute, and I’ve always believed it was a bad decision.

  60. John says:

    I agree with several of the comments.  System was platform indepentant and would work on non-microsoft platforms.  Where Microsoft. would only work on say a version of windows.

    This was why registry was placed in Microsoft because it was a windows only thing.

  61. I consider the stuff in System.* to be core stuff. The stuff in Microsoft.* I consider to have to do with specifically Microsoft products. I try not to use the stuff in Microsoft.* unless I’m working specifically with that thing.

  62. Joe says:

    To me, option 3 is ideal.  But I think it’s too late – there’s too much stuff shipping outside the core redist that’s already in System.*.*

    So Option 2 is more likely the natural behavior.  

    Switching namespaces isn’t a big deal as long as the refactoring tools know to change the namespace declarations in the XAML.

  63. Eric Swanson says:

    Technically, I agree with all three scenarios. I don’t have time to read all of the comments, but, ideally, I would expect System.* to contain only elements of the core distribution and framework. In a utopia, I suppose everything in System.* could also be ported to something cross-platform like Mono.NET. I would expect Microsoft.* to contain interoperability libraries for other Microsoft products as well as code releases from Microsoft teams not yet supported by the core distribution. However, I would also expect that the namespaces used would explicitly clarify Microsoft professional support (e.g. "Microsoft.Labs.*").

  64. In this issue: Martin Mihaylov, Ivan Dragoev, Jesse Liberty, Scott Guthrie, Laurent Bugnion, Ning Zhang

  65. I agree with Alan Dean and those who agreed with him. 🙂

    System.* should be reserved for those types which are part of the non-platform-dependent CLI, whereas Microsoft.* should contain all the extensions with which Microsoft enhances the CLI.

    Like ShadowChaser, I have always thought that WinForms should have been part of a Microsoft.Windows.* namespace. Something like Silverlight, actually has greater cross-platform potential and would be more appropriate in the System.* namespace hierarchy.

    Whether something is "cutting edge" or not quite ready for production use, should not determine a namespace. That’s a versioning issue, not a naming issue, IMO.

  66. I agree with @davidacoder and @Ulrich Strauss. That seems to make the most sense.

  67. Rafael says:

    I always thought that System.* was meant to the core components that could be implement in any platform, and Microsoft.* refers to Microsoft specific technology, like in SQL Server SQL-SMO, where the classes resides in the Microsoft.*, since SQL Server is a Microsoft specific technology, and not "generic" implementation.

  68. apinzur says:

    My perception parallels that of davidacoder and Billy Hollis.

  69. Kyralessa says:

    When I look at the namespaces on my system, what jumps out at me is stuff like Microsoft.Office, Microsoft.SqlServer, and Microsoft.VisualStudio.

    So to me, System.* is something you have if you install the .NET framework.  Microsoft.* is something you have if you install some other program, like Office, SQL Server, or Visual Studio.  The Microsoft.* namespace is sort of a flag/warning that you have dependencies other than just the .NET framework.

  70. Daneil says:

    I would say #2 only because I use the Enterprise Library. I’m just used to seeing the Microsoft.* namespace when using those tools. Since they are not part of the core framework, my perception relates closely to #2.

  71. Miral says:

    #3 I think.  System.* should be for the core parts of the runtime — they can be added to via service packs, new runtime versions etc, but separately-downloaded libraries should be forbidden from adding classes to System.*.

    Of course with the advent of the Client Profile the question of "is this functionality available" got a whole lot more complicated anyway 🙂

  72. int19h says:

    Brad, with all the replies (and, it seems, a strong preference for one particular scheme here which is different from the current way of things) – what would be your comment on this?

  73. Ben Callister says:

    i have always thought it was #2 and i would prefer if it stays that way. i would be shocked if MS intended otherwise. however, #2 can also be stretched to include #3 as well, but #1 is out. no way. nada! =)

  74. BradA says:

    Yes — int19h — I am actively working on this… This thread has already helped me out a lot.   I might take a few weeks to get back to you as there is just as much colorful opinions in side the big house as outside… but we will get back to you.

  75. David Nelson says:

    Interesting, all of the people who seem to think that WinForms is Windows specific. Mono has implemented the majority of WinForms to run on Linux and Mac. It is poorly named, perhaps, but that doesn’t mean it doesn’t make sense in System.

  76. int19h says:

    Windows Forms _is_ Windows specific. Case in point: System.Windows.Forms.Message, and Control.WndProc. If those aren’t Win32-specific, then I don’t know what is.

    Yes, Mono guys tried, more or less successfully, to work around that. To do so, they had to effectively re-implement Win32 message loop specifically for UI purposes, with exact same WM_* messages as on Windows (so that those WinForms programs that override WndProc will receive what they expect).

    Even so, to date, it still can’t run any production WinForms application I throw at it, unless that application was specifically designed to run on both .NET and Mono by avoiding the corners of WinForms that are unsupported or badly supported on Mono.

  77. David Nelson says:

    It’s true that the design of Windows Forms is highly correlated with the Win32 architecture. It probably could have been better abstracted, with non-platform-specific control interfaces in System, and the Windows implementation in Microsoft.Windows.Forms; but I imagine Microsoft didn’t think the benefit was worth the effort.

    For what its worth, the two main WinForms applications I work on at my job were written by a programmer whose prior experience mostly consisted of VBA macros in office applications. They are not well designed, and they were definitely NOT designed for compatibility. But they both ran fine on Mono as of a year ago (with simple usage; I was testing out of personal curiosity so they weren’t production tested).

  78. Rudi says:

    I’m pleased to see that I have the same perception of the .Net namespaces as most of the readers.

    System.* == CLI (or portability)

    Microsoft.* == libraries for Microsoft Products

    +1 for Option 4

    Having been part of the first wave of Technical Evangelist spreading the word about .NET, it was clear (for me) that the openness of the System.* namespaces, being published as ‘real’ open ECMA specifications , with the free ‘rotor’ distribution, was one of the initial thoughts behind the namespaces. But even then there were the ‘odd’ ones, like WinForms.

    It’s a pity that Microsoft has not kept the distinction clear (or clean) between what is part of the ‘spec’ and what is part of Microsoft platform features.

    (Kind of reminds me of the whole .NET 3.0, 3.5 naming mishap, but that is history, just hope .NET 4.0 will be correclty named after its technical merits and not just its marketing merits)

    I would not expect a library to change its namespace, but some support in the core fx for being able to move namespaces from System.* to Microsoft.* could come in handy. E.g. WinForms could move to Microsoft.* in a future version of the .net fx, where the runtime could automagically redirect the assembly bindings to the new namespace without code being build for a previous version of the fx to be changed. In the new version of the fx, the old namespaces can then be marked ‘deprecated’ and removed in the new version +1

    Regarding the distribution, I’d expect all of the System.* to be in the core redist. Ofcourse depending on the ‘flavour’ and version; eg. desktop/server, compact, silverlight, micro; v1.0, v1.1, v2.0, v3.5 (<= see the whole naming mishap again)

    Seeing the .Net Redist grow as it does, and having soo much in there, with soo much that is not used, I hope to see it being split up in several packages, each one containing smaller parts (BCL, WinForms, ASP.NET, WPF, WCF). This will ease the adoption and solve some ISV headaches to distribute .NET with their apps.

    Microsoft.* packages should then exist in their own right, having dependencies on other packages.

  79. Steve Dunn says:

    Like others, I thought System.* was the CLI stuff.

  80. I have never understood the difference, probably because I have never given it much thought. Since the System.* or Microsoft.* placement of .NET classes have never made any difference to me when choosing to use or not use something it makes no sense to me to have two namespace prefixes. I’ll use a class if its functionality helps me write useful code. My only requirement on the namespace is that it should helpfully guide me when looking for classes with the functionality I’m looking for to use.

    If placing code in these two namespaces helps anyone else thats fine by me, but any academic discussion about where things belong is foreign to me if it does not actually help me with a problem that I have. The categorizations I have read in this discussion thread so far do not fall into that category. Simply put. If Microsoft ships a class with functionality that can help add business value to my software I’ll use it, regardless of its namespace. All I want is to be able to find it.

  81. David Morton says:

    I’ve always taken the "Microsoft" namespace to refer to items that would be specific to Microsoft technologies, esp. Microsoft Windows, whereas the System namespace is for items that are more integral to the system, (anything that could be used on any OS as opposed to simply the Microsoft OS’s.)  I suppose I’ve gotten this idea because of the large Microsoft.Win32 namespace, in which the RegistryKey and some other classes specific to the functioning of Windows reside.  Of course, there are other classes in the System.Namespace that do the same thing, but this has always been my immediate perception.