Development World

New Development Technologies , Computer Last News , Tips & Tricks , UI , CSS , HTML , ASP , C# , .net Framework , Patterns & Practices & etc

How can I Debug WPF Bindings

How can I debug WPF bindings?

Data Binding can be tricky to debug. In this post, I will share the techniques I use to debug WPF bindings, including the new debugging improvements we implemented in the latest 3.5 release. I will discuss the following four techniques:

  • Scanning Visual Studio’s Output window for errors.
  • Using Trace Sources for maximum control.
  • Using the new property introduced in WPF 3.5 PresentationTraceSources.TraceLevel.
  • Adding a breakpoint to a Converter.

The DataContext of this app is set to a new instance of Star, which is a class that contains two properties: Picture and Caption. Picture is of type BitmapImage and contains an image of the sun, which I included in the project. Caption is a string property that takes a while to be initialized (more details about this later).

Output Window

In the XAML of this application, I have an Image whose Source is data bound to an incorrect property name. This is a simple scenario that causes a Binding to fail.

    <Image Source="{Binding Path=PictureWrong}" Width="300" Height="300" Grid.Row="0"/>

Every time a Binding fails, the binding engine prints an informative message in the Output window of Visual Studio. In this case, I get the following message:

    System.Windows.Data Error: 35 : BindingExpression path error: ‘PictureWrong’ property not found on ‘object’ ”Star’ (HashCode=49535530)’. BindingExpression:Path=PictureWrong; DataItem=’Star’ (HashCode=49535530); target element is ‘Image’ (Name=”); target property is ‘Source’ (type ‘ImageSource’)

This message should give you enough information to quickly figure out the mistake in the property name.

Advantage of this technique:

  • It is very easy to look at the Output window, and in most cases it’s sufficient. It should be the first approach you consider when you have a problem with your bindings.

Disadvantage of this technique:

  • Most real world applications print so much information to the Output window that it may be hard to find the error you’re looking for.

Trace Sources

The Trace Sources solution was already around in WPF 3.0. It adds a lot more flexibility to the previous solution by allowing you to control the level of detail you care about, where you want that messages to be printed and the WPF feature you want to debug.

The Trace Sources solution relies on a config file for the configuration of its behavior - the App.config file. Here is a portion of the contents of that file:

    <configuration>
         <system.diagnostics>
            <sources>
    
            <source name="System.Windows.Data" switchName="SourceSwitch" >
                <listeners>
                    <add name="textListener" />
                </listeners>
            </source>
            …
        
            <switches>
                …
                <add name="SourceSwitch" value="All" />
            </switches>
        
            <sharedListeners>
                …
                <add name="textListener"
                type="System.Diagnostics.TextWriterTraceListener"
                initializeData="DebugTrace.txt" />
                …
            </sharedListeners>
        
            <trace autoflush="true" indentsize="4"></trace>
        
        </system.diagnostics>
    </configuration>

In this file, I am specifying that:

  • I want only messages generated in the Data subarea to be printed. If you’re trying to debug, for example, animations, you would instead add the area System.Windows.Media.Animation.
  • I want as much information as possible about data binding. This was done by setting the switch to All. Other possible values are Off, Error, Warning. For a complete list, look up SourceLevels in .NET Reflector.
  • I want the messages to be printed to an external file called DebugTrace.txt, instead of the Output Window. This file will be created in the bin\debug folder for the application. If you run this application twice, the messages generated the second time will be appended to the existing messages in this file. If you don’t want this behavior, remember to delete the file before running the app.

Other pre-defined listeners allow printing to the Console (ConsoleTraceListener), or to an external file in XML format (XmlWriterTraceListener).

If you run the application with the settings above, you should find a DebugTrace.txt file in the bin\debug directory. If you open it, you will see the data binding error we saw previously in the Output Window, plus four “Information” messages. These lower-priority messages are printed because I specified in the switch that I want all the information available about the bindings.

If you want to learn more about this topic, I recommend Mike Hillberg’s blog. He wrote the best article I’ve read about Trace Sources, which I use frequently as a reference.

Advantages of this technique:

  • It separates the debug messages you care about from the rest of the information printed in the Output window.
  • This solution may help you debug other areas in WPF, not just binding.
  • You can get lower-priority messages (such as information or warnings) that are not typically printed to the Output window.

Disadvantages of this technique:

  • The text file (or whatever form of output you choose) will contain debug messages about all the bindings in your application. Although this is not as much clutter as the Output window, it may still require some digging for you to find exactly the information you need.
  • It won’t help you in scenarios where your Binding actually succeeds, but you still don’t see what you expect in the UI. The first and second techniques I show here only help in scenarios where the Binding fails.

