Tag: .NET

Friendly Reminder: If you release a NuGet package please sign all the DLLs.

Please. I am begging you. If you release NuGet packages sign both the Debug and the Release DLLs. Do not just sign the Release DLLs.

I wasted four hours today debugging the following exception: “FileLoadException: A strongly-named assembly is required. (0x80131044)”.

I was debugging the debug build of an application that uses the Titanium.Web.Proxy version 3.1.1397, obtained using NuGet. The Titanium.Web.Proxy uses BouncyCastle.NetCore version 1.8.10.

I have a python script that copies the build output from the output directory to the appropriate location on my test PC where I have the product I am working on installed. This python script replaces the files already present in the application installation directory with the files produced by building the product on my development PC.

The build process, which uses MSBuild, copies the DLLs for BouncyCastle.NetCore and Titanium.Web.Proxy to the output directory. This is useful for release builds because the installer project pulls all DLL and EXE files from the build output directory. My python script previously copied the BouncyCastle.NetCore and Titanium.Web.Proxy files to my test PC in addition to all the DLL and EXE files for the application.

The problem is that the Debug DLLs for BouncyCastle.NetCore and Titanium.Web.Proxy are not signed. When a .NET assembly depends on another assembly and the dependent assembly is not signed .NET will throw a “FileLoadException: A strongly-named assembly is required. (0x80131044)” exception when the first assembly attempts to load the dependent assembly.

It took me four hours to find out why this exception was occurring.

Providing Accessibility Information in a .NET Windows Forms application

Windows Forms applications provide two mechanisms for providing accessibility information.

In many cases the required accessibility information can be provided using the following properties of the Control Class in the System.Windows.Forms Namespace: the Control.AccessibleDefaultActionDescription Property, the Control.AccessibleDescription Property, the Control.AccessibleName Property, and the Control.AccessibleRole Property. This feature is almost enough to meet WCAG Success Criterion 4.1.2: Name, Role, Value. WCAG Success Criterion 4.1.2: Name, Role, Value requires that state information be provided as well. Unfortunately, there is not a property in the Control Class for state information.

In many cases, the built in Windows Forms support is sufficient and therefore there is no need to specifically provide state information.

If you do need to provide state information, it will take a bit more effort. In this case, you will need to use the AccessibleObject Class and the Control.CreateAccessibilityInstance Method.

Using the Accessible* Properties of the Control Class

The following code demonstrates the use of the Control.AccessibleDescription Property and the Control.AccessibleName Property of the Control Class.

In this case, the checkbox object provides the state. However, since an image is used instead of text, it does not provide the name. Therefore the Control.AccessibleDescription Property and the Control.AccessibleName Property of the Control Class are used. In addition, these properties suffice to meet WCAG Success Criterion 4.1.2: Name, Role, Value.

References