CoreCLR's Blog

Archive for October, 2009

Debugging Release Builds

Posted by coreclr on October 30, 2009

This is a nice little trick you might not know.

Lets say you have an application build in release
mode (/debug:pdbonly /optimize+) and you want to attach the debugger directly to a running instance.

To keep it simple, this is our app:

public partial class Window1 : Window
      {
          public Window1()
          {
              InitializeComponent();
          }

          private void button1_Click(object sender, RoutedEventArgs e)
          {
              Cal(100);
          }

          int Cal(int x)
          {
              return x * x;
          }
      }

We set a break point in this line and attach to the process:

return x * x;

But the debugger will never break in our code!

The reason is that the JIT compiler has inlined the method call (remember that will compiled with /optimize+)

This is indeed a good thing. In most cases, we want the JIT compiler to have the option to inline our production code.

We can see that the module is optimized in the modules window in VS:

 image

Disable JIT Optimization

For debugging purposes, we can actually disable JIT Optimization without rebuilding the code.

Put an ini file (yes ini) in the same folder as the exe file. The filename should match the exe filename, just with ini as extension. In this case WpfApplication1.exe and WpfApplication1.ini.

The ini file should contain these 3 lines:

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

This will tell the JIT compiler not to optimized the code, so the method-call won’t be inlined.

We can now see that the loaded module is not optimized:

image

Remember to disable “Enter Just My Code” in VS.NET (Tools –> Options –> Debugger)

Advertisements

Posted in .NET, Debugging, Visual Studio, WPF | Leave a Comment »

Multiple ResourceDictionary’s with Blend Support

Posted by coreclr on October 29, 2009

On any real WPF/Silverlight project, you end up with a lot of Styles/Templates. The recommended approach is to put these in a separate ResourceDictonary.

But pretty soon, this ResourceDictonary can become very large, so we need to split it into multiple ResourceDictonary’s, but at the same time we don’t want to loose Blend Design Support.

Lets say we have a Style for ComboBox and a Style for a Button. Both styles are Based on another Style called BaseStyle. Here is a snippet of the Styles:

<Style x:Name="BaseStyle" TargetType="Control">
           <Setter Property="FontSize" Value="20" />
       </Style>


       <Style x:Key="ComboBoxStyle" TargetType="ComboBox" BasedOn="{StaticResource BaseStyle}">
           <Setter Property="Padding" Value="6,2,25,2"/>
           <Setter Property="Background" Value="#FF1F3B53"/>
           <Setter Property="HorizontalContentAlignment" Value="Left"/>
           <Setter Property="BorderThickness" Value="1"/>
           <Setter Property="TabNavigation" Value="Once"/>
           </Setter>
       </Style>

       <Style x:Key="ButtonStyle" TargetType="Button" BasedOn="{StaticResource BaseStyle}">
           <Setter Property="Background" Value="#FF1F3B53"/>
           <Setter Property="Foreground" Value="#FF000000"/>
           <Setter Property="Padding" Value="3"/>
           <Setter Property="BorderThickness" Value="1"/>
       </Style>

As long as these Styles exist in the same ResourceDictonary, then everything is good.

Now lets say we want to put the Button Style in a ResourceDictonary called ButtonResources.xaml and the ComboBoxStyle in a ResourceDictonary called ComboBoxResources.xaml.

But what do we do about the BaseStyle? We don’t want to duplicate it in both files.

One way is to create a new ResourceDictonary (BaseResources.xaml) and place it in that ResourceDictonary.

But now we lost Design-time support in Blend…

The trick here is pretty simple: just include BaseResources.xaml in both ButtonResources.xaml and ComboBoxResources.xaml:

Put this section just before the Styles in both files:

<ResourceDictionary.MergedDictionaries>
           <ResourceDictionary Source="BaseResources.xaml" />
       </ResourceDictionary.MergedDictionaries>

(Please note that you cannot have circular reference).

In our Main app we can just include the two files and everything runs:

<ResourceDictionary.MergedDictionaries>
         <ResourceDictionary Source="/SilverlightThemes;component/Themes/ButtonResources.xaml" />
         <ResourceDictionary Source="/SilverlightThemes;component/Themes/ComboBoxResources.xaml" />
     </ResourceDictionary.MergedDictionaries>

