.NET Framework Client Profile [Justin Van Patten]

Article
05/21/2008

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

Anonymous
May 21, 2008
PingBack from http://dogs-pets.info/dog-training/?p=983
Anonymous
May 21, 2008
The comment has been removed
Anonymous
May 21, 2008
We're very excited that we're improving the installation experience on machines without .Net
Anonymous
May 21, 2008
Greg brings up some great feedback on the .NET Framework Client Profile. Thanks for that Greg!
Anonymous
May 21, 2008
Introducingthe.NETFrameworkClientProfile http://blogs.windowsclient.net/trickster92/archive/20...
Anonymous
May 21, 2008
+1 for including System.Management in the Client Profile We assumed that was already included.
Anonymous
May 21, 2008
As I mentioned a few days ago , with .NET Framework 3.5 SP1 Beta we are taking some MAJOR steps toward
Anonymous
May 21, 2008
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
Anonymous
May 21, 2008
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.
Anonymous
May 21, 2008
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?
Anonymous
May 22, 2008
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?
Anonymous
May 22, 2008
Hi ... Is not System.IO a minimum requirement and supposed to be a part of the Framework Client Profile APIs ??
Anonymous
May 22, 2008
I don't see any Workflow assemblies included in the list.
Anonymous
May 22, 2008
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?
Anonymous
May 22, 2008
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:

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!
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.
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.
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?
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!

Anonymous
May 22, 2008
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.
Anonymous
May 22, 2008
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.
Anonymous
May 22, 2008
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
Anonymous
May 22, 2008
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 ;)
Anonymous
May 23, 2008
Justin Van Patten from the BCL Team has put out an official list of what assemblies will be included
Anonymous
May 23, 2008
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.
Anonymous
May 23, 2008
Justin Van Patten from the BCL Team has put out an official list of what assemblies will be included
Anonymous
May 23, 2008
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
Anonymous
May 23, 2008
jb, Good idea. We do have some internal dependency analysis tools that we can look into releasing publicly. Thanks, Justin
Anonymous
May 23, 2008
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
Anonymous
May 23, 2008
BNC, The System.IO APIs are in mscorlib and are supported on the Client Profile. Thanks, Justin
Anonymous
May 23, 2008
John Green, We aren't planning to include Workflow in the Client Profile at this time. But thanks for the feedback. Thanks, Justin
Anonymous
May 23, 2008
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
Anonymous
May 23, 2008
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
Anonymous
May 23, 2008
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
Anonymous
May 23, 2008
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
Anonymous
May 23, 2008
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
Anonymous
May 23, 2008
Daniel, Thanks for the feedback. We'll consider adding support for System.ServiceProcess. Thanks, Justin
Anonymous
May 26, 2008
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.
Anonymous
May 26, 2008
Justin Van Patten has posted on BCL Team Blog about the .NET Framework Client Profile . In this post
Anonymous
May 26, 2008
Justin Van Patten has posted on BCL Team Blog about the .NET Framework Client Profile . In this post
Anonymous
May 26, 2008
Justin Van Patten colocou uma entrada no Blogue da Equipa da BCL acerca do .NET Framework Client Profile
Anonymous
May 27, 2008
The comment has been removed
Anonymous
May 27, 2008
The Client Profile does not include the DLR, but you should be able to use it on top of the Client Profile. Thanks, Justin
Anonymous
May 27, 2008
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.
Anonymous
May 27, 2008
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
Anonymous
May 27, 2008
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.
Anonymous
May 27, 2008
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
Anonymous
May 27, 2008
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
Anonymous
May 27, 2008
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.
Anonymous
May 28, 2008
The comment has been removed
Anonymous
May 29, 2008
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
Anonymous
May 30, 2008
This Week on Channel 9, Brian and Ed cover: - PDC Registration (0:22) - Improvements to MSDN and Technet
Anonymous
May 30, 2008
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?
Anonymous
May 30, 2008
The beta version of the .NET Framework 3.5 SP1 and Visual Studio 2008 SP1 were released a few weeks ago.
Anonymous
May 31, 2008
As I mentioned a few days ago , with .NET Framework 3.5 SP1 Beta we are taking some MAJOR steps toward
Anonymous
June 01, 2008
This is great stuff, please include System.Web in the RTM
Anonymous
June 02, 2008
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
Anonymous
June 02, 2008
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
Anonymous
June 03, 2008
This Week on Channel 9, Brian and Ed cover:
Anonymous
June 10, 2008
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.
Anonymous
June 13, 2008
Our application uses MS Report Viewer for all reports. That's local report, no web involvedd. Is it safe with this .Net Client Profile?
Anonymous
June 28, 2008
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
Anonymous
August 12, 2008
As you know the .NET Framework 3.5 Service Pack 1 Beta download is now available. There are many improvements
Anonymous
August 13, 2008
We just announced the release of Service Pack 1 for VS 2008 and .NET FX 3.5 . A major push for this release
Anonymous
August 13, 2008
We just announced the release of Service Pack 1 for VS 2008 and .NET FX 3.5 . A major push for this release
Anonymous
August 13, 2008
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
Anonymous
August 14, 2008
.NET 3.5 SP1 buzz peaked very early at the beta.  At the time I was immersed in Silverlight, so
Anonymous
August 19, 2008
I was just reading an article in Application Development Trends, titled Microsoft Ships Visual Studio
Anonymous
August 20, 2008
The comment has been removed
Anonymous
August 26, 2008
If you're building something like a .NET WPF client application then one of the major bugbears (for both...
Anonymous
August 27, 2008
Jeżeli ktoś miałby wątpliwości, że lato to okres posuchy dla programistów, poniżej krótki spis istotnych
Anonymous
September 02, 2008
A .NET 3.5 SP1 egyik legnagyobb dobása az ún. .NET Client Profile bevezetés, mely segítségével egy 26
Anonymous
September 03, 2008
Avec la sortie du framework 3.5, Microsoft a annoncé le " .Net Client Profile ". Il s'agit d'une version
Anonymous
September 03, 2008
Avec la sortie du framework 3.5 SP1 Beta, Microsoft avait annoncé le " .Net Client Profile ". Il s'agit
Anonymous
May 26, 2009
Justin Van Patten colocou uma entrada no Blogue da Equipa da BCL acerca do .NET Framework Client Profile

Share via