Welcome to MSDN Blogs Sign in | Join | Help

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

Published Wednesday, May 21, 2008 8:00 AM by BCLTeam
Filed under: ,

Comments

# Dog Training &raquo; .NET Framework Client Profile [Justin Van Patten]

Wednesday, May 21, 2008 1:26 PM by Greg

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Wednesday, May 21, 2008 4:18 PM by Rob Relyea - Xamlified

# .NET Framework Client Profile - improving setup experiences for WPF or WinForms Applications

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

Wednesday, May 21, 2008 4:57 PM by Troy Martez

# re: .NET Framework Client Profile [Justin Van Patten]

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

Wednesday, May 21, 2008 9:09 PM by Warren Tang

# .NET Framework Client Profile - a Subset of the .NET Framework Redistribution

Introducingthe.NETFrameworkClientProfile

http://blogs.windowsclient.net/trickster92/archive/20...

Thursday, May 22, 2008 12:39 AM by kiran

# re: .NET Framework Client Profile [Justin Van Patten]

+1 for including System.Management in the Client Profile

We assumed that was already included.

Thursday, May 22, 2008 12:47 AM by Brad Abrams

# .NET Framework Client Profile

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

Thursday, May 22, 2008 2:19 AM by James

# re: .NET Framework Client Profile [Justin Van Patten]

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 Assemblies\Microsoft\Framework\v3.0\SubsetList\Client.xml

Thursday, May 22, 2008 3:00 AM by Miral

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Thursday, May 22, 2008 3:40 AM by jb

# re: .NET Framework Client Profile [Justin Van Patten]

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?

Thursday, May 22, 2008 8:03 AM by mihailik

# re: .NET Framework Client Profile [Justin Van Patten]

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?

Thursday, May 22, 2008 8:39 AM by BNC

# re: .NET Framework Client Profile [Justin Van Patten]

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

Thursday, May 22, 2008 9:29 AM by John Green

# re: .NET Framework Client Profile [Justin Van Patten]

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

Thursday, May 22, 2008 9:38 AM by Gary

# re: .NET Framework Client Profile [Justin Van Patten]

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?

Thursday, May 22, 2008 10:00 AM by Jay

# I don't envy you

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!

Thursday, May 22, 2008 11:05 AM by John Melville

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Thursday, May 22, 2008 12:16 PM by Ricky Supit

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Thursday, May 22, 2008 3:06 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Friday, May 23, 2008 7:24 AM by Dave R.

# re: .NET Framework Client Profile [Justin Van Patten]

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 ;)

Friday, May 23, 2008 9:50 AM by POKE 53280,0: Pete Brown's Blog

# What's in the .NET Framework Client Profile?

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

Friday, May 23, 2008 1:18 PM by Daniel

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Friday, May 23, 2008 4:40 PM by Community Blogs

# What's in the .NET Framework Client Profile?

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

Friday, May 23, 2008 7:06 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Friday, May 23, 2008 7:07 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

jb,

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

Thanks,

Justin

Friday, May 23, 2008 7:25 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Friday, May 23, 2008 7:26 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

BNC,

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

Thanks,

Justin

Friday, May 23, 2008 7:27 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

John Green,

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

Thanks,

Justin

Friday, May 23, 2008 7:29 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Friday, May 23, 2008 7:42 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Friday, May 23, 2008 7:44 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Friday, May 23, 2008 7:47 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Friday, May 23, 2008 7:49 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Friday, May 23, 2008 7:50 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

Daniel,

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

Thanks,

Justin

Monday, May 26, 2008 11:37 AM by Paulo Morgado

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Monday, May 26, 2008 7:24 PM by Paulo Morgado

# .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

Monday, May 26, 2008 7:24 PM by Paulo Morgado

# .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

Monday, May 26, 2008 7:57 PM by Paulo Morgado

# .NET Framework Client Profile - O Que É Que Vai Lá Estar?

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

Tuesday, May 27, 2008 11:24 AM by Greg

# re: .NET Framework Client Profile [Justin Van Patten]

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?