Posted in .NET, Blend, Silverlight, WPF | Leave a Comment »

Using DebugView during Silverlight development

Posted by coreclr on October 24, 2009

DebugView is a nice little utility that lets you monitor debug output on your local system. It can display Win32 debug output, so when you use Debug.WriteLine() it will be displayed in DebugView.

This is very handy during Silverlight development, since we cannot write to a local log file and monitor that using Grep or something else.

One specific scenario where its really useful, is when you want to get client side log information for a Silverlight application that runs on a machine without a debugger installed.

Lets look at an example:

We have an Silverlight application with a button event handler that uses Debug.WriteLine to output some information.

private void Button_Click(object sender, RoutedEventArgs e)
{
  Debug.WriteLine(DateTime.Now.ToLongTimeString());
}

If you run this on you development box, you don’t really need DebugView. You can just look at the Visual Studio’s output window.

But if you run this on at machine without a debugger, you can use DebugView to grab the output. Here is a screenshot at this in action:

DebugView

(use Ctrl+x to clear the output)

Using DebugView in Release Mode

Since Debug.WriteLine has the [Conditional("DEBUG")] attribute defined, we can only use it when the DEBUG symbol is defined. By default this symbol is not defined when we compile in Release mode.

In the full framework, we could use Trace.WriteLine(). But in Silverlight Trace is internal, so we cannot use it.

I you really want to use Debug.WriteLine in Release Model, you could explicit define the DEBUG symbol like this:

#define DEBUG
using System.Diagnostics;

namespace DebugViewTest
{
    public static class DebugUtil
    {
        public static void WriteLine(string message)
        {
            Debug.WriteLine(message);
        }
    }
}

Now we can get client side logs from a machine that runs our Silverlight application in Release mode.

In most cases I would give the user a debug version, an let him reproduce the issue. But there might be scenarios where you don’t have that option.

Another option is to use Isolated Storage as logging storage. We will look at this in a future post.

Posted in .NET, Debugging, Silverlight | 2 Comments »

Silverlight 3 Styling Screencast

Posted by coreclr on October 17, 2009

I recorded a new screencast (in Danish) that explains Styling in Silverlight 3. Get it here:

Styling in Silverlight 3.

Posted in Screencast, Silverlight | Leave a Comment »

Slides and code from Dev Days, Århus

Posted by coreclr on October 17, 2009

Slides and code from the “Silverlight n-tier Architecture” session at Dev Days, Århus.

Find the slides here and the code here.
(remember to rename ANUG.docx to ANUG.zip).

Posted in Presentations, Silverlight, Talk | 1 Comment »

Data Binding Screencast

Posted by coreclr on October 13, 2009

I recorded a screencast (in Danish) about Data Binding in Silverlight 3.

Get it here:

Data Binding in Silverlight 3

Posted in Screencast, Silverlight, Video | Leave a Comment »

Routed event handler in Silverlight 3

Posted by coreclr on October 11, 2009

In WPF its possible to add an routed event handler for a routed event. This is useful in scenarios where you want the event to bubble up the tree, even if a control marks the event as handled.

This feature is now supported in Silverlight 3 as well.

Let me give a concrete example on this feature.

Say we have a ContentPresenter when we can place any content inside. When the user click on the content, we want to catch that event (MouseLeftButtonUpEvent). But we don’t want to subscribe to each control inside the ContentPresenter.

The good news is that most event will bubble up the tree. The bad news is that some controls catches the MouseLeftButtonUp event and mark it as handled.

This is the XAML:

<Grid x:Name="LayoutRoot">
        <ContentPresenter x:Name="presenter">        
            <Border Margin="8" 
                    BorderBrush="#FFF60606" 
                    BorderThickness="2"
                    Height="100" 
                    Background="White" 
                    HorizontalAlignment="Left" 
                    VerticalAlignment="Top" 
                    Width="150">
                <Button Margin="25"                        
                        Content="Button"/>
            </Border>
        </ContentPresenter>        
    </Grid>

