NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Namespaces

Do avoid the possibility of two published namespaces having the same name by prefixing namespace names with a company name or other well-established brand. E.g., Microsoft.Office for the Office Automation Classes provided by Microsoft.

Overall Guidelines

The general rule for namespace naming we have been using for over a year now is: CompanyName.TechnologyName. That would mean we should expect to see Microsoft.Office, PowerSoft.PowerBuilder, etc. Notice this is merely a guideline, 3rd party companies are free to choice other names.

The Root Namespace

For the most part Microsoft follow the general guidance above for naming its technologies exposed to the managed world. We expect to see namespaces such as Microsoft.Office, Microsoft.Exchange, Microsoft.StreamingMedia, Microsoft.MSCom in the next couple of years.

The NGWS runtime has an obligation to identify certain technologies as being fundamental building blocks of the platform. These technologies conceptually belong more to the NGWS frameworks and runtime than to Microsoft. Consider the possibility of turning the NGWS frameworks and runtime over to a standards body: what technologies would go with it and what would Microsoft continue to hold on to?

System.*

System is the root namespace for the set of functionality that is part of the NGWS platform. The definition of what’s in a platform is by necessity subjective. There is a certainly a judgment call to be made on what is part of the platform and what is not, however we have outlined to following guidance for functionality in the System namespace.

Expose a generic set of functionality - The functionality must be infrastructure peaces upon which we expect our customers to build on. This restriction helps insure the integrality of System; that is, it cannot be polluted by any random functionality Microsoft builds. Essentially, it is an area we don’t expect competition in.

For example, the Office object model should NOT be in system because the functionality it exposes is not generic it is specific to the office implementation.

Be Rationalized with Similar Technology – We don’t want to expose more than one way to accomplish the same goal in the base system classes. Therefore what we do expose needs to be rationalized with similar functionality. For example we can not ship a messaging story in System that we already know will be completely replaced in V2. We can ship the building blocks or a small part of the messaging story in System.

Does not Re-Introduce Existing Functionality – If we already ship a way to solve a problem, do not add a new way in system.

Naming in System

Microsoft.*

This set of functionality represents the value Microsoft is adding to the NGWS platform. It is typically more domain specific (i.e. word processing, finical) and our customers find it valuable enough to pay for.

Although we certainly expect for the vast majority of functionality in the Microsoft.* namespace to have most of the attributes listed above, they are not required. The ones that are required of any managed library Microsoft ships is: