I recently stumbled upon a not very well documented "design feature" that took me a couple of hours to track down.

If you are defining a custom delete function for an ObjectDataSource you must also remember to define the DataKeyNames property of the GridView you are working with. If you do not remember to do this, the object’s value passed to your delete function will be null.

You can read more about the ObjectDataSource delete issue here.

Hope this helps!

I was really surprised to discover this bug a couple of days back while working on an ASP.Net 2.0 web site.

I spent several hours barking up the wrong code tree since I was convinced it had to do with some recent code changes I made.

But as it turns out this problem is as old as the server itself and for some reason has not been fixed by any .Net patches.

The jist of it is that if you encounter .net exceptions that only happen on your server with certain types of traffic ( examples: google bot, yahoo bot and some other esteemed visitors), you might be the victim of an annoying bug that has existed, as far as I could tell, for a couple of years and has not been fixed till date.

The telltale signs would be server exceptions that look like ->

Exception of type 'System.Web.HttpUnhandledException' was thrown.
Stack trace: at System.Web.UI.Page.HandleError(Exception e)

And inner exception type ->

System.Web.HttpException: Cannot use a leading .. to exit above the top directory. at System.Web.Util.UrlPath.ReduceVirtualPath(String path)

---------------

As it turns out this bug has to do with .Net 2.0 browser detection bug and can be fixed by adding a browser definition file to correct the problem.

You can also reproduce and test the browser detection bug here.

Note that this bug often occurs when you use url rewriting on your server.

 

If you forget to set the TargetType in a ControlTemplate and access certain properties in the content presenter, Blend will report an error and you will not be able to edit the XAML in design mode.

Note that this error only effects design mode in blend, the XAML still compiles and works perfectly (assuming we apply the template to the correct type).

Example:

Ok on blend, ok on VS 2008 ->

Invalid XAML error on blend, ok on VS 2008 ->

For the error to appear you will also have to access non globally shared properties in the content presenter.

In the example below we try to set a content property which is not guaranteed to exist in the type we apply the template to.

Example:

 

When upgrading an existing Silverlight project to silverlight 2 beta 2 you might encounter the following error:

"The type or namespace name 'DataGrid' does not exist in the namespace 'System.Windows.Controls' (are you missing an assembly reference?)"

To solve the problem:

1. First go to your project references (Expand your project references sub tree in the Visual Studio IDE) and  look for System.Windows.Controls.Data in the reference list.

(If it does not exist in the list then you probably had the problem before the upgrade and you need to add a reference to System.Windows.Controls.Data by going to Project/Add Reference/.Net and choosing it from the list)

2. Press the right button on the System.Windows.Controls.Data reference and choose properties.

3. If the "Specific Version" property is set to true, change the "Specific Version" property to False.

4. Rebuild the project/solution.

This solved the problem for us on several Silverlight projects using a DataGrid.

Cheers

While working on  Bumble Beegger we came across a daunting problem that only seemed to happen under certain conditions.

Silverlight error message
ErrorCode: 4002
ErrorType: ManagedRuntimeError
Message: System.Exception: Error HRESULT E_FAIL has been returned from a call to a COM component.
at MS.Internal.XcpImports.MethodEx(IntPtr ptr, String name, CValue[] cvData)
at System.Windows.DependencyObject.MethodEx(String methodName, CValue[] cvData)
at System.Windows.UIElement.ReleaseMouseCapture()
at System.Windows.Controls.Primitives.ButtonBase.ReleaseMouseCaptureInternal()
at System.Windows.Controls.Primitives.ButtonBase.OnLostFocus(RoutedEventArgs e)
at System.Windows.Controls.Primitives.ButtonBase.OnLostFocus(Object sender, RoutedEventArgs e)
at System.Windows.CoreInvokeHandler.InvokeEventHandler(Int32 typeIndex, Delegate handlerDelegate, Object sender, Object args)
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, String eventName) 

After a few hours of debugging, experimenting and googling I came across a discussion on Silverlight.net that shed some light on the problem.

As it turns out there is bug in Silverlight 2 beta 1 that can cause a crash when changing the visibility of a button control inside a mouse event handler.

The recommended workarounds around this problem were to change the size to 0,0 or change the opacity to 1.

Another option is to use the Canvas.ZIndexProperty and set it to a number that is smaller then your foreground elements.

The problem is that those does not always produce a similar enough effect in other elements.

If you still want to use visibility where possible, you can check the type of control and choose to modify visibility, size, opacity or Z Index according to the type.

Granted this is a horrible hack but it gets the job done until we can get our hands on beta 2...

Example:

// assume uiElement points to some valid UIElement

UIElement uiElement;

// check element type, if its not a button set visibility to collapsed else use ZIndex for a similar effect

if (uiElement.GetType() != typeof(Button)) 

   uiElement.Visibility = Visibility.Collapsed;

else

   ((Button)uiElement).SetValue(Canvas.ZIndexProperty, -1);

