This blog has, IMO, some great resources. Unfortunately, some of those resources are becoming less relevant. I'm still blogging, learning tech and helping others...please find me at my new home on http://www.jameschambers.com/.

Monday, February 28, 2011

Fixing “Unrecognized configuration section userSetting” Errors

Though I have not seen the error “Unrecognized configuration section userSetting” as a standalone exception, it has come up a number of times for me and surfaces as the inner exception on a “Configuration system failed to initialize” exception.

If you’re running into this error and following along, I’m currently using Visual Studio 2010, mostly on .NET 4.0 and I program in c#.  If you’re using a different environment some of the file names or UI might be a bit different, so you’ll have to adjust accordingly.

The exception will be raised in Settings.Designer.cs, on the first attempt to read a value from the application’s configuration.

You can fix the error by navigating to the current directory where the user settings are being saved for your app.  This will be in %system%\users\your_user\AppData\Local\Microsoft\YourApp.vshost.######\version

Delete the user.config file, clean your solution and rebuild all.  This should fix the problem.

If that doesn’t work, you may need to go so far as to shut down Visual Studio, clean out all the %system%\users\your_user\AppData\Local\Microsoft\YourApp directories of any config files and then follow the above steps.

What’s Happening?

When you first add a setting to the application through the UI, the default is to create a user-scoped setting.

image

User settings and Application settings are primarily different on two fronts:

  1. Storage location
  2. Run-time accessibility

User settings are read/write and can be altered at run-time. These are perfect to save things like favorites, window layout, user-specific options, color preferences and the like. These files are stored in a directory created for the application, basically sand-boxed from system-wide access and the only place your app can read/write from for free (elevated privileges aside).

Application settings are read only at run-time and can only be altered by changing the XML file and relaunching the application, or by some creative XML file management (and then a reload on your configuration data).  These files are stored in the app directory in app.config and also contain the default settings for users who have not yet launched the app (these are the settings that will be defaulted in for the new users).

I have hit the “Configuration system failed to initialize”Configuration system failed to initialize error a couple of times, and it always seems to be the User scope default biting me in the arse.

Basically, I create a setting, plug along for a while, then go back to add another setting and realize that I had left it in user scope.  I switch the first setting to application scope and keep plugging away.  Somewhere between then and the next time the application tries to access that property, the exception is thrown and doesn’t give you much detail at the surface level.

Figuring out the Files You Need to Delete

I said you can likely delete the user.config files without much regard.  Truth is if you’re into testing something settings-related that can be a real inconvenience.

I will drill into the inner exception to find the problem file; it’s only two deep, so it’s easy to find the path of the file in question if you’re willing to dig. 

Trust me, folks, your debugger is your best friend.

Friday, February 25, 2011

Windows Phone 7 - What if?

Nice. Looks like Microsoft is starting to ramp up the ooh-la-la with their advertising. Combined with the web-based ads with the head-to-head comparisons, the new Windows Phone 7 commercials are starting to look a little more playful.



Yeah. My phone does that. :)

Monday, February 14, 2011

An Azure Deployment Primer

From the Developer & Evangelism Labs: Introduction to Windows Azure

This post is a summary of the notes I took while working through the Introduction to Windows Azure lab in the January 2011 Platform Training Kit.  I ran into a couple of road bumps and bruises along the way and thought I’d share.

The Platform Training Kit – The download for the kit

The sample is a guestbook that lets you write your name, a message and post a photo.  A background service resizes the photo and the thumbnail is linked to the full size image.

The lab walks you through setting up the relevant bits of the application locally, then walks you through deploying it the application to the cloud.  I found it to be a good balance of hand-holding and explanation, but you may find many questions left unanswered. The Microsoft Platform Evangelism team has certainly lowered the bar for folks to get in over their head! Thankfully there are 26 other labs to help quench your thirst.

When you get it up and running, here’s what the end product looks like:

image

Well…that’s what it looks like if you post a picture of the snow on my roof with a name of MisterJames! 

Snags, Detours and Road Bumps

Documentation Gap

Following the lab from the first step and trying to use the project through all of the exercises has its pitfalls. First of all if you make a mistake, that carries through the whole way.  Secondly, when preparing for and throughout exercise 3 (deployment) there isn’t much clarity around the implications of misnaming your hosted service or storage account.  There are also rules around naming (they have to be DNS suitable names) but this isn’t clear through the docs.  Worse, the error you get when you make an account naming mistake is not very leading: One of the request inputs is out of range.  I was getting this error when making a call to CreateTablesFromModel, and nothing really pointed me back to the name.