Before you move on, make sure you correct the Path in the Image’s Source so that these errors won’t interfere with the ones I show next.

Trace Level - new in 3.5

In order to understand this feature, let’s start by uncommenting the first TextBlock in the XAML of this application:

    <TextBlock Text="{Binding Path=Caption}" … />

This TextBlock attempts to bind to Caption, a property whose value is slow to be initialized. In this case, I am simulating a slow data source by adding a Dispatcher timer to the constructor, but in reality this delay could have many different causes. Notice also that I am *not* raising a property changed notification when Caption changes value.

    public string Caption
    {
        private set
        {
            this.caption= value;
            //OnPropertyChanged("Caption");
        }
        get
        {
            return caption;
        }
    }
    
    public Star()
    {
        this.Picture = new BitmapImage(new Uri("Images\\sun.jpg", UriKind.Relative));
        this.Caption = String.Empty;
        DispatcherTimer timer = new DispatcherTimer();
        timer.Interval = new TimeSpan(0, 0, 3);
        timer.Tick += new EventHandler(Timer_Tick);
        timer.Start();
    }
    
    private void Timer_Tick(object sender, EventArgs e)
    {
        this.Caption = "Sun";
    }

In this scenario, the Binding will succeed (it will bind to the initial value of empty string), but you don’t see what you expect to see in the UI. The unwanted behavior is caused by the fact that the events happen in an order different from what you expect: the Binding will be evaluated before Caption gets its real value. In this case, there are no errors in the Output window or DebugTrace.txt because the Binding succeeds.

You can use the new debugging feature in 3.5 to debug this scenario by adding the attached property PresentationTraceSources.TraceLevel to the Binding, which can be set to None, Low, Medium and High. Since PresentationTraceSource is not in the default namespace mappings for WPF, you will have to write the following XAML:

    <Window …
    xmlns:diagnostics="clr-namespace:System.Diagnostics;assembly=WindowsBase"
    />
    
    <TextBlock Text="{Binding Path=Caption, diagnostics:PresentationTraceSources.TraceLevel=High}" … />

If you look at the Output window, you will notice that the binding engine generated debug information for every task that may help users find problems with this particular binding:

    System.Windows.Data Warning: 47 : Created BindingExpression (hash=25209742) for Binding (hash=3888474)
    …
    System.Windows.Data Warning: 91 : BindingExpression (hash=25209742): GetValue at level 0 from Star (hash=31609076) using RuntimePropertyInfo(Caption): ‘ ‘
    System.Windows.Data Warning: 71 : BindingExpression (hash=25209742): TransferValue - got raw value ‘ ‘
    System.Windows.Data Warning: 78 : BindingExpression (hash=25209742): TransferValue - using final value ‘ ‘

In this case, we can scan the debug messages quickly to see that there were no errors, and look at the last few messages to understand that the value found at the Source was the empty string. This information will help you come to the conclusion that there is some timing issue with the scenario.

Advantages of this technique:

  • This feature is particularly useful when you know exactly which binding you want to find out more about, which is the most common scenario.
  • It allows you to know more about bindings that succeed, which many times helps you find the mistake in your logic.

Disadvantages of this technique:

  • If you forget to remove the property after you found the problem, it adds to the clutter of the Output Window (which adds to the time it takes to start your application in debug mode).

Converter

The last solution is extremely simple: you can simply add a no-op Converter to your binding and put a breakpoint in its Convert method. This is what this solution looks like:

    <TextBlock Text="{Binding Path=Caption, Converter={StaticResource converter}}" …/>

    public class DebuggingConverter : IValueConverter
    {
        public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            return value; // Add the breakpoint here!!
        }

        public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            throw new NotImplementedException("This method should never be called");
        }
    }

If you run this code and set a breakpoint inside the Convert method, you can simply hover over the “value” parameter to see what is being passed from the source to the target. In this case, you will see that “value” contains an empty string. This may help you realize that the source of your binding does not have the value you thought it had.

Advantages of this technique:

  • It is really easy to implement. It relies on a concept that most data binding users are familiar with.
  • It does not depend on the Output window.
  • It helps you find out more about scenarios where the binding doesn’t fail.

Disadvantages to this technique:

  • It doesn’t provide as much information as the TraceLevel technique.
  • If the Binding fails early, the Converter may not be called.

Conclusion

