This article is more than 1 year old
'Milestone' Microsoft service pack staples .NET's stomach
Can its willpower hold?
SP1 certainly offers a radical diet for .NET's weight problem: it introduces the .NET Framework Client Profile for client-side applications. The Profile cuts by 85 per cent the amount of code you'll need to run a Windows Vista-looking application on a machine that can only stretch to Windows XP. It's designed to improve download and start-up times.
SP 1 comes less than a year after the launch of Visual Studio 2008 and .NET Framework 3.5. It has been released, though, as further evidence has emerged that Microsoft is concerned over the number of .NET Framework libraries, as product groups converge on a single framework.
SD Times claims to have seen a Microsoft memo that pointed to the Windows Communication Foundation (WCF), Windows Presentation Foundation (WPF) and ADO.NET entity framework as particular causes for concern. Tellingly, the .NET Framework Client Profile includes the WPF and WCF.
The report follows our own recent conversation with the general manager for Microsoft's presentation platforms and tools team Ian Ellison-Taylor, who said on the client: ".NET got a little big - it was a victim of its own success"
Are deployment-specific "profiles" the answer to a complicated problem?
The client profile is intended to help regain some focus and bring some Windows Vista like look-and-feel and functionality to Windows XP machines. If, though, more profiles are planned, then Microsoft risks going in the opposite direction - away from convergence on a single development framework and into fragmentation as more forks and features are included.
The challenge would then be to coordinate the core .NET Framework and profiles at a product-engineering level and at a meta framework level. Does Microsoft, or any large software company or project, have that discipline?
There's also a hidden problem for those building .NET applications. Already, a lot of people are angry at the fact they have to download different version numbers of the .NET Framework on their machines to build and test applications. Imagine how messy it could get in a world of multiple profiles, all of them running different version numbers.
Ultimately, the big question is whether the profile approach is a long-term weight loss strategy for the .NET Framework. We've heard Microsoft's plan for the next big release of Visual Studio - version 10 - is for a "stripped down" suite, although the company has not provided more information.
Profiles could be a part of that plan, with profiles plugging into the suite instead of Microsoft delivering a one-size fits all development environment. This could be a good move.
Or profiles could be a tactical answer to simply getting more people using Windows Vista and driving uptake of Visual Studio 2008. This would be a bad move. It would suggest there's no long-term commitment, and would swap the problem of bloat for islands of development profiles that have no real future, and further complicate the development and deployment landscape.®