.NET Framework Client Profile [Justin Van Patten]


Last week Soma and Scott Guthrie announced the availability of Visual Studio 2008 and .NET Framework 3.5 SP1 Beta.  As part of this release, we’re introducing the .NET Framework Client Profile, a smaller .NET Framework redist optimized for .NET client applications.  The new redist weighs in at around 26.5 MB, enabling a smaller, faster, more reliable installation experience for .NET client applications on machines that do not already have the .NET Framework installed.


.NET Framework Client Profile Assemblies


Here’s the list of assemblies that are included in the.NET Framework Client Profile.  Please note that this is actually the list of assemblies that will be included in the RTM release of the Client Profile; the beta version released last week includes some assemblies that will not be included in the RTM release (more details below).


BCL, “Core FX,” and LINQ



  • CustomMarshalers

  • ISymWrapper

  • mscorlib

  • sysglobl

  • System

  • System.AddIn

  • System.AddIn.Contract

  • System.Configuration

  • System.Configuration.Install

  • System.Core

  • System.Security

Visual Basic and Visual C++ Language Support



  • Microsoft.VisualBasic

  • Microsoft.VisualC

XML



  • System.Xml

  • System.Xml.Linq

Windows Forms



  • Accessibility

  • System.Drawing

  • System.Windows.Forms

WPF



  • PresentationCore

  • PresentationFramework

  • PresentationFramework.Aero

  • PresentationFramework.Classic

  • PresentationFramework.Luna

  • PresentationFramework.Royale

  • PresentationUI

  • ReachFramework

  • System.Printing

  • System.Windows.Presentation

  • UIAutomationClient

  • UIAutomationClientsideProviders

  • UIAutomationProvider

  • UIAutomationTypes

  • WindowsBase

  • WindowsFormsIntegration

ClickOnce



  • System.Deployment

WCF, Web Services, Remoting, and Serialization



  • System.IdentityModel

  • System.Runtime.Remoting

  • System.Runtime.Serialization

  • System.Runtime.Serialization.Formatters.Soap

  • System.ServiceModel

  • System.ServiceModel.Web

  • System.ServiceModel.Install

  • System.Transactions

  • System.Web.Services

Data Access



  • System.Data

  • System.Data.SqlXml

  • System.Data.DataSetExtensions

  • System.Data.Services.Client

Peer to Peer



  • System.Net

Active Directory and Enterprise Services



  • System.DirectoryServices

  • System.EnterpriseServices

The following assemblies are included in the beta release of the Client Profile but will be removed in the RTM release:



  • jsc

  • Microsoft.JScript

  • Microsoft.Vsa

  • System.DirectoryServices.Protocols

  • System.Management

  • System.Messaging

  • System.ServiceProcess

  • System.Web

  • System.Web.Extensions

  • System.Web.RegularExpressions

We’d love to hear your feedback on the list of assemblies in the Client Profile.  If your client app depends on an assembly that isn’t listed above, let us know.  I can’t guarantee that we’ll add the assembly to the Client Profile for RTM, but we’ll certainly consider it.  Keep in mind that the more assemblies we add, the more dependencies we may need to pull in, and the larger the package becomes.  This translates into longer download/install times and less reliable installs.  We’re aiming to keep the Client Profile as small as possible while still providing the right amount of functionality to satisfy the needs of most .NET client apps.


Targeting the .NET Framework Client Profile using Visual Studio 2008 SP1


Visual Studio 2008 SP1 adds a new feature in the project Properties for targeting the Client Profile.


Client-only Framework subset checkbox


After checking the “Client-only Framework subset” checkbox, Visual Studio will generate a warning if your project references an assembly that is not part of the Client Profile or an assembly that depends on an assembly that is not part of the Client Profile.


Warning


Things to be Aware of

Visual Studio 2008 SP1 Beta generates a warning when referencing assemblies that *are* in the Client Profile

Unfortunately the list of assemblies that Visual Studio 2008 SP1 Beta uses to generate warnings is out of sync with the actual assemblies that are included in the beta release of the Client Profile.  So you may find that Visual Studio will generate warnings when referencing some of the Client Profile assemblies listed above, even though the assemblies are included in the Client Profile.