I mentioned here techniques to debug WPF bindings using Visual Studio, however there are other tools that can help you with this process. One other tool I use frequently is Snoop, not only to debug bindings but many other aspects of my application. Mole is also useful, and has great documentation.

What technique or tool you use to debug your bindings comes down to a combination of personal preference and your specific scenario.

Here you can find the project with this code built using VS 2008 RTM.

Reference

http://www.beacosta.com/blog/?p=52
نویسنده : Nasser Hajloo : ۱۱:۱٤ ‎ق.ظ ; ۱۳۸٧/۱/٢٤
Comments پيام هاي ديگران ()      لینک دائم

WCSF - Web Client Service Factory

 Summary

The Web Service Software Factory (also known as the Service Factory) is an integrated collection of tools, patterns, source code and prescriptive guidance. It is designed to help you quickly and consistently construct WCF and ASMX Web services that adhere to well known architecture and design patterns.

wcsf-Intro-scope.png


The Web Client Software Factory (WCSF) provides a set of guidance for architects and developers building enterprise Web applications. The factory includes samples, reusable code and a guidance package which automates key development tasks from within Visual Studio.

Using the Web Client Software Factory assets, developers can create Composite Web applications composed of independently developed and deployed modules. These modules are dynamically brought together at runtime into a common shell. Additionally the factory includes support for ASP.NET AJAX thus providing users with a richer and more responsive user experience.

The Web Client Software Factory provides proven solutions to common challenges found while building and operating large transaction processing enterprise Web sites. It helps architects and developers build modular systems. A module is a functionally complete and independent component. Modularity allows independent teams to work on different aspects of the application and also improves security and testability. Applications built with the software factory use proven practices for operations like centralized exception logging and can be XCopy deployed.

deduction

Architects and developers can use the Web Client Software Factory to quickly incorporate many of the proven practices and patterns of building Web client applications. These practices and patterns have been identified during the development of many Web client applications and their components.

These applications have one or more of the following characteristics:

  • They are developed by multiple collaborating development teams.
  • They are composite applications that present information from multiple sources through an integrated user interface.
  • They support XCopy deployment of independently developed modules.
  • They support online business transaction processing Web sites.
  • They deliver a responsive user experience.
Note The software factory is optimized to create online business transaction processing Web sites. It is not optimized for Web content sites or collaboration sites.

The software factory contains a collection of reusable components and libraries, Visual Studio 2008 solution templates, wizards and extensions, How-to topics, automated tests, extensive architecture documentation, patterns, and a reference implementation. The software factory uses ASP.NET and the Enterprise Library.

By using the software factory, architects and developers can focus their efforts on business opportunities and create Web client applications that effectively address the needs of their organizations.

Downloads
Guidance Assets

Note The Guidance Assets are also included in the Web Client Software Factory. The Guidance Assets are provided to allow a developer to implement different components of the factory without having to use it in its entirety.
Getting Started
Community
License
 References
نویسنده : Nasser Hajloo : ٩:٢٠ ‎ق.ظ ; ۱۳۸٧/۱/٢٢
Comments پيام هاي ديگران ()      لینک دائم

SCSF - Smart Client Software Factory

Summary

Architects and developers can quickly incorporate many of the proven practices and patterns of building composite smart client applications. These practices and patterns have been identified during the development of many smart client applications and their components.

By using the software factory, architects and developers can focus their efforts on business opportunities and create smart client applications that effectively address the needs of their organizations.

The Smart Client Software Factory provides an integrated set of guidance that assists architects and developers create composite smart client applications. These applications have one or more of the following characteristics:

  • They have a rich user interface that takes advantage of the power of the Microsoft Windows desktop.
  • They connect to multiple back-end systems to exchange data with them.
  • They present information coming from multiple and diverse sources through an integrated user interface, so the data looks like it came from one back-end system.
  • They take advantage of local storage and processing resources to enable operation during periods of no network connectivity or intermittent network connectivity.
  • They are easily deployed and configured.

in other word The Smart Client Software Factory is a guidance offering that provides comprehensive architecture guidance to help customers build Composite Smart Clients using the Microsoft platform (Win Forms, WPF, etc). An SCSF solution is composed of a number of discrete, independent, yet functional assemblies and components. These pieces are dynamically loaded and integrated together at runtime within a shell to form a fully coherent application.

SCSF Architecture.png

 

Although we all pretty much suspected it, Glenn Block validates our thinking by putting together a nice post, called Acropolis, the future of Smart Client, that positions the Smart Client Software Factory and Composition Application Block with respect to Acropolis. His statement:

