.NET Framework Client Profile - What Will Be On It?

Justin Van Patten has posted on BCL Team Blog about the .NET Framework Client Profile.

In this post he goes through the list of the assemblies that will and will not be part of this client profile.

If you know how classes are packaged in the .NET Framework, you know that sometimes they are packaged, often, not by concern but by ownership. That's why you find a provider model on System.Web.dll, as well as HttpUtility, or even the Cache (that can be very useful in non-web applications).

If you read through the comments you'll come to the conclusion that there is a need to several client profiles (or a bootstrapper that will be cooked up by the developer, which is worst). Some of these profiles could be (loose definition):

• Application Foundation - mscorlib.dll, System.dll, System.Core.dll
• Windows Forms - System.Windows.Forms.dll
• Windows Communication Foundation (client) - System.ServiceModel.dll (broken in core and client only classes)
• Windows Communication Foundation (server) - System.ServiceModel.dll (broken in core and server only classes)
• Web - System.Web.dll (not the full fledged ASP.NET just because you need HttpUtility)
• ...

This could be taken to a level that the Silverlight, XNA, Robotics, Compact Framework would become profiles of the framework. Something like the concept of server roles for server operating systems.

I think that more important than what each one of us would like to see in this Client Profile is that the team is analyzing it.