To work around this in Visual Studio 2008 SP1 Beta, you can simply ignore the warnings for any assembly in the list above (your application should still compile).


Or, you can manually replace the Client.xml files that Visual Studio uses to target the Client Profile (do this at your own risk).  Here are some replacement Client.xml files that are based on the list of assemblies that will be in the RTM release of the Client Profile.


%windir%\Microsoft.NET\Framework\v2.0.50727\SubsetList\Client.xml

<?xml version=1.0 encoding=utf-8?>
<
FileList Redist=20ClientSubsetList>
<
File AssemblyName=Accessibility Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=caspol Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=X86 InGAC=false />
<
File AssemblyName=CustomMarshalers Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=X86 InGAC=true />
<
File AssemblyName=dfsvc Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=InstallUtil Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=X86 InGAC=false />
<
File AssemblyName=ISymWrapper Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=X86 InGAC=true />
<
File AssemblyName=Microsoft.VisualBasic Version=8.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=Microsoft.VisualC Version=8.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=mscorlib Version=2.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=X86 InGAC=true />
<
File AssemblyName=RegAsm Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=X86 InGAC=false />
<
File AssemblyName=sysglobl Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System Version=2.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Configuration Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Configuration.Install Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Data Version=2.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=X86 InGAC=true />
<
File AssemblyName=System.Data.SqlXml Version=2.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Deployment Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.DirectoryServices Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Drawing Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.EnterpriseServices Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=X86 InGAC=true />
<
File AssemblyName=System.Runtime.Remoting Version=2.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Runtime.Serialization.Formatters.Soap Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Security Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Transactions Version=2.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=X86 InGAC=true />
<
File AssemblyName=System.Web.Services Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Windows.Forms Version=2.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Xml Version=2.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
</
FileList>

%programfiles%\Reference Assemblies\Microsoft\Framework\v3.0\SubsetList\Client.xml

<?xml version=1.0 encoding=utf-8?>
<
FileList Redist=30ClientSubsetList>
<
File AssemblyName=PresentationCFFRasterizer Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=PresentationCore Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=X86 InGAC=true />
<
File AssemblyName=PresentationFramework Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=PresentationFramework.Aero Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=PresentationFramework.Classic Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=PresentationFramework.Luna Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=PresentationFramework.Royale Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=PresentationUI Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=ReachFramework Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=ServiceModelReg Version=3.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.IdentityModel Version=3.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.Printing Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=X86 InGAC=true />
<
File AssemblyName=System.Runtime.Serialization Version=3.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.ServiceModel Version=3.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.ServiceModel.Install Version=3.0.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=UIAutomationClient Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=UIAutomationClientsideProviders Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=UIAutomationProvider Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=UIAutomationTypes Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=WindowsBase Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=WindowsFormsIntegration Version=3.0.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
</
FileList>

%programfiles%\Reference Assemblies\Microsoft\Framework\v3.5\SubsetList\Client.xml

<?xml version=1.0 encoding=utf-8?>
<
FileList Redist=35ClientSubsetList>
<
File AssemblyName=System.Net Version=3.5.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Net Version=3.5.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.Core Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.Core Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Data.DataSetExtensions Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.Data.DataSetExtensions Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.AddIn Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.AddIn Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.AddIn.Contract Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.AddIn.Contract Version=2.0.0.0 PublicKeyToken=b03f5f7f11d50a3a Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=AddInUtil Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=AddInProcess Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=AddInProcess32 Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=X86 InGAC=false />
<
File AssemblyName=System.Xml.Linq Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.Xml.Linq Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.ServiceModel.Web Version=3.5.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.ServiceModel.Web Version=3.5.0.0 PublicKeyToken=31bf3856ad364e35 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Windows.Presentation Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Windows.Presentation Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
<
File AssemblyName=System.Data.Services.Client Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=true />
<
File AssemblyName=System.Data.Services.Client Version=3.5.0.0 PublicKeyToken=b77a5c561934e089 Culture=neutral ProcessorArchitecture=MSIL InGAC=false />
</
FileList>

Regardless of the workaround you choose, you should still test your application on a machine that only has the Client Profile installed to ensure your client app works correctly on the Client Profile.

Some APIs that exist in Client Profile assemblies are not supported

