通过

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

  • Anonymous
    November 16, 2008
    PingBack from http://www.tmao.info/what-does-that-net-namespace-mean-system-and-microsoft/

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    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 ;)

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    The comment has been removed

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    I personally feel that System.* is the implementation of the CLI specifications and therefore is platform independent. Microsoft.* are platform specific extensions.

  • Anonymous
    November 16, 2008
    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...

  • Anonymous
    November 16, 2008
    The comment has been removed

  • Anonymous
    November 16, 2008
    #2 is closest to my perception.

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    +1 on System.* being CLI and standards based and Microsoft.* being proprietary platform extensions

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

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    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?

  • Anonymous
    November 16, 2008
    Hmm. Interesting question. I'd turn to you and Cwalina for good answers in such cases :-P 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 :-P

  • Anonymous
    November 16, 2008
    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

  • Anonymous
    November 16, 2008
    The comment has been removed

  • Anonymous
    November 16, 2008
    I think the answer is System.* is part of the .NET and C# standards as a language, regardless of Microsoft as a company.

  • Anonymous
    November 16, 2008
    I think the answer is System.* is part of the .NET and C# standards as a language, regardless of Microsoft as a company.

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    The comment has been removed

  • Anonymous
    November 16, 2008
    I echo the option 4 people. The very name suggests "Standards" vs "we own this"

  • Anonymous
    November 16, 2008
    I wish MSFT to release all Microsoft.* as OpenSource. :)

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    The comment has been removed

  • Anonymous
    November 16, 2008
    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..."

  • Anonymous
    November 16, 2008
    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'

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    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...

  • Anonymous
    November 16, 2008
    The comment has been removed

  • Anonymous
    November 16, 2008
    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?

  • Anonymous
    November 16, 2008
    Ok, 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. BOb

  • Anonymous
    November 16, 2008
    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" ?

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    Going forward, Microsoft should adopt #2 as a principle regardless of what it mean currently.

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    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?

  • Anonymous
    November 16, 2008
    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".

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    The third because System.* is common and platform-independent

  • Anonymous
    November 16, 2008
    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

  • Anonymous
    November 16, 2008
    The comment has been removed

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    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.

  • Anonymous
    November 16, 2008
    I think 3. But also, I would expect Mono to support System.* rather than Microsoft.*.

  • Anonymous
    November 17, 2008
    Same as @davidacoder and Rev. Billy Hollis.

  • Anonymous
    November 17, 2008
    > 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.*).

  • Anonymous
    November 17, 2008
    The comment has been removed

  • Anonymous
    November 17, 2008
    My perception is closest to #2...

  • Anonymous
    November 17, 2008
    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'"

  • Anonymous
    November 17, 2008
    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'"

  • Anonymous
    November 17, 2008
    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

  • Anonymous
    November 17, 2008
    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.

  • Anonymous
    November 17, 2008
    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

  • Anonymous
    November 17, 2008
    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.

  • Anonymous
    November 17, 2008
    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.

  • Anonymous
    November 17, 2008
    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.

  • Anonymous
    November 17, 2008
    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.

  • Anonymous
    November 17, 2008
    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.

  • Anonymous
    November 17, 2008
    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.*").

  • Anonymous
    November 17, 2008
    In this issue: Martin Mihaylov, Ivan Dragoev, Jesse Liberty, Scott Guthrie, Laurent Bugnion, Ning Zhang

  • Anonymous
    November 17, 2008
    The comment has been removed

  • Anonymous
    November 17, 2008
    I agree with @davidacoder and @Ulrich Strauss. That seems to make the most sense.

  • Anonymous
    November 17, 2008
    The comment has been removed

  • Anonymous
    November 18, 2008
    My perception parallels that of davidacoder and Billy Hollis.

  • Anonymous
    November 18, 2008
    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.

  • Anonymous
    November 18, 2008
    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.

  • Anonymous
    November 18, 2008
    #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 :)

  • Anonymous
    November 19, 2008
    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?

  • Anonymous
    November 20, 2008
    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! =)

  • Anonymous
    November 20, 2008
    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.

  • Anonymous
    November 22, 2008
    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.

  • Anonymous
    November 23, 2008
    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.

  • Anonymous
    November 26, 2008
    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).

  • Anonymous
    November 27, 2008
    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.

  • Anonymous
    November 28, 2008
    Like others, I thought System.* was the CLI stuff.

  • Anonymous
    November 29, 2008
    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.

  • Anonymous
    December 01, 2008
    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.