Instead of structuring my tree like this, with the children nested under the Border with the Bitmap effect:

<Border>
<Border.BitmapEffect>
<BevelBitmapEffect />
</Border.BitmapEffect>
<Grid>
<!--Children-->
</Grid>
</Border>


I simply changed it to this, moving the BitmapEffected element out of the ancestry of the rest of the tree:

<Grid>
<Border>
<Border.BitmapEffect>
<BevelBitmapEffect />
</Border.BitmapEffect>

</Border>
<Grid>
<!--Children-->
</Grid>
</Grid>


Now the grid that contains the children is a sibling of the BitmapEffected Border, not a descendant.

Cause: occurs when you are referencing a DLL or project with its target platform set to x86 from a project set to AnyCPU or x64.

I was afraid to power down the system, as I’ve read of it corrupting the OS and requiring a complete reinstall, so just left it. After about 12 hours, it apparently finished the updates and shut down all the way. It then booted fine with no errors.

So, it appears that sometimes those updates can take an obscenely long time. When in doubt, better to give it a while than to force a reboot.

<UserControl x:Class="CatManagement.UI.TestControl"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Width="400" Height="300" x:Name="Me">

I assigned an x:Name because I was wanting to bind certain UI elements to custom properties defined on my user control. However, this caused a problem when I used this user control in a DataGridTemplateColumn like this:

<data:DataGridTemplateColumn.CellTemplate>
<DataTemplate>
<local:AssignUserControl DataContext="{Binding}" />
</DataTemplate>
</data:DataGridTemplateColumn.CellTemplate>

The problem was that the following exception was thrown whenever a second DataGrid row was inserted:

I set up our internal trace sources programmatically to read the switch value from the registry, which worked fine. However, when it came to configuring the System.Net trace sources, I ran into problems. After a lot of searching it appears impossible to gain access to those system trace sources without using some shady reflection techniques which I’m not comfortable with in a production environment. Without access to those TraceSource objects, it is impossible to programmitically add my own switches and listeners.

My eventual solution was to configure the System.Net trace sources in the app.config file, but use a custom switch that reads its value from the registry. It took me a bit to figure out how to do this, so I’m reposting it here:

My custom switch looks like this:


Public Class RegistrySwitch
    Inherits SourceSwitch

    Public Sub New(ByVal name As String)
        MyBase.New(name)
        Me.Value = GetSwitchValue()
    End Sub

    Public Sub New(ByVal name As String, ByVal value As String)
        MyBase.New(name)
        Me.Value = GetSwitchValue()
    End Sub

    Private Shared Function GetSwitchValue()
        Dim switchValue As String = GetRegistryValue("TracingLevel", "Off")

        Select Case switchValue
            Case "True", "1", "-1", "On"
                switchValue = "All"
            Case "0", "False"
                switchValue = "Off"
        End Select

        Return switchValue
    End Function

End Class

The GetRegistryValue function (code not shown) simply reads the specified value from our product’s key in the registry.

Then my app.config file looks like this:
  <system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.Net" tracemode="includehex" maxdatasize="1024" switchName="NetworkSwitch" switchType="MyProject.RegistrySwitch, MyProject">
        <listeners>
          <add name="System.Net"/>
        </listeners>
      </source>
      <source name="System.Net.Sockets" switchName="NetworkSwitch"  switchType="MyProject.RegistrySwitch, MyProject">
        <listeners>
          <add name="System.Net"/>
        </listeners>
      </source>
      <source name="System.Net.Cache" switchName="NetworkSwitch"  switchType="MyProject.RegistrySwitch, MyProject">
        <listeners>
          <add name="System.Net"/>
        </listeners>
      </source>
    </sources>
    <switches>
      <add name="NetworkSwitch"  value="Off"/>
    </switches>
    <sharedListeners>
      <add name="System.Net" type="MyProject.MyTextWriterTraceListener, MyProject" initializeData="network.log" />
    </sharedListeners>
  </system.diagnostics>

Notice that I had to define the CLR type of my switch not in the <Switches> node where the switch is named, but in the switchType parameter on each <Source> that references the switch.  Also note that even though the Value of the switch is set to Off in this configuration file, that value is overwritten when my RegistrySwitch subclass initializes with the value from the registry.

Also note that in this example, my listener is a custom type. It is a TextWriterTraceListener that places the log file in a valid user data path.

HtmlPage.Window.Navigate(uri)

It is caused by security settings preventing the launching of unsafe content from code as opposed to a user-initiated action. I guess that is why the HyperlinkButton control works just fine with a .application URL in its NavigateUri property.

