.NET Framework Client Profile [Justin Van Patten]

Dog Training » .NET Framework Client Profile [Justin Van Patten]

Dog Training » .NET Framework Client Profile [Justin Van Patten] — Wed, 21 May 2008 20:03:10 GMT

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

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

Greg — Wed, 21 May 2008 20:26:23 GMT

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.

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

Rob Relyea - Xamlified — Wed, 21 May 2008 23:18:26 GMT

We're very excited that we're improving the installation experience on machines without .Net

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

Troy Martez — Wed, 21 May 2008 23:57:27 GMT

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

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

Warren Tang — Thu, 22 May 2008 04:09:46 GMT

Introducingthe.NETFrameworkClientProfile

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

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

kiran — Thu, 22 May 2008 07:39:03 GMT

+1 for including System.Management in the Client Profile

We assumed that was already included.

.NET Framework Client Profile

Brad Abrams — Thu, 22 May 2008 07:47:41 GMT

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

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

James — Thu, 22 May 2008 09:19:27 GMT

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

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

Miral — Thu, 22 May 2008 10:00:20 GMT

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.

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

jb — Thu, 22 May 2008 10:40:37 GMT

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?

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

mihailik — Thu, 22 May 2008 15:03:13 GMT

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?

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

BNC — Thu, 22 May 2008 15:39:04 GMT

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

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

John Green — Thu, 22 May 2008 16:29:48 GMT

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

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

Gary — Thu, 22 May 2008 16:38:12 GMT

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?

I don't envy you

Jay — Thu, 22 May 2008 17:00:42 GMT

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!

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

John Melville — Thu, 22 May 2008 18:05:50 GMT

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.

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

Ricky Supit — Thu, 22 May 2008 19:16:41 GMT

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.

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

BCLTeam — Thu, 22 May 2008 22:06:13 GMT

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

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

Dave R. — Fri, 23 May 2008 14:24:48 GMT

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

What's in the .NET Framework Client Profile?

POKE 53280,0: Pete Brown's Blog — Fri, 23 May 2008 16:50:03 GMT

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

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

Daniel — Fri, 23 May 2008 20:18:27 GMT

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.

What's in the .NET Framework Client Profile?

Community Blogs — Fri, 23 May 2008 23:40:12 GMT

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

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

BCLTeam — Sat, 24 May 2008 02:06:04 GMT

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

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

BCLTeam — Sat, 24 May 2008 02:07:22 GMT

jb,

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

Thanks,

Justin

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

BCLTeam — Sat, 24 May 2008 02:25:21 GMT

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

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

BCLTeam — Sat, 24 May 2008 02:26:13 GMT

BNC,

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

Thanks,

Justin

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

BCLTeam — Sat, 24 May 2008 02:27:07 GMT

John Green,

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

Thanks,

Justin

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

BCLTeam — Sat, 24 May 2008 02:29:41 GMT

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

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

BCLTeam — Sat, 24 May 2008 02:42:17 GMT

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

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

BCLTeam — Sat, 24 May 2008 02:44:19 GMT

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

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

BCLTeam — Sat, 24 May 2008 02:47:11 GMT

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

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

BCLTeam — Sat, 24 May 2008 02:49:16 GMT

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

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

BCLTeam — Sat, 24 May 2008 02:50:18 GMT

Daniel,

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

Thanks,

Justin

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

Paulo Morgado — Mon, 26 May 2008 18:37:21 GMT

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.

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

Paulo Morgado — Tue, 27 May 2008 02:24:27 GMT

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

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

Paulo Morgado — Tue, 27 May 2008 02:24:40 GMT

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

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

Paulo Morgado — Tue, 27 May 2008 02:57:32 GMT

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

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

Greg — Tue, 27 May 2008 18:24:41 GMT

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?

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

BCLTeam — Tue, 27 May 2008 20:17:42 GMT

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

Thanks,

Justin

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

Greg — Tue, 27 May 2008 23:36:23 GMT

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.

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

jinishans — Wed, 28 May 2008 00:46:01 GMT

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

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

Gary — Wed, 28 May 2008 11:44:05 GMT

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.

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

BCLTeam — Wed, 28 May 2008 12:11:57 GMT

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

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

BCLTeam — Wed, 28 May 2008 12:22:05 GMT

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

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

Gary — Wed, 28 May 2008 13:31:05 GMT

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.

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

Paul D — Thu, 29 May 2008 00:02:31 GMT

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.

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

Roland Rodriguez — Thu, 29 May 2008 23:12:42 GMT

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

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

ASP.NET on Channel9 — Fri, 30 May 2008 21:59:55 GMT

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

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

Joel Lyons — Fri, 30 May 2008 22:21:12 GMT

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?

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

Aaron Stebner's WebLog — Sat, 31 May 2008 04:26:44 GMT

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

.NET Framework Client Profile

Programming — Sat, 31 May 2008 17:36:36 GMT

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

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

Victor — Mon, 02 Jun 2008 05:12:42 GMT

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

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

BCLTeam — Tue, 03 Jun 2008 01:56:03 GMT

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

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

BCLTeam — Tue, 03 Jun 2008 01:59:13 GMT

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

Re: I'm inspired...

Channel 9 — Wed, 04 Jun 2008 07:37:13 GMT

This Week on Channel 9, Brian and Ed cover:

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

Angel Ochoa — Wed, 11 Jun 2008 01:21:07 GMT

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.

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

Vincent — Sat, 14 Jun 2008 01:59:55 GMT

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

What's in the .NET Framework Client Profile?

DEVELOPMENT SITE - NOT MY PUBLIC BLOG — Sun, 29 Jun 2008 07:01:56 GMT

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

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

WPF Performance — Wed, 13 Aug 2008 10:29:57 GMT

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!

(Semi) Official Developer Division Performance Engineering blog — Wed, 13 Aug 2008 23:01:32 GMT

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

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

No1 Microsoft Fan — Wed, 13 Aug 2008 23:21:48 GMT

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

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

Aldığım notlar: .NET, VS.NET ve IIS... — Thu, 14 Aug 2008 12:27:18 GMT

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

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

Jaime Rodriguez — Fri, 15 Aug 2008 10:42:25 GMT

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

What is Your Top Feature in .NET 3.5 SP1?

Out Of The Box — Tue, 19 Aug 2008 18:45:24 GMT

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

Client profile explained..

Jaime Rodriguez — Thu, 21 Aug 2008 07:15:21 GMT

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

The .NET Client Profile

Mike Taulty's Blog — Wed, 27 Aug 2008 01:49:10 GMT

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

W telegraficznym skrócie

SocialITy — Wed, 27 Aug 2008 15:35:53 GMT

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

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

Hírcsatorna — Wed, 03 Sep 2008 10:00:48 GMT

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

[.Net] Présentation du Client Profile

Elise's blog — Wed, 03 Sep 2008 15:37:59 GMT

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

[.Net] Présentation du Client Profile

Elise's blog — Wed, 03 Sep 2008 16:09:37 GMT

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

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

Paulo Morgado — Wed, 27 May 2009 06:04:28 GMT

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