To catch the MouseLeftButtonUp Event on any element inside the ContentPresenter, we can now in Silverlight 3 use the AddHandler method. This is the signature:

public void AddHandler(RoutedEvent routedEvent, 
    Delegate handler, 
    bool handledEventsToo);

Add we use it like this:

public SilverlightControl1()
{
  InitializeComponent();

  this.AddHandler(UIElement.MouseLeftButtonUpEvent,
   new MouseButtonEventHandler(OnMouseLeftButtonUp), true);
}

private void OnMouseLeftButtonUp(object sender, MouseButtonEventArgs e)
{
  //do stuff
}

Because we pass true as the last parameter, we indicate that we want to be invoked, even if the event has been marked as handled. In the above example, the button will handle the MouseLeftButtonUp event, so we need to pass true to the AddHandler to get invoked.

According to the doc, this feature can only be used with KeyDown, KeyUp, MouseLeftButtonDown and MouseLeftButtonUp.

Posted in .NET, Silverlight, WPF | Leave a Comment »

Silverlight 3 – Local Connection Screencast

Posted by coreclr on October 9, 2009

I recorded a screencast (in Danish) that explains the “Local Connection” feature in Silverlight 3.  Enjoy

Local Connection in Silverlight 3.

Posted in Screencast, Silverlight, Video | 1 Comment »

Visual Studio 2008 Target Framework and .NET Service Packs

Posted by coreclr on October 7, 2009

Visual Studio 2008 is a great product, but it would be nice to be able to compile against a specific .NET service pack. Let me illustrate,

Lets say that we have this .NET 2.0 application:

img3

Everything runs fine on our server with .NET 2.0 installed.

Then we upgrade our project to VS2008 and set the target to .NET 2.0. We compile and everything is fine.

img6

Until a developer uses some functionality from the .NET 2.0 SP1 API.
The source will compile, but fail at runtime since the server don’t have .NET 2.0 SP1 installed.

img4 

The problem is that we are compiling against .NET 2.0 SP1 and not .NET 2.0.

When we install VS2008, we get .NET 3.5 and .NET 2.0 SP1 and .NET 3.0 SP1. Using VS2008, there is no way to compile against a specific service pack.

So when using VS2008 to develop .NET 2.0 .NET apps, we need to ensure that we don’t use any functionality from .NET 2.0 SP1.

We can catch this during compile-time by using this FXCop rule. This rule will give the following warning/error depending on the settings.
 
img7

By the way, we have the same issue when installing .NET 3.5 SP1. In that case, VS2008 will compile against .NET 2.0 SP2 / .NET 3.0 SP2, because these two service packs are included in .NET 3.5 SP1.

Posted in .NET, Visual Studio | Leave a Comment »

Dispatcher in Silverlight – Extension Method

Posted by coreclr on October 7, 2009

Normally when we need to update the UI from a non-UI thread, we write code that checks if we are on the UI thread or not. Like this:

ThreadPool.QueueUserWorkItem((state) =>
  {
         if (CheckAccess())
         {
             txtFirstName.Text = 
             DateTime.Now.ToString();
         }
         else
         {
             Deployment.Current.Dispatcher.BeginInvoke(() => 
             {
                 txtFirstName.Text = DateTime.Now.ToString();
             });
         }
     }
  );

But this is a lot of code, so to simplify this, we can write an extension method like this:

public static void InvokeIfNeeded(this DependencyObject ctl, Action doit)
{
  if(ctl.Dispatcher.CheckAccess())
  {
      doit();                
  }
  else
  {
      ctl.Dispatcher.BeginInvoke(doit);
  }
}

And we can then use it like this:

InvokeIfNeeded( () => txtFirstName.Text = DateTime.Now.ToString());

Note that if we access UI elements from a generated proxy, the BackgroundWorker API or from the WebClient API, Silverlight will automatic marshal the code to the UI Thread, so we don’t need to do this explicit. But if we access UI elements from a manually created Thread, a ThreadPool Thread or the HttpWebRequest API, we need to use the Dispatcher. Also note that in the Silverlight version, it’s not possible to specify a DispatcherPriority. It’s always processed with the Background priority.

Posted in .NET, Silverlight, Threading | Leave a Comment »