Tuesday, May 27, 2008 1:17 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Thanks,

Justin

Tuesday, May 27, 2008 4:36 PM by Greg

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Tuesday, May 27, 2008 5:46 PM by jinishans

# re: .NET Framework Client Profile [Justin Van Patten]

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

Wednesday, May 28, 2008 4:44 AM by Gary

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Wednesday, May 28, 2008 5:11 AM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Wednesday, May 28, 2008 5:22 AM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Wednesday, May 28, 2008 6:31 AM by Gary

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Wednesday, May 28, 2008 5:02 PM by Paul D

# re: .NET Framework Client Profile - two components we would like to stay

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.

Thursday, May 29, 2008 4:12 PM by Roland Rodriguez

# re: .NET Framework Client Profile [Justin Van Patten]

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

Friday, May 30, 2008 2:59 PM by ASP.NET on Channel9

# This Week on Channel 9: PDC, Pex, Build Bunnies, UltraCam, Live Agents SDK

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

Friday, May 30, 2008 3:21 PM by Joel Lyons

# re: .NET Framework Client Profile [Justin Van Patten]

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?

Friday, May 30, 2008 9:26 PM by Aaron Stebner's WebLog

# Links to more detailed information about the .NET Framework 3.5 client profile

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

Saturday, May 31, 2008 10:36 AM by Programming

# .NET Framework Client Profile

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

Sunday, June 01, 2008 10:12 PM by Victor

# re: .NET Framework Client Profile [Justin Van Patten]

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

Monday, June 02, 2008 6:56 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Monday, June 02, 2008 6:59 PM by BCLTeam

# re: .NET Framework Client Profile [Justin Van Patten]

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

Wednesday, June 04, 2008 12:37 AM by Channel 9

# Re: I'm inspired...

This Week on Channel 9, Brian and Ed cover:

Tuesday, June 10, 2008 6:21 PM by Angel Ochoa

# re: .NET Framework Client Profile [Justin Van Patten]

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.

Friday, June 13, 2008 6:59 PM by Vincent

# Is it safe to run report viewer on .Net Client Profile

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

Sunday, June 29, 2008 12:01 AM by DEVELOPMENT SITE - NOT MY PUBLIC BLOG

# What's in the .NET Framework Client Profile?

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

Wednesday, August 13, 2008 3:29 AM by WPF Performance

# What’s New for Performance in WPF in .Net 3.5 SP1

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

# Service Pack 1 for VS 2008 and .NET FX 3.5 released!

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

Wednesday, August 13, 2008 4:21 PM by No1 Microsoft Fan

# Service Pack 1 for VS 2008 and .NET FX 3.5 released!

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

Thursday, August 14, 2008 5:27 AM by Aldığım notlar: .NET, VS.NET ve IIS...

# Visual Studio 2008 ve .NET Framework 3.5 için Service Pack 1 yayınlandı

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

Friday, August 15, 2008 3:42 AM by Jaime Rodriguez

# cheat-sheet to some of the WPF 3.5 SP1 features..

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

Tuesday, August 19, 2008 11:45 AM by Out Of The Box

# What is Your Top Feature in .NET 3.5 SP1?

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

Thursday, August 21, 2008 12:15 AM by Jaime Rodriguez

# Client profile explained..

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

Tuesday, August 26, 2008 6:49 PM by Mike Taulty's Blog

# The .NET Client Profile

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

Wednesday, August 27, 2008 8:35 AM by SocialITy

# W telegraficznym skrócie

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

Wednesday, September 03, 2008 3:00 AM by Hírcsatorna

# Mi van pontosan a .NET FW Client Profile-ban?

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

Wednesday, September 03, 2008 8:37 AM by Elise's blog

# [.Net] Présentation du Client Profile

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

Wednesday, September 03, 2008 9:09 AM by Elise's blog

# [.Net] Présentation du Client Profile

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

Tuesday, May 26, 2009 11:04 PM by Paulo Morgado

# .NET Framework Client Profile - O Que &#201; Que Vai L&#225; Estar?

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

New Comments to this post are disabled
 
Page view tracker