"With the announcement of Acropolis, we currently have no further plans for SCSF releases."

pretty much says it all. The Smart Client Software Factory will still be supported, but the current version is expected to be the last version.

Glenn does a great job of answering common questions, so I recommend reading his post.

Note that the Web Client Software Factory ( WCSF ) project is not effected by Acropolis.

deduction

 Smart Client Software Factory (SCSF) is a Guidance Package driven CAB solution. It's architecture extends the CAB architecture. The SCSF experience involves the Guidance Automation Toolkit. A solution is generated for you when creating a new one within Visual Studio 2005, but the code generation doesn't stop for a SCSF solution until all the requisite parts are constructed. Afterwards, developers run "Recipies" to generate code in large and small chunks. This Guidance is extensible and it is an add-on to the IDE. Back to the SCSF CAB generated solution, SCSF enhances the stock CAB in the area of deployment as well as the process of loading modules.

Downloads
Whitepaper
Getting Started
Community
License
  References

 

نویسنده : Nasser Hajloo : ٥:٠٧ ‎ب.ظ ; ۱۳۸٧/۱/٢۱
Comments پيام هاي ديگران ()      لینک دائم

Acropolis

Microsoft "code-name" Acropolis, smart client futures

Project Description

Acropolis is a set of components and tools that make it easier for developers to build and manage modular, business focused, client .NET applications. Acropolis is part of the “.NET Client Futures” wave of releases, our preview of upcoming technologies for Windows client development.



Acropolis builds on the rich capabilities of Microsoft Windows and the .NET Framework, including Windows Presentation Foundation (WPF), by providing tools and pre-built components that help developers quickly assemble applications from loosely-coupled parts and services. With Acropolis you will be able to:

  • Quickly create WPF enabled user experiences for your client applications.
  • Build client applications from reusable, connectable, modules that allow you to easily create complex, business-focused applications in less time.
  • Integrate and host your modules in applications such as Microsoft Office, or quickly build stand-alone client interfaces.
  • Change the look and feel of your application quickly using built-in themes, or custom designs using XAML.
  • Add features such as workflow navigation and user-specific views with minimal coding.
  • Manage, update, and deploy your application modules quickly and easily.

If you read the description above it seems to be very similar to Smart Client Software Factory. What's the relationship between them, how does the future of SCSF looks like? If you have this questions, your planning to use SCSF or you are using SCSF check out this post on Glenn's Block (P&P Product Planner) about P&P, SCSF & Acropolis.

If you wanna play around with Acropolis bits download them from here. For a preview of Acropolis and to get involved I recommend you this video Getting started with code-name "Acropolis".


A New Phase for the Acropolis Project
The Acropolis incubation project has been a great learning experience for us and we have received a lot of great feedback that will keep us very busy for quite a while.
We are very excited to be entering the next phase of the project where we will begin to roll many of the Acropolis concepts into future versions of the .NET Framework for the desktop and Silverlight. Unfortunately, while we figure out exactly how to go about this, we have decided not to release any more Acropolis CTP's. We’re going to keep the current CTP bits available to allow you to continue prototyping and evaluating the Acropolis concepts. There will be no new functionality added to the Acropolis CTPs but we do hope that you will continue to provide feedback to us on what you like or don’t like.
We do have some good news though! We were pleasantly surprised to get feedback from many of you that you want to go live with Acropolis based solutions in the short term. To us that validated a lot of the thinking we have been doing and it is a positive indicator of the Acropolis approach. Because of this type of feedback, we want to help you continue to take advantage of the Acropolis concepts and the power of the .NET platform while we figure out the longer term plan.
We are very excited to announce that we are going to be working closely with the Microsoft Patterns & Practices team to provide guidance (samples, applications blocks, patterns and so on) for building composite client applications for .NET Framework 3.5 and Visual Studio 2008. As part of that effort we want to engage with those that have been following the Acropolis project to ensure that this guidance meets your needs. Glenn Block, the Patterns & Practices client product manager, has much more information about the Composite Applications for Visual Studio 2008 and .NET 3.5 project here. (Click for his post.)
If you have evaluated Acropolis and are unsure whether to adopt it for your project, or to use the existing CAB, or to wait for the new guidance, our guidance for this situation remains the same – if you are building a Windows Forms LOB composite client (with maybe rich islands of WPF content) you should carefully evaluate the current CAB release. If you are specifically interesting in building composite applications on .NET 3.5, please get involved with the Patterns & Practices project and help us to deliver a guidance package that meets your requirements.
Thanks again for your feedback and expect to hear more in the next couple of months about our future plans.