To get around this, I subclassed the HyperlinkButton class as shown below:

 Public Class MyHyperlinkButton
    Inherits HyperlinkButton

    Public Sub NavigateTo(ByVal url As String)
        Me.NavigateUri = New Uri(url)
        Me.OnClick()
    End Sub
End Class

The NavigateTo method has access to the protected OnClick method of the HyperlinkButton that initiates the navigation. This navigate takes place through a security path different from HtmlPage.Window.Navigate().

I created an invisble instance of MyHyperlinkButton on my Silverlight page.  Then from anywhere in my Silverlight code-behind, I can call the NavigateTo(url) method on the invisble hyperlink control to successfully launch the ClickOnce application.

Whether I’m exploiting an unknown security hole here or not, I do not know. It is possible that Microsoft may deem this a security risk and close this work around. In the mean time, for SL2, it works.

http://dotnetdreamer.com/2009/03/21/azure-services-method-not-allowed-405/

“InitializeError error 2104: could not download the silverlight application, check web server settings”

A brief search online showed the solution:

In IIS On the Web Server

1) Go to Site Properties -> HTTP Headers

2) Click MIME Types

3) Click New

4) Fill the follow fields:
    Extension: .xap
    MIME type: application/x-silverlight-app

That solved the problem for me.

Here is a summary of my changes:

Losing the MethodCaller.OnEventMethodCall property

I realized that since the OnEventMethodCall object derives from MethodCall, there’s no reason to have a separate attached property for specifying an OnEventMethodCall. So I dropped the MethodCaller.OnEventMethodCall attached property. The MethodCaller.MethodCall property should be used instead:

        <mc:MethodCaller.MethodCall>
            <mc:OnEventMethodCall EventName="Click" MethodName="SelectPerson">
                <mc:MethodCall.Arguments>
                    <mc:MethodArgument Value="{Binding}" />
                </mc:MethodCall.Arguments>
            </mc:OnEventMethodCall>
        </mc:MethodCaller.MethodCall>

This makes it cleaner, and also I can create further MethodCall subclasses down the road if needed and use the same attached property to set them up.

Multiple MethodCalls in a trigger

I added a new attached property called MethodCaller.SetMethodCalls that takes in a MethodCallCollection object. This allows me to specify any number of MethodCall objects to be invoked when the trigger fires:

         <Setter TargetName="uxRow" Property="mc:MethodCaller.SetMethodCalls">
            <Setter.Value>
                <mc:MethodCallCollection>
                    <mc:MethodCall MethodName="Focus" Target="{Binding ElementName=uxText}"  />
                    <mc:MethodCall MethodName="BringIntoView" />                                
                </mc:MethodCallCollection>
            </Setter.Value>
        </Setter>

Additionally, this MethodCaller.SetMethodCalls attached property would be used to specify MethodCall‘s (or OnEventMethodCall‘s) via a <Style>. Basically, anywhere you use a <Setter> to set the property. You’ll notice in the snippet above, that we’re passing in a new <MethodCallCollection> object. The SetMethodCalls property has no default value, so when setting it you must pass in a new MethodCallCollection.

Wiring multiple events on the same object

The last change is almost identical to the one I just mentioned. I added another attached property called MethodCaller.MethodCalls that exposes a MethodCallCollection object. The difference between this property and the SetMethodCalls property described above is that this collection is already initialized and instantiated, so you can just add to it without creating a new MethodCallCollection object:

        <mc:MethodCaller.MethodCalls>
            <mc:OnEventMethodCall EventName="Click" MethodName="SelectPerson">
                <mc:MethodCall.Arguments>
                    <mc:MethodArgument Value="{Binding}" />
                </mc:MethodCall.Arguments>
            </mc:OnEventMethodCall>
            <mc:OnEventMethodCall EventName="MouseLeftButtonUp" MethodName="Focus" />
        </mc:MethodCaller.MethodCalls>

(Note: creating a read-only attached property of type collection can be tricky because you need to initialize the collection, but unless you do some special setup, the Getter is not called upon first access like you might expect. And setting a default value via the Attached Property’s Default Value mechanism doesn’t work either, because the value you specified is a shared value and not unique to the instance of the dependency property. See Bill Kempf’s post and John Gossman’s post for more information and explanation of the why’s and how’s.)

Summary

In working with the MethodCaller framework, I found these changes to be useful, so I wanted to post them. The latest code can be downloaded here. I may make another post in the future walking through some of the actual code behind this solution in case anyone is interested.

Thanks for reading!

—Benjamin