Some APIs that exist in Client Profile assemblies are not supported because we have chosen not to include the dependencies required for them to function properly.  For RTM, we’re planning to release some tools (such as an FxCop rule) to help prevent taking a dependency on these APIs when targeting the Client Profile.  And in future versions of the .NET Framework Client Profile, we may even remove these APIs altogether (possibly by moving them to other assemblies).  But until then, you should be aware of these APIs and be sure not to call them from your client app.


The following list of APIs are not supported on the Client Profile (even though they exist and are public).  Note: these may change slightly for RTM.


System.dll



  • System.CodeDom.* (all APIs in this namespace)

  • System.CodeDom.Compiler.* (all APIs in this namespace)

  • Microsoft.VisualBasic.VBCodeProvider

  • Microsoft.CSharp.CSharpCodeProvider

System.Runtime.Remoting.dll



  • System.Runtime.Remoting.Channels.Http.* (all APIs in this namespace)

  • System.Runtime.Remoting.Services.RemotingService

System.ServiceModel.dll



  • System.ServiceModel.Activation.* (all APIs in this namespace)

  • System.ServiceModel.ServiceHost

System.IdentityModel.dll



  • System.IdentityModel.Selectors.* (all APIs in this namespace)

System.Web.Services.dll



  • System.Web.Services.* (all APIs in this namespace)

  • System.Web.Services.Configuration.* (all APIs in this namespace)

  • System.Web.Services.Diagnostics.* (all APIs in this namespace)

  • System.Web.Services.Discovery.* (all APIs in this namespace)

  • System.Web.Services.Protocols.* (all APIs in this namespace)

Again, you should test any code that targets the Client Profile on a machine that only has the Client Profile installed to ensure it works correctly on the Client Profile.


Conclusion


The .NET Framework Client Profile should help significantly improve the experience of deploying .NET client applications on machines that do not already have the .NET Framework installed.  It has been designed to make it as easy as possible to deploy the smallest set of files necessary to run a typical .NET client application today.  Our hope is that your existing .NET client apps can be easily modified to target the Client Profile to take advantage of the improved deployment experience.  If you’re having any trouble targeting the Client Profile, or you feel it is missing a crucial assembly required for client scenarios, please let us know!


Update: Troy Martez, a Program Manager on the WPF team, has an excellent blog post Introducing the .NET Framework Client Profile with more info on the Client Profile.

