C# 2.0 Settings Quirk

One of the nice new features in C# 2.0/VS2005 is the visual settings editor for persisting application and user settings between sessions.

This post is not a discussion about this facility, it is an observation of a problem that can occur and a way to solve it.

If you have a custom class in your project, and you want to persist an instance of this, you would do the following:

In the Settings tab in project properties :-

• Enter a Name (e.g. SavedMyClass)
• Choose Browse... in the Type column
• In the 'Select a Type' dialog, type your fully qualified class name (e.g. WindowsApplication1.MyClass)
• Set Scope to 'User'

And you have now created a strongly typed setting in Properties.Settings.Default.SavedMyClass that you can access on application startup and will be saved during a call to Properties.Settings.Default.Save().

The problem occurs when you build the app. All being well, the build will succeed; but you should see many warnings like the following:

The type 'WindowsApplication1.MyClass' in 'C:\Documents and Settings\carlw\My Documents\Visual Studio 2005\Projects\WindowsApplication1\Form1.cs' conflicts with the imported type 'WindowsApplication1.MyClass' in 'C:\Documents and Settings\carlw\My Documents\Visual Studio 2005\Projects\WindowsApplication1\bin\Debug\WindowsApplication1.exe'. Using the one in 'Form1.cs'

The reason for this is that the output exe from this project is automatically added to the References for the project, thus creating the conflict.

This is easily solved by just removing this reference (e.g. WindowsApplication1) from the references in the project, although this may not be an immediately obvious solution as you would (or at least I did) expect this reference to be recognised is local.

Just incase anyone comes across this.

Auto-update update...

I posted some time ago about the problems with Microsoft Windows XP auto-update (link). It appears that Guy Kewney from Newswireless.net has had a similar problem, as he posted in an article on TheRegister.

Just an update....

ToolStripMenuItem shortcuts remain active

Frans Bouma blogged the other day about a bug that he had found within the ToolStripMenu in .NET 2.0.

When a top level menu on the strip is set to Enabled = false, pressing the shortcut key for any of the child menu items still causes the event for that item to be fired.

He also updated this article with a link to a workaround that Jfo posted

Thanks guys, that's the sort of problem that drives you mad!

Pet Hate #457

Google.

Well, not really Google, just the quality of some of the results that get returned. In particular, there are two types of return that should, in my opinion, be restricted in some way.

Time limited results

These are the results where the linked page is one that contains a 'Latest News/Articles' type section. There is little worse than following a link that seems to relate to exactly what you are looking for, only to be presented with a list of recently posted articles that has obviously changed since the last time Google came a-calling.

Log-in

Many a time, I have followed a link from the results where the abstract contains what seems like just what I'm looking for, only to be presented with a 'To access this page, you must be logged in first'.

Frankly, I don't care whether it is a free registration and the process only takes a minute to gain access to this and 50,000,000 other articles; if it's good enough for Google, it should be good enough for me.

Google seems to be slowly loosing it's grip on the most useful search results - if they're not careful, by the time they hand over search details to anyone that wants them, the data will be crap anyway.

</rant>

Microsoft Downloads

So today I was following a couple of mini-tutorials for the Workflow Foundation by Sahil Malik, which required that I had .NET 3.0 (hmm), and the Visual Studio 2005 Extensions for WF installed.

Obviously, I had .NET 3.0 installed, because even though it's pre-release, it contains the RTM of .NET Framework 2.0; so I didn't see any reason not to install it at the time.

I went onto msdn.microsoft.com to find the VS Extensions and did a search for 'Visual Studio Extensions for Workflow'. This gives quite a few results, the top ten or so looking like what I'm after, so I went to the top link.

The file there was 'Visual Studio 2005 Extensions for WIndows Workflow Foundation Beta2_2(EN).exe', which is what I was after. I downloaded that (~67Mb) and ran through Sahil's examples easily. I have since found out, however, that the latest release available is RC4.

This just leads me to wonder whether - for a company that produced many, many iterations of each product before they release it - there should be some sort of visual cue to indicate that this is not the latest iteration. The sort of thing that we get in technical docs would be fine - 'This method is deprecated, use blah blah blah instead'.

It just seems like something that would be of benefit.