Tone's Notes

Are you having trouble getting app.config included in the installation folder of a Windows Forms 2.0 application created with Whidbey Beta 1 (you may see an “unable to access configuration section” error message when saving Properties.Settings)?

This might not be the best solution (I’m sure it’s not), but after spending too much time on it to start with, I just included the myexecutable.exe.config file explicitly from the “bin/debug” into the setup project. End of problem for me, but I’d love to hear how it’s supposed to work.

If you’ve been frustrated by Whidbey’s Windows Forms support for application settings management here’s a tip that may help you.

There are two major bits of functionality involved. The first is the support for reading and writing the xml configuration files for both user and application settings. The second is the support for creating Binding objects to tie the settings properties to various object properties in your application.

The Binding stuff is much more broken than the xml read/write stuff.

My suggestion is to not use the “Application Settings” on the Property panel. It invariably shoots me in the foot, scrambling the *.Designer.cs files with random settings getting stuck where they don’t belong.

Instead, take charge of manually transferring the properties to and from the Properties.Settings.Value object. Right after InitializeComponent(), copy them out, and right before Properties.Settings.Value.Save() copy them back.

All the truly mysterious behavior of when user config files were and were not written, as well as random changes to the applications UI, disappeared after I eliminated all the automatically generated Binding objects.

I did try manually creating the Bindings, but the bugs seem to be inherent in the code that identifies actual object fields to update based on the state of the Binding objects. It seems to just get it wrong with painful regularity.

It is just beta code after all J

Here’s an MSDN article that I found useful. Specifically, it answered why some settings are read-only wile others are read-write. Obvious once you think about it!

I’m looking forward to when it all works smoothly…

this.button1.DataBindings.Add(new System.Windows.Forms.Binding("Font", SettingsTest.Properties.Settings.Value, "ButtonFont", true, "", null, System.Windows.Forms.BindingUpdateMode.OnPropertyChanged));

I’ve seen a number of developers surprised by InvokeRequired returning false in situations when they know it’s a cross thread call.

The reason is that the underlying window handle associated with the control has not been created yet at the time of the call.

Since InvokeRequired is meant to be used with either BeginInvoke or just Invoke, and neither of these methods can succeed until a windows message pump gets associated with the control, it elects to return false.

There is some support for FTP in Whidbey beta 1, but it still failed my real world requirements.

Using both the FtpWebRequest / FtpWebResponse and WebClient classes failed to connect to an embedded system running an ftp server that Windows Explorer had no trouble connecting to.

I tried two third party FTP components for .NET (Mabry's FTP/NET and CSpot’s FTPComponent). Both components succeeded in connecting to the server when run as Visual Studio 2003 projects (using their own sample code). But both components failed (typically by hanging in the class constructors) when run after conversion to Visual Studio 2005 (Whidbey beta 1).

It seems that at the moment, there’s just enough FTP implementation in Whidbey to work with some FTP servers, but not all, and just enough changes to interfere with the existing crop of 3^rd party components.

These comments relate to Whidbey Beta 1.

Setting the SaveSettings property to true in the designer for a toolbar strip causes app.config to be rewritten with encoding Windows-1252 which seems to prevent the application from starting. You may see an error similar to the following:

Editing the app.config file to change the encoding back to UTF-8 may fix your problem.

In general, using C#, the support for user configuration settings appears to be very brittle in Beta 1.

ClickOnce Deployment

Trying to install an application that requires FullTrust from the internet or non-local UNC is still either very difficult or impossible.

Found the following reference:

Also, the manifests you create are strong named signed and ClickOnce will block the install of strong named signed manifests that request full trust permissions (like the ones we're making here) over the internet in Beta 1. We're working on ways for small shops to use ClickOnce over the internet in Beta 2 but the best way to get things going in Beta 1 is to zip up the files and place that zip on the internet and your users can download the zip, unzip it, and install the app. You'll still get all the benefits of ClickOnce updates and app management. (from Sampy's Blog)

Intalling from a downloaded zip did not help with security blocking access to updates. They are detected, but the same installation denied dialog appears.

There may be a way to adjust security settings to permit installation of “publisher unknown” applications, but I haven’t found it yet and the reference above suggests there may be no way.

Generic Windows.Forms

The IDE’s Windows.Forms.Form designer can’t handle generic classes derived from Form. An “Unknown Error” screen appears. Temporarily hiding the generic aspects of the class and rebuilding the project allowed the designer to work again.

Changing the signature of a Form derived class appears to be tricky when using designer generated partial classes. Adding a “public” modifier is okay so long as the designer file doesn’t use “private”. The class name and generic-type parameters must be identical but modifiers must only not conflict. It appears that base classes and implemented interfaces also don’t need to be identical as long as they don’t conflict (i.e. two different base classes).

In Visual Basic, event handlers are defined and registered declaratively in one step by adding a “Handles <instance>.<event>” clause to a Sub or Function declaration whose signature matches the event’s delegate.

Because the declarative style is used, as opposed to C#’s imperative style (event += new <delegate>), there is no control over the lifetime of the event registration. This can require additional code and effort when the lifetime of the event source extends beyond the lifetime of a resource required by the handler.

A second limitation of Visual Basic event handler support appears to be that a generic delegate defined in C# can not be used to define an event if you want Visual Basic clients to be able to bind to it.