Pasted from <http://silverlight.net/forums/p/60423/151129.aspx>

Extracted from SDK regarding to entry of GridLength:

XAML Values

doubleValue
The row’s height, or column’s width, expressed as a floating-point value for a pixel count. Typically this is specified as an integer, although interpolation of floating-point values is supported by grid layout.

starSizing
A convention by which you can size rows or columns to take the remaining available space in a Grid. A star sizing always includes the asterisk character (*), and optionally precedes the asterisk with an integer value that specifies a weighted factor versus other possible star sizings (for example, 3*). The cell size is a percentage of the remaining size of its content. The remaining size is the size of the grid, minus the fixed and auto size. This remaining size is divided in the * rows or columns, proportionaly of the values before.

Auto
The column’s width, or the row’s height, described by the literal Auto. The cell size is the size of its content.

Building on the vision of software + services, Microsoft Code Name “Acropolis” makes it easier to build and manage modular, business-focused, client applications for Microsoft Windows on the .NET Framework. It builds on the rich capabilities of Windows and the .NET Framework, including Windows Presentation Foundation (WPF), by providing tools and pre-built components that help developers quickly assemble an application from loosely-coupled parts and services. Code Name “Acropolis” reduces the complexities of building occasionally connected client applications and provides the ability to assemble and reconfigure systems without having to write a lot of code. Code Name “Acropolis” is part of the .NET Client Futures release, Microsoft’s preview of upcoming technologies in Windows client development.

For more information about Code Name “Acropolis” and the .NET Client Futures, see Windowsclient.net.

References:

http://www.rollthunder.com/Newsletter/newslv9n1.htm
http://blogs.msdn.com/ashish/archive/2007/06/07/wpf-cab-has-arrived.aspx
http://blogs.msdn.com/gblock/archive/2007/06/06/acropolis-the-future-of-smart-client.aspx

The information below was extracted from the write-up by Francis K. Cheung.

What are modular, composible applications?

Imagine that you want to need to build an application that, due to its size and complexity, needs to be split up and developed by several teams. Let’s say you have several teams developing modules that can be assembled at run time. There will also be a team in charge of the shared infrastructure. You also need a way for the UI elements from each module to be brought together into a reasonable composite. You also want the modules to be loosely coupled from eachother (no static references). You also want a way for these modules to communicate with eachother. Since there are no static references, you can’t take advantage of standard .NET eventing. You also want to expose services and share them across modules.

This scenario was first addressed by the Composite UI Application Block (CAB) and the Smart Client Software Factory. This scenario was then addressed for Windows Mobile 5: Mobile Client Software Factory. For the composible applications in the web space, the Web Client Software Factory was developed.

The demand for CAB functionality interoperable with WPF’s look and feel prompted the community project WPF CAB.

The Composite Application Guidance for WPF can help you split the development of your WPF client application across multiple development teams, each responsible for the development of a piece of the application, and help you seamlessly compose those pieces together into a client application.

I have done some search on choosing between SCSF (Smart Client Software Factory) and Composite WPF. If using SCSF, you are still able to host WPF SmartParts and develop WPF controls. If you are an existing CAB/SCSF developers, download the reference document at here. The following information was pasted from here:

#1: What should I use when starting a new project?

My personal conclusion: For me that question is obvious: use Composite WPF guidance and WPF if your client-hardware is sufficient for WPF.

WPF adds a lot value that make things for development of enterprise line-of-business client apps much easier - although the design time experience isn’t where it should be, today. And Composite WPF brings you the framework for building extensible and manageable enterprise-level smart clients with WPF! So just use it!

#2: Should you migrate to Composite WPF from CAB/SCSF?

Of course many customers are asking this question right now. They are afraid that they are using an old technology which is not going to be state-of-the-art anymore and running into panic-mode.

Well, I don’t see it that critical. CAB/SCSF is still driven forward by the community (see SCSFContrib, SCSFWPF etc.) and there are lots of people out there answering questions, sharing experience etc. Furthermore according to the Microsoft homepage it is still supported the same way it was supported all the time: it is simply treated as custom code in support cases with Microsoft.

My personal conclusion therefore: if you do not get additional business value out of Composite WPF and if you are happy with CAB/SCSF in your solution, why should you take the effort of migrating to it!? Then you don’t need to… some good reasons to migrate might be:

• native WPF implementation that leverages the base classes of WPF such as its existing command mechanisms etc.
• more lightweight - Composite WPF is more lightweight than CAB/SCSF and I had the feeling that it is easier to learn…
• extended flexibility of Composite WPF: you have the choice which features you want to use and which you don’t want to. Composite WPF features are independent from others - e.g. you could use the MVP/MVC implementation without being bound to any “Controller” or “WorkItem” base classes or to the dependency injection mechanisms.
• the new Unity framework as an easier-to-use, more lightweight dependency injection framework
• the ability of Composite WPF to use another dependency injection framework such as spring etc.

