Ben Struthers

ASP.NET LISTBOX DOES NOT DISABLE

With ASP.NET 4, ListBoxes no longer disable. This appears to be a bug with ASP.NET 4

According to the ASP.NET 4 Breaking Changes whitepaper (http://www.asp.net/whitepapers/aspnet4/breaking-changes#0.1__Toc256770141)

Controls that are not designed for user input (for example, the Label control) no longer render the disabled="disabled" attribute if their Enabled property is set to false (or if they inherit this setting from a container control).

That's great for label controls etc, but a ListBox (select element with the multiple attribute) is designed for user input and should support the disabled attribute.

There are a couple of options to work around this issue.

1) extend the ListBox and override the SupportsDisabledAttribute property:

public class DisabledSupportedListBox : ListBox
{
   public override bool SupportsDisabledAttribute { get { return true; } }
}

2) server side, manually add the disabled attribute:

ListBox.Attributes.Add("disabled", "disabled");

3) client side, manually add the disabled attribute:

$(function () {
    $("select.aspNetDisabled").attr('disabled', 'disabled');
});

If you're already extending the ListBox, option 1 is definitely the best bet. Otherwise, I'd go with option 2 and only use option 3 as a last resort.

Permalink

C# DATETIME CONSTANT

In VB.NET, you could use a VB Date literal to define a constant. (Side Note, VB Date literals always use the American mm/dd/yyyy format)

Public Const CONSTANT_DATE As DateTime = #1/1/1501#

but in C#, no such thing exists. A simple workaround is to create a static readonly variable and assign it the desired date.

public static readonly DateTime CONSTANT_DATE = new DateTime(1501, 01, 01);

Permalink

CANNOT EVALUATE THE ITEM METADATA "%(FULLPATH)"

When building one of the web services at work, I kept running into this error:

Cannot evaluate the item metadata "%(FullPath)". 
The item metadata "%(FullPath)" cannot be applied to the path 
	"bin\Debug\Native.[...].manifest". 

Turns out I was exceeding the limitation of 255 characters in a file path on windows. Moving the solution to a root directory fixed the error and let the service compile.

Permalink

TRUST NOT GRANTED WHEN RUNNING WPF IN IE

At work, we were getting a few users who were unable to run our deployed WPF application. When running under https, a Windows Presentation Foundation Host error would occur with the following message:

Trust Not Granted
The application cannot be deployed because it is not trusted and possibly unsafe.

Recorded in the Error Log were the following messages:

System.Deployment.Application.TrustNotGrantedException (Unknown subtype)

and

User has refused to grant required permissions to the application.

A blog entry on MSDN suggested modifying the CASPOL. After modifying the CASPOL by giving the site FullTrust, the WPF would run in the browser, but it still wasn't working 100%. Our application makes several web service calls, and the application was erroring when making those calls.

Running ProcMon and filtering for ACCESS DENIED showed that PresentationHost.exe was denied several spots under HKCU.

Running the WPF XBAP Permission Error Tool fixed some of the ACCESS DENIED errors. For others, the user account had to explicitly have read permission to the registry keys and subkeys. It doesn't matter if the user account is in the Administrators group.

In our case, the problematic key was

HKCU\Software\Policies\Microsoft

Without explicit read access, PresentationHost.exe couldn't determine what Security Zone the xbap was running under in IE. This in turn caused the WPF to execute under the Nothing Permissions Set.

Once the user account had explicit read permissions to the registry keys, our WPF application ran with no issues.

Permalink