Download All Acropolis Video Series here

Building Rich Client UI With Acropolis

The Acropolis Client Application Framework


Download July CTP Here : http://www.microsoft.com/downloads/details.aspx?FamilyID=44977885-86B5-4AA0-9F20-DB365BFB9D10&displaylang=en

Team Blog : http://blogs.msdn.com/Acropolis/
Reference : http://staff.southworks.net/blogs/johnny/archive/2007/06/06/Microsoft-_2200_code_2D00_name_2200_-Acropolis_2C00_-smart-client-futures.aspx


Sandcastle

Project Description
Sandcastle produces accurate, MSDN style, comprehensive documentation by reflecting over the source assemblies and optionally integrating XML Documentation Comments. Sandcastle has the following key features:

* Works with or without authored comments
* Supports Generics and .NET Framework 2.0
* Sandcastle has 2 main components (MrefBuilder and Build Assembler)
* MrefBuilder generates reflection xml file for Build Assembler
* Build Assembler includes syntax generation, transformation, etc
* Sandcastle is used internally to build .Net Framework documentation




Genereating Website for API documentation using Sandcastle

In this blog on generating builds using Powershell, I provided details on generating a single command wrapper to build CHM and HxS files regardless of where the source assemblies and comments are located. This powershell script provided the following features:

Allows the build options to be read from a configuration file. Options specified on the command line override options defined in the configuration file.
Handles any number of target assemblies and comment files, including globbing.
Handles any number of dependencies.
Should work with .NET 2.0, 3.0, and 3.5.
Supports vs2005, prototype, and Hana presentation styles.
Provides hooks to add new presentation styles in the future, including user defined styles, and user defined function overrides.
The script is written for PowerShell 1.0.

Prerequisites

The build script has the following dependencies:

Latest release of Sandcastle from http://www.codeplex.com/sandcastle.
The DxRoot environment variable must point to the root of the Sandcastle installation.
To make it easier for the user, the PATH environment variable should contain the …/ProductionTools folder, which contains the scbuild.ps1 script.
.NET 2.0 for Sandcastle.
PowerShell 1.0, with the execution policy set to RemoteSigned or Unrestricted. [Note: In a future release we could Authenticode sign the script to make this unnecessary.]
hhc.exe to compile CHM files.
Hxcomp.exe to compile HxS files.
Running the Script

The scbuild.ps1 script can now be used to build a website, in addition to .chm and .hxs files. To build a website use the –BuildWebsite option. For example, to build a website with API documentation for an assembly named test.dll, with comments in comments.xml, use the following command:

scbuild –framework 2.0 –sources test.dll,comments.xml –BuildWebsite

The build result will be in test website. You can use the –name option to specify an output location and root name for the website.

Currently scbuild supports only the default presentation style: -style vs2005. Future versions may support other output styles.

The output from scbuild is designed to be integrated into an existing website. The master page, web.config file, and style sheet in the output directory are intended as a starting point for further customization. You will probably want to keep the contents of the icons and styles directories however, because they are used to give the generated API topics the vs2005 look-and-feel. All JavaScript functionality was disabled in this version, to minimize conflicts with the website the reference topics will be merged into.

Also note the contents of the web.config file, specifically the element. Make sure to copy the sample definition to your own website, to ensure that non breaking spaces get displayed properly.

The “api” directory contains one ASP.NET content file for each topic and a sitemap that you can merge into the sitemap of an existing website, as shown in the example. At runtime, the sample master page uses a tree view to display the sitemap and a simple content placeholder to display the topics.

To merge the output into your own website, you can copy the api, icons, and styles directories to the target website and include the sitemap into the master sitemap file as appropriate. Or you can use the –WebTemplate option to specify a user defined template that will be copied to the output directory, instead of the Sandcastle sample.

If you want to use the generated sitemap, include the following reference to the API topics in your own sitemap:

Further customization is possible through the –WebBuildConfig option, to specify a custom BuildAssembler config file.

For more information, please refer to the header of the scbuild.ps1 script, which shows a list of all available build options and short descriptions. Hope this helps.



Project Home : http://www.codeplex.com/Sandcastle
Download Here : http://www.codeplex.com/Sandcastle/Release/ProjectReleases.aspx?ReleaseId=9921
Complete State of Project : http://www.codeplex.com/Sandcastle/stats/view
References : http://blogs.msdn.com/sandcastle/ , http://www.codeplex.com/Sandcastle