If you are trying to debug ASP.NET applications on Vista you might run into the following problem:

localhost is not accessible through your browser and the error that is displayed is "Internet Explorer cannot display the webpage".

After some googling I ran across a reference to the same problem.

The problem has to do with the fact that there are 2 entries for local host in the hosts file ([Windows directory]\System32\drivers\etc\hosts).

One for ipv4 and one for ipv6.

Example:

127.0.0.1 localhost
::1 localhost

To solve the problem you can remark one of them. The example below remarks the ipv6 entry.

127.0.0.1 localhost
# Causes problems when using localhost ->
#::1 localhost

Note that you might not be able to modify the hosts file even if you are running as an administrator.

The following Microsoft KB explains how to change the hosts file:

http://support.microsoft.com/default.aspx?scid=kb;en-us;923947

Hope this helps...
 

If you run into this message when building a Silverlight project and have a class name and a namespace name that are identical you might be suffering from some kind of naming problem in the Silverlight development environment.

I found another reference to the problem in an MSDN forum.

To solve the problem I renamed the class name to a different name (one that is not identical to the namespace name).

Hope this helps...

 

 

Last week we were trying to debug legacy 32-bit applications that were misbehaving on Windows 2008 64-bit.

Microsoft's debugging tools for windows information page states the following regarding When to Use 64-bit Debugging Tools.

"The 64-bit versions of Debugging Tools for Windows allow you to debug both 32-bit and 64-bit user-mode applications running on 64-bit processors. Use this package to debug both the application and the WOW64 emulator."

Unfortunately WinDbg 64-bit does not seem work properly on at least some of the 32-bit apps running on windows 2008 64-bit that we have tested.

The problem is that WindDbg does not seem to find the correct symbols for the 32 bit application you try to debug even though WinDbg finds the correct PDB symbol files.

To solve the problem we had to install the 32-bit version of the debugging tools for windows side by side with the 64-bit version (we did not have to uninstall the 64-bit version) and use the 32-bit version to debug the 32-bit applications running on the 64 bit version of windows. 

Note that the version of the debugging tools for windows we used for both 32 and 64 bit debugging was version 6.8.4.0 released on October 18, 2007.
 

If you are using ASP.NET AJAX to create RIA's (Rich Internet Applications) you might run into the maximum length exceeded error.

This error occurs when you are trying to send too much data using ASP.NET AJAX from the client to the server and vice versa.

On the function call stack level this error occurs at System.Web.Script.Serialization.JavaScriptSerializer.Deserialize or at System.Web.Script.Services.RestHandler.InvokeMethod depending if you are sending or receiving data.

The problem is that the default maximum size (102400 characters) does not suffice when you try to transfer a significant amount of data.

To increase the maximum allowed send/receive data you need to change the MaxJsonLength Property.

To change the MaxJsonLength Property you can edit your web.config file.

Look for the following commented section in the web.config file:

 

<!-- Uncomment this line to customize maxJsonLength and add a custom converter -->

<!--

<jsonSerialization maxJsonLength="500">

<converters>

<add name="ConvertMe" type="Acme.SubAcme.ConvertMeTypeConverter"/>

</converters>

</jsonSerialization>

-->

 

Convert it to something along the following lines (see note below):

 

<!-- Uncomment this line to customize maxJsonLength and add a custom converter -->

<jsonSerialization maxJsonLength="200000"><

converters>

<!--<add name="ConvertMe" type="Acme.SubAcme.ConvertMeTypeConverter"/>--></

converters>

</jsonSerialization>

 

Note that in the example above the max size was set to 200,000 characters.

You should calculate and test the size you will need for your data (there might be a few bytes of overhead so take that into account).

 

I've recently encountered an annoying bug when trying to connect to a dell laptop using Remote Desktop..

Every time a remote desktop connection will be established to the laptop machine and the laptop was using a wireless connection, the following would happen:

1. The remote desktop logon screen would appear on the connecting side.

2. Entering the logon info would lead to a power down of the wireless card on the remote laptop machine.

3. The connection will be broken on the laptop side.

3. A blank remote desktop screen would appear on the connecting machine.

4. The remote desktop connection will eventually time out on the connecting machine.

The problem seems to be related to power saving options but cannot be resolved using the advanced parameters available with the wireless card.

The problem only appears when using the Dell Wireless WLAN Card Utility.

This problem was produced on a dell laptop running Windows XP SP2 with a dell wireless 1390 card.

To solve the problem disable the Dell Wireless WLAN Card Utility and let Windows manage the wireless configuration.

To do that:

1. Open Dell Wireless WLAN Card Utility in the Control Panel.

2. Uncheck the "Let this tool manage your wireless networks" check box.

3. Configure your wireless connection using the standard Windows wireless utility.

If any one else had a similar problem on their dell laptops please drop me a comment below so I can collect more data to send to Dell regarding this bug.

Sponsored link: Terminal Services and Remote Desktop Software