But these are just some thoughts that went through my head. And again - for me important is that if you don’t get any value for YOU out of these advantages then why migrate!? There is no reason for doing so. If you get additional value, then let’s go;)

#3: How do components from CAB/SCSF map to Composite WPF?

As far as I have seen, the Composite WPF framework achieves exactly the same goals as CAB on it’s own. There is no replacement for SCSF available, so far, and according to Microsoft none is planned for the foreseeable future. The team is in a kind-of gathering customer feedback loop right now;) Okay, but let’s map some features from CAB/SCSF to Composite WPF - I assume that you read my paper on CAB/SCSF to fully understand the following table…

As you can see, Composite WPF supports all scenarios but leaves you more “freedom” of whether you want to implement a scenario or not. And also if you implement a scenario you often don’t need to inherit from any base class or apply attributes in most cases. That means you can build-up your own hierarchies without running into too many dependencies of the Composite WPF guidance.

#4: The very basic steps to get from CAB/SCSF to Prism

These are some of the first steps I had to complete while migrating the shell and modules from CAB/SCSF to prism. Essentially these where the following:

1. Create a new solution for the Composite WPF version of my demo.
2. Import the interface libraries from the CAB/SCSF solution to the Composite WPF solution and remove all namespace-, attribute- and base-class references to CAB/SCSF-related classes.
3. Re-create the shell as described in the guidance: I have to admit I didn’t even try to migrate the shell because many of the concepts are different. But I left my IShellExtensionService interface concept and therefore I was able to hide this pretty heavy change from the modules I migrated later on.
4. Add a new class library with some of my own base classes:
   (1) A Controller base class with a state-bag to replace WorkItems. This is a simple as possible and I just used it because I used the WorkItem.State property. (2) A presenter base class with a reference to the original work item.
5. Add the first CAB/SCSF module to my new solution.
6. Replace the “ModuleInit” class by a IModule implementation. I even left the ModuleController-concept for simplicity.
7. Remove the WorkItemController base class reference in my ModuleController class and replace it by the Controller-base class I created in step 4.1 above.
8. Replace CAB-Commands [CommandHandler] by DelegateCommands as used in WPF and WPF composite guidance.
9. Replace all WorkItem.Service usages against a Unity Container Service usage.
10. UI Extension Site usage must be replaced by my IShellExtensionService concepts as described in my paper as they are not available anymore. Or you create your own IShellService that supports extension of menus etc. in your shell.
11. Uncomment CAB/SCSF generated code in the code-besides of the smart parts.
12. Remove all attributes in Presenter classes and SmartParts which are specific to CAB/SCSF.
13. Replace all WorkItem classes with your own, custom Controller classes that inherit from the Controller-base class I’ve created in step 4.
14. Update the configuration and run the application

In a nutshell, WPF a.k.a. Windows Presentation Framework provides the foundation for building applications and high fidelity experiences in Windows Vista, blending together application UI, documents, and media content, while exploiting the full power of your computer (WPF MSDN, 2008).

If you have never seen any WPF application before, look for sample applications at here. If you are a developer or a designer, I can assure that you will be WOW after seeing the nice UI and probably consider building an application like those. Therefore, in the remaining post, I will only discuss about how to get started and the REAL world practice. Well…if you need an introduction or walkthrough on what is WPF, download the presentation slide at here.

To GET STARTED, Microsoft provides a all-you-want-to-know site named WindowsClient.Net. On the other hand, to get started in Silverlight, the site you must refer to is Silverlight.Net. First of all, download all the essential tools such as Visual Studio 2008 and Expression Studio.

LEARN FROM EXPERIENCE. Frankly speaking, when I was ready to learn WPF and Silverlight, I had skipped reading up those “how to develop a Hello World” tutorials. What I did is download some sample projects with source code, run it and study it.

If you are going to develop a commercial or enterprise application, do refer to Composite Application Guidance for WPF by patterns & practices Developer center. You may download the Composite Application Guidance package that consists of a sample application source code and documentation. Refer to this guide is very useful, as I’m using it too for my projects.

Last but not least, a few must-explore-into tools are WPF Application Quality Guide and Performance Profiling Tools. The WPF Application Quality Guide provides guidance for improving the testability of WPF applications; Performance Profiling Tools allow you to analyze WPF application run time behavior and potential performance bottlenecks.