Comments (71)

  1. Greg says:

    Thanks for this valuable post.  Overall the list looks very good.  However, we see two major missing areas that many clients may require:

    System.Management:

     Need ManagementObject-related classes.

     Interact with PnP devices, Xbox 360 controllers (for non-XNA apps), etc.

     Get system properties for client application configuration.

     Retrieved properties also used for licensing/activation.

     Retrieved properties also used in error reports.

     Is it possible to simply not support the parts that depend on Microsoft.JScript?

    System.CodeDom

    System.CodeDom.Compiler

    Microsoft.CSharp.CSharpCodeProvider:

     Used for client scripting using C#.

     How else should we do client-side scripting?

    PLEASE include these components in the RTM.  Bandwidth is always getting faster/cheaper and we aren’t looking forward to future confusion of numerous client profiles.  30MB is a very reasonable number for 2009.

    Thanks.

  2. We&#39;re very excited that we&#39;re improving the installation experience on machines without .Net

  3. Troy Martez says:

    Greg brings up some great feedback on the .NET Framework Client Profile. Thanks for that Greg!

  4. kiran says:

    +1 for including System.Management in the Client Profile

    We assumed that was already included.

  5. As I mentioned a few days ago , with .NET Framework 3.5 SP1 Beta we are taking some MAJOR steps toward

  6. James says:

    We use the xsd.exe tool to generate classes from our schema, and it generates the following for every class:

    [System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.1432")]

    Is that going to be a problem since System.CodeDom.Compiler is not allowed?

    Also, change the second instance of the following from v3.0 to v3.5:

    %programfiles%Reference AssembliesMicrosoftFrameworkv3.0SubsetListClient.xml

  7. Miral says:

    I’ve used Microsoft.JScript in a WPF client application — it’s a useful way of embedding a simple expression into a data binding (eg. "value of this property plus one").

    Could be replaced by an army of converters, I guess, but using an expression seems cleaner and more flexible.

    And +1 for runtime C# code compilation as well, for more complicated scripting.

  8. jb says:

    Why not publish the tool that you’re using to generate the dependencies and have a way for it to send you the report to you?

  9. mihailik says:

    XML serialization relies on CodeDom.

    Are you planning to reimplement XML serialization without CodeDom, or you are planning to break the code that uses XML serialization?

  10. BNC says:

    Hi … Is not System.IO a minimum requirement and supposed to be a part of the Framework Client Profile APIs ??

  11. John Green says:

    I don’t see any Workflow assemblies included in the list.

  12. Gary says:

    I’m currently looking at using the Smart Client Software Factory for the development of a client application. I’ve noticed the Application Blocks include a reference to System.Design which does not seem to be on your list.

    Is there any possibility of including this in the Client Profile?

  13. Jay says:

    It’s hard to pick a good subset that reamins understandable. Picking it by assembly and then breaking as few APIs as possible (generally by namespace) is a reasonable approach.

    WCF serialization is generally better than XmlSerializer, so I don’t miss that (none of my clients use it anymore).

    I currently use System.Management for PnP notifications when a drive is added, but I will probably swap to a native COM server with better functionality. It would be nice if there was a FileSystemWatcher-like class that informed me when drives (ahem, FileSystems) are mounted, but I doubt ReadDirectoryChanges gives you that…

    So most of my client work seems it would work, in some cases falling back to interop.

    We also have a  service that isn’t a ‘client app’, but works well with clients running on the same machine and reuses some of the code. Importantly, the setup is very similar currently.

    I’m trying to determine if this Client Profile would make it feasible to move my .Net 2.0 apps to 3.5. The concerns:

    1. SIZE.  Going from 22MB for dotnetfx20 to 26+MB for clientProfile35 (let’s call it that). Seems reasonable. Without the client profile, we have ruled .Net 3.0 or 3.5 (300MB, or even 80MB after elaborate workarounds) to be prohibitively large for web download of our relatively small apps, so you have our attention!

    2. CHANCE OF AVOIDING FX INSTALL. Vista has dotnetfx20 installed already, as do many (though not most) XP systems. So now we can in some (increasing) cases avoid an install completely. ClientProfile35 won’t be a default install anywhere for a while.

    3. NUMBER OF SETUP VARIATIONS REQUIRED. We currently have one prereq installer (dotnetfx20) for all systems, for both our server (90MB) and client (32MB) installs. It seems for this new ClientProfile35 we cannot install it on Vista (so we need the huge version of the redist still?), and our service needs the full 300MB install even on XP due to the API subset not covering our service needs.

    4. REGISTRY VERSION CHECKS (For non-client 3.5 apps). Assuming a system has only clientProfile35 installed, and NOT the full 3.5 framework, is there a simple regkey I can check to determine that the API is a subset of 3.5?  Otherwise how does my server installer know that it needs to run 3.5 install because the ClientProfile is not the ‘real’ framework it was depending on?

    5. REGISTRY VERSION CHECKS (Backward compat with apps expecting 2.0). My current software already tries to detect if dotnetfx20 is installed by checking for a v2.0 key. But now the clientProfile35 may show up on systems that my app is being installed on. Is your clientProfile35 going to set the regkey and thus look like it has the full 2.0 feature set, breaking my app with MissingMethods if it calls APIs that have been part of 2.0 for yers?

    I hope these scenarios have been considered and you have answers!

  14. I need at least the parts of System.CodeDom that are needed to support lightweight code gen, and would like to see it in the client profile.

  15. Ricky Supit says:

    System.Web.Caching is a very convenient library to have when implementing caching in your application (windows/asp.net). The library should not be under System.Web to begin with.  

    To me caching is very important when building any (decent) application. So for not being part of this would be a big lost.

  16. BCLTeam says:

    James,

    Thanks for the heads up on the GeneratedCodeAttribute.  This should still work on the Client even though the CodeDom APIs are unsupported.

    I’ve updated the v3.0 to v3.5, thanks for catching this!

    Thanks,

    Justin

  17. Dave R. says:

    This seems like a good idea considering the ever-expanding nature of the framework. However, the download size still seems quite excessive for those of us who do not use the 3.5 libraries, such as WCF, WPF and so on. Would it be possible to have an option to exclude the 3.5 ‘extras’ for those of us who are still programming against the ‘classic’ Windows Forms 2.0? I think there is a large audience out there who are in this situation and do not have need for the 3.5 facilities yet.

    Of course, the ideal would be the ability for the net bootstrapper to detect and download only the DLLs that your particular app needed to run ;)

  18. Justin Van Patten from the BCL Team has put out an official list of what assemblies will be included

  19. Daniel says:

    Here’s a vote for including System.ServiceProcess since we have a desktop app (with a very large user base) that needs a Windows Service.

  20. Justin Van Patten from the BCL Team has put out an official list of what assemblies will be included

  21. BCLTeam says:

    Greg and Miral,

    Languages that run on top of the Dynamic Language Runtime (DLR), such as IronPython, IronRuby, Managed JScript, etc., might make more sense than using CodeDom or Microsoft.JScript for client-side scripting.  But this is still good feedback.

    Thanks,

    Justin

  22. BCLTeam says:

    jb,

    Good idea.  We do have some internal dependency analysis tools that we can look into releasing publicly.

    Thanks,

    Justin

  23. BCLTeam says:

    mihailik,

    You’re right, XML serialization does rely on CodeDom.  We’re actually including only the necessary CodeDom dependencies to ensure XML serialization works correctly (namely, the C# compiler).  But we’re not including the full set of CodeDom dependencies.  Right now we’re not making any gaurantees that CodeDom will work on the Client Profile — but we *are* testing XML serialization, and you are safe to continue using it.

    In the future, we’re looking into implementing XML serialization on top of Reflection.Emit instead of CodeDom.  At that point we’ll likely remove the CodeDom APIs from the Client Profile altogether along with its dependencies (the C# compiler).  So you’re well advised not to take a dependency on they are unsupported and we reserve the right to remove them in future versions.

    In summary, it’s safe to use XML serialization on the Client Profile, but don’t use CodeDom because it is unsupported on its own.

    Some of the comments have mentioned that CodeDom may be useful to enable client-side scripting in .NET client apps, but languages that run on the Dynamic Language Runtime (DLR) such as IronPython, IronRuby, Managed JScript, etc., may actually be better for these scenarios.

    Thanks,

    Justin

  24. BCLTeam says:

    BNC,

    The System.IO APIs are in mscorlib and are supported on the Client Profile.

    Thanks,

    Justin

  25. BCLTeam says:

    John Green,

    We aren’t planning to include Workflow in the Client Profile at this time.  But thanks for the feedback.

    Thanks,

    Justin

  26. BCLTeam says:

    Gary,

    We don’t have any plans to include System.Design in the Client Profile.  This is actually a rather large assembly that’s mainly useful only at design time.

    Thanks for the info on the Smart Client Software Factory, though.  Perhaps it can be updated to remove the dependency on System.Design.  I’ll look into this.

    Thanks,

    Justin

  27. BCLTeam says:

    Jay,

    I recommend getting in touch with Troy Martez on his blog http://blogs.windowsclient.net/trickster92/

    He’s been leading the deployment efforts and should be able to answer your deployment-related questions.

    Thanks,

    Justin

  28. BCLTeam says:

    John Melville,

    Lightweight Code Gen doesn’t depend on System.CodeDom, so you should be fine (LCG depends on Reflection.Emit in mscorlib).

    Thanks,

    Justin

  29. BCLTeam says:

    Ricky Supit,

    We have no plans to include ASP.NET in the Client Profile, but your request for a general purpose caching API is a good one.  I agree that this is useful for client apps.  I’ll keep this on our radar as a potential area to factor out of System.Web so it can be used by client-side applications as well as by ASP.NET.  There are some other APIs that fall into this camp as well, such as System.Web.HttpUtility.

    Thanks,

    Justin

  30. BCLTeam says:

    Dave R.,

    Thanks for the feedback.  This is a good idea that we’re considering for the future to further help improve the deployment experience for client apps.

    Thanks,

    Justin

  31. BCLTeam says:

    Daniel,

    Thanks for the feedback.  We’ll consider adding support for System.ServiceProcess.

    Thanks,

    Justin

  32. I think that more important than what I/we would like to see in this Client Profile is that the team is thinking about it.

    The way some code is packaged, some times, looks more like it’s by team then by purpose or usage.

    The guys that do the web stuff are the ones that thought about caching, URL encoding/decoding, HTML encoding/deconding, HttpValueCollection and much more.

    I’ve used most of these in client applications and, although I could use the Caching Application Block from EntLib, most of the others would have to be reimplemented.

    By the requests, looks like we are looking at several levels of client profile (or several profiles). But, as I said before, for now, I’m happy for the awareness.

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

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

  35. Justin Van Patten colocou uma entrada no Blogue da Equipa da BCL acerca do .NET Framework Client Profile

  36. Greg says:

    Will the client Profile fully support the Dynamic Language Runtime (DLR) and languages such as IronPython, IronRuby, Managed JScript, or are additional language components/downloads required?

  37. BCLTeam says:

    The Client Profile does not include the DLR, but you should be able to use it on top of the Client Profile.

    Thanks,

    Justin

  38. Greg says:

    Justin,

    Thanks for the quick response.  If possible, could you please elaborate on how we could do scripting using the Common Profile.  It is not yet clear how the DLR, Microsoft.Scripting.dll, and JScript, Python, Ruby stuff will be distributed.  I know some of these assemblies are in the Silverlight betas and on CodePlex, but how will this move into .NET proper?  We firmly believe you need a real story for how to do client-side scripting using the Client Profile.  If that means waiting for this other work to wrap up, then perhaps the Client Profile should wait until the DLR and scripting support are ready for commercial deployment.  Or will this DLR-stuff never really move into .NET?  For the record, we (and our clients) would strongly prefer to write small scripts in C# (a very well-known and complete language) and just use the CodeDom to compile as needed.  Thanks.

  39. jinishans says:

    Excellent blog post. I’ve a reply in my blog here (http://jinishans.blogspot.com/2008/05/net-framework-client-profile.html) thanking the CLR team

  40. Gary says:

    Justin,

    Thanks for the previous reply.

    Using the Client Profile do you know if it will be possible to install SQL Server 2008 Express?

    I know SQL Server 2008 Express is currently a CTP release but when trying to install it where the Client Profile has been installed, the SQL Server 2008 Express install asks for .NET 2.0 to be installed.

  41. BCLTeam says:

    Greg,

    We hear you :-)… For now, as you mention, the DLR ships as part of the IronPython project on CodePlex as well as the IronRuby project on RubyForge.  You can download it and use it today in your client application.  In future versions of .NET, the DLR and dynamic languages will be more first class.

    Thanks,

    Justin

  42. BCLTeam says:

    Gary,

    SQL Server 2008 Express may depend on assemblies in .NET 2.0 that do no ship as part of the Client Profile.  So in order to use it, you’ll have to install the full .NET Framework.

    Do you use SQL Server 2008 Express in your client app?  Have you looked at SQL Server Compact 3.5 as an alternative?

    http://www.microsoft.com/sql/editions/compact/default.mspx

    SQL Server Compact 3.5 should work on top of the Client Profile.

    Thanks,

    Justin

  43. Gary says:

    Justin,

    Thanks for the quick reply. I did look at SQL Server Compact 3.5 but we need to provide a client application where the data can be shared between different users on the same network.

    If SQL Server 2008 Express could be installed using only the Client Profile this would provide us with the ideal solution. Otherwise we are in the position of needing to distribute the full .NET Framework and the associated issues with the size of the distributable.

    Thanks,

    Gary.

  44. Paul D says:

    Hi Justin,

    We can survive with most of what you have outlined, but our client relies on two components that it seems you are removing:

    1. System.Management, for monitoring memory and hard-drive usage.  I’ve noticed that a few people want this one…

    2. System.ServiceProcess.  We use this to control a windows service that runs along with our client.

    Perhaps there are unmanaged ways to do these things, but we would prefer to keep them in the framework.

  45. Hi,

    Curious – Since you won’t be including System.ServiceModel.ServiceHost API’s does that mean one would not be able to create a stand-alone peer-to-peer app using the WCF NetPeerTCP provider as a self-hosted service app?

    Thanks for the info,

    Roland Rodriguez

  46. This Week on Channel 9, Brian and Ed cover: – PDC Registration (0:22) – Improvements to MSDN and Technet

  47. Joel Lyons says:

    I’m surprised to see that you are not planning on supporting the types in System.Runtime.Remoting.Channels.Http which is where HttpClientChannel lives.  All of our client applications use HTTP remoting to talk to our servers and we love it!

    Am I missing something?

  48. The beta version of the .NET Framework 3.5 SP1 and Visual Studio 2008 SP1 were released a few weeks ago.

  49. Programming says:

    As I mentioned a few days ago , with .NET Framework 3.5 SP1 Beta we are taking some MAJOR steps toward

  50. Victor says:

    This is great stuff, please include System.Web in the RTM

  51. BCLTeam says:

    Joel,

    Thanks for pointing out HttpClientChannel.  The System.Runtime.Remoting.Channels.Http.* APIs that depend on System.Web are not supported.  HttpClientChannel does not depend on System.Web, so it should work.  We’ll have a much more granular list of unsupported APIs for RTM.

    Thanks,

    Justin

  52. BCLTeam says:

    Victor,

    We have no plans to include the ASP.NET in the Client Profile, so its unlikely that we will add System.Web.dll.  I’m curious, what functionality does your client app need from this assembly?

    We do realize there is some functionality provided in this assembly that may be useful to client apps, such as caching and HttpUtility.  We’ll be looking into ways to make this functionality available on the Client Profile in a future release.

    Thanks,

    Justin

  53. Channel 9 says:

    This Week on Channel 9, Brian and Ed cover:

  54. Angel Ochoa says:

    Why isn’t the System.Data.OracleClient supported ? Applications that connect to Oracle databases need it and is easier than to install the Oracle’s one.

  55. Vincent says:

    Our application uses MS Report Viewer for all reports. That’s local report, no web involvedd. Is it safe with this .Net Client Profile?

  56. Justin Van Patten from the BCL Team has put out an official list of what assemblies will be included in the RTM of the .NET Framework Client Profile. The usual suspects are there, and as expected, server-side technologies like ASP.NET are not. Note that

  57. As you know the .NET Framework 3.5 Service Pack 1 Beta download is now available. There are many improvements

  58. We just announced the release of Service Pack 1 for VS 2008 and .NET FX 3.5 . A major push for this release

  59. We just announced the release of Service Pack 1 for VS 2008 and .NET FX 3.5 . A major push for this release

  60. Geçtiğimiz Kasım ayında yayınlanan Visual Studio 2008 ve .NET Framework 3.5 için pek çok yenilik ve düzeltme

  61. .NET 3.5 SP1 buzz peaked very early at the beta.&#160; At the time I was immersed in Silverlight, so

  62. I was just reading an article in Application Development Trends, titled Microsoft Ships Visual Studio

  63. As I mentioned on the SP1 cheat sheet , client profile is an exciting new deployment feature in SP1..&#160;&#160;

  64. If you’re building something like a .NET WPF client application then one of the major bugbears (for both…

  65. SocialITy says:

    Jeżeli ktoś miałby wątpliwości, że lato to okres posuchy dla programistów, poniżej krótki spis istotnych

  66. Hírcsatorna says:

    A .NET 3.5 SP1 egyik legnagyobb dobása az ún. .NET Client Profile bevezetés, mely segítségével egy 26

  67. Elise's blog says:

    Avec la sortie du framework 3.5, Microsoft a annoncé le " .Net Client Profile ". Il s’agit d’une version

  68. Elise's blog says:

    Avec la sortie du framework 3.5 SP1 Beta, Microsoft avait annoncé le " .Net Client Profile ". Il s’agit

  69. Justin Van Patten colocou uma entrada no Blogue da Equipa da BCL acerca do .NET Framework Client Profile