.NET Framework Client Profile [Justin Van Patten]

.NET Framework Client Profile [Justin Van Patten]

  • Comments 71

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.

  • PingBack from http://dogs-pets.info/dog-training/?p=983

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

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

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

  • Introducingthe.NETFrameworkClientProfile

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

  • +1 for including System.Management in the Client Profile

    We assumed that was already included.

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

  • 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

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

  • 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?

  • 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?

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

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

  • 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?

  • 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!

Page 1 of 5 (71 items) 12345