You can, however, opt to jump in with the files provided for the lab.  At each step of the exercise the team has provided us with an updated, accurate solution to continue from.

This is good, as in step 3 it assumes you’re using that and doesn’t give clear instructions on the updates required in the service configuration file.  The nodes and values required are in the provided solution.

Error Loop on Deployment

After I completed the lab I started playing around with config files and some simple changes to the app.  In that process I managed to botch a deployment package (the configuration bits).  Unfortunately, I didn’t realize that until I had already deployed the package as an upgrade to the first version.  The instances were stuck in some updating/starting/waiting/resetting cycle that took over 40 minutes to work itself out. The result was an error state, which until reaching I was unable to stop and update the service.

A Missing Warning

I just want to add another voice to the mix here: remember to stop and delete your project as you don’t want to be incurring charges or burning up valuable compute cycles.

Time Expectations

This is a lab that is scheduled to take approximately 60 minutes.  In addition to the coding bits I took two phone calls, answered a few IMs and emails and was wrapped up on the code/deployment side of things inside 55 minutes. I did muscle through it pretty quickly, though, as I’ve done several of these labs and know the style. 

If you aren’t patterned to recognizing the parts you should and shouldn’t need to read, this lab could take up to 75 minutes to complete.  One other note: I already had my Azure account up and running, so I was able to skip that part of the task.

After plugging through the juicy bits, I then had to wait for the succession of updates, host starts, role starts and what not.  This easily pushed me over the allotted 60 minutes.

image

For all of these services to finish their progression to their final states took about 20 minutes, at which point we end up here:

image

Conclusion

Set aside a two-hour slice of time and you should be able to move casually through the lab, start to finish. The Introduction to Windows Azure does a great job of touching on many of the concepts you’ll be working with when you get into cloud development.  You will be left with questions around deployment and configuration, but this start is good exposure and the walkthrough doesn’t leave out any important steps.

Don’t forget to delete the services created in the lab!

Sunday, February 13, 2011

Mixin’ it up

Bootcamps. Keynote. Sessions I’m actually interested in. Meeting folks that I’ve only ever known online.  Should be a great event!

Tuesday, February 8, 2011

Parents, Open Your Eyes

I just read this blog post from over on ZDNet: It's time for iTunes and Xbox Live to put spending limits in place.  Mr. Adrian Kingsley-Hughes writes that:

There’s a fine line between something being lucrative, and starting to feel scammy. Apple is certainly sailing close to the wind with some of the in-app purchases it is allowing, and Microsoft could certainly do more to prevent this kind of bad publicity. [...] And it’s clear that the current mechanism of relying on parental controls isn’t enough. Both companies need to get their act together.

I would agree that parental controls are failing – couldn’t that be said about a lot of things? – imagebut we would stop short of flogging a parent who pulled off the same stunt at Wal-Mart and then tried to blame the store management. 

Could you imagine walking your child into the store, giving them a shopping cart and meeting them at the checkout – at which point you blindfold yourself and let the check-out clerk scan all items…and then your credit card?  And you don’t even check?

Look, I’m no fan of Apple, but I don’t think they (or Microsoft) are in the wrong here.  My wife has disabled in-app purchases and we don’t share our password for the iPod Touch or the Windows Phone 7 devices we own.  Not going to happen.

Our kids just don’t get unchecked access to our credit cards.  Period.

While Mr. Kingsley-Hughes refers to it as ‘insanity’ and points blame to the companies in question, I refuse to be an enabler for parents who want to make stupid, unconditionally blameless children.

Monday, February 7, 2011

Dedicated Back Button: Genius

My wife has an iPod Touch and we were running through some of the same apps that exist on iOS and Windows Phone 7.

At several points we both accidentally clicked the wrong link/button/UI element etc. on our own device.  There was one glaring difference, however; the iOS versions often land you in a place where you have to navigate through the home screen and back into the app where you accidentally made the click.

Not so, with Windows Phone 7: there’s a dedicated, hardware-based back button.  This makes it easy to back up through your screen progression to the last place you were at.

It’s so simple that you think that it wouldn’t be necessary, and yet, there she is…my wife pushing the empty space on her iPod like there should actually be something useful there.