Specifying Application Settings in web.config

As you may know, the new Configuration Settings functionality added in .Net 2.0 brought strong-typing to configuration values.  So, rather than just having

  <add key=”setting1″    value=”123″/>

we now can have a typed value

      <setting name=”setting1″ serializeAs=”int”>
        <value>123</value>
      </setting>

This has a lot of value from a programming perspective, because we do not have to deal with parsing strings and converting them, etc; the framework does it for us, and we also have compile-time checking.
Also, there is a simple UI for a Project – Properties – Settings, where we can specify the various settings which creates a new ApplicationSettings section with the values.

Unfortunately, all this has also caused a lot of confusion in the community, especially when there are multiple calling apps.
I, too, faced challenges with this to work and here’s my story…

In my scenario, I have a component in a Dll project with it’s application-level Properties. The component is consumed by both a Web Application project and a website project. At runtime, the caller needs to pass in the required values. The trick is to add the settings from your dll.config to the caller config.
For a web application or website project, copy the entire applicationSettings section from the dll.config.
Also, you also need to add a definition for an applicationSettings section, in the web.config, like so:

<sectionGroup name=”applicationSettings” type=”System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″>
  <section name=”foo.Properties.Settings” type=”System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ requirePermission=”false” />
</sectionGroup>

This should be added as a new node in the <configSections> node.

Now, the required values should be picked up in the dll code at runtime.

Troubleshooting:
If you get a compile error stating that there is an unknown section in config file, ensure you have declared/defined the sectionGroup properly.

If things still don’t work, ensure (as in one of my previous posts) that the node name + setting name = the fully qualified name of the property of the settings class.
For e.g.

<applicationSettings>
  <foo.Properties.Settings>
    <setting name=”setting1” …>

would map to a property called setting1 in a (partial) class called Settings in the foo.Properties namespace, defined in a file settings.designer.cs.

Hope that helped clarify some of the mysteries around config settings

 

LINQ and Database Connection Strings

If you use LINQ in a data-access component, and are looking to manage connection strings in various projects and environments, this article is for you…

When you create a new ER mapping in LINQ (as a dbml), you may end up with the connection string in the app.config file of your DA component. When your website or other client project uses this component, it can get quite confusing to know where the connection string is picked up from, and you most likely have pulled out your hair out in that process.
It is likely that the connection string is actually hard-coded in your Settings.Designer.cs file in the Properties folder in our project. There is a default setting attribute for the connection key property in your settings class, and if the required key is not found in your configs at run-time, this default value will be used.
So, what are the best practices to specify connection strings for LINQ? Here is my solution…

The key is to have the right settings key (no pun intended) in the connectionStrings section in your client config file.
Something like:

<connectionStrings>
  <add name=”NamespaceFoo.SettingFoo.ConnectionFoo” connectionString=”DataSource=xxx;blah-blah”
    providerName=”System.Data.SqlClient” />
</connectionStrings>

To figure out the precise key name, open your Settings.Designer.cs file. Note the Namespace, the partial class name and the name of the related connection string Property. Concatenate these together with periods and you have your config key. e.g. Outerspace.Settings.EarthDBConnection

Add this setting to the config file of your calling project, e.g. web.config of your main website. At run-time, the connection string value for that key will be used by your LINQ data context.

As you’re aware, different environments like dev, integration, qa, staging, production, etc. have different connection strings. You could change the value of the connection string but how do you maintain the various values? In the past, I have had these all in the config files and commented and uncommented them as required, but that was clunky and exposed them to everybody.
A good solution to this is to have different config files for your environments with the required security privileges and to specify which one to use in your config, like so:

<connectionStrings configSource=”dev.config” />

Create a dev.config in the same folder and specify the value in there. Note, that it should be the entire xml node

<connectionStrings>
  <add name=”xxx” connectionString=”yyy”
    providerName=”System.Data.SqlClient” />
</connectionStrings>

For QA, create another file qa.config with the required settings, and simply change the configSource value to point to qa.config. That way, you just need to change this value in a post-deployment step. Of course, your constraints for security and who sees the config files may be different but you have all the building blocks to adapt to your modus-operandi.
Hope that helps…

 

Insight Into Floating-Point Arithmetic

This is a quick plug for an excellent article I came across, that explains how computer systems deal with floating point operations and all that happens under the hood for precision.
It is lengthy and parts of it might twist your neurons, but I highly recommend giving it a glance at least: http://docs.sun.com/source/806-3568/ncg_goldberg.html

 

Deploying a RIA Services app

I have a creaky old Win 2003 Server dev box that I wanted to deploy my RIA solution to. I could not do a build and publish on the box itself because I did not want to install the RIA services, etc. on there.

So I did a publish on my local environment, which produced a folder with the required aspx files and a bin folder with all the RIA Dlls (include data annotations and domain services) and a ClientBin folder for the Silverlight XAP client payload.

I copied the folder as-is to my web server and created a virtual folder and an Application (in IIS) for it.

But when I browsed to it, I got an error in my browser stating:
Message: Unhandled Error in Silverlight Application
Code: 2104   
Category: InitializeError      
Message: Could not download the Silverlight application. Check web server settings    

This is slightly misleading since you might think there is something wrong with your application, but in fact it happens because the web server is not serving the required payload properly. It is because your web server may not have the required MIME types for Silverlight configured.
To fix this problem, right-click on your application, and click the MIME types button in the HTTP-headers tab.
Add the following:
.xaml    application/xaml+xml
.xap    application/x-silverlight-app
.xbap    application/x-ms-xbap

Now, the web server should be able to serve all the required files for the Silverlight client to run.

 

Silverlight Error AG_E_PARSER_BAD_PROPERTY_VALUE (Bad Property Error) with RIA Services

I was merrily chugging along developing my app with RIA Services, and I started getting AG_E_PARSER_BAD_PROPERTY_VALUE errors. The error seemed like a XAML error and stated Bad Property Error and the line and column where it occurred. But it was the line where the DomainContext was specified, like so:

<riaControls:DomainDataSource.DomainContext>
    <App:fooDomainContext/>
</riaControls:DomainDataSource.DomainContext>

The error was being raised when the Domain Data Source was initializing, but it was cryptic and just had the line and column number.
To get better error details, move the Declarative XAML (above) to the code-behind, so it is like:

fooDomainContext dc = new fooDomainContext();
this.dds.DomainContext = dc;

Now, if there was a problem with Domain Context, you will get a more meaningful error message.

Another tip: If you get an error because an unknown method was being called on the Domain Context, remember the proxy code is auto-generated and the name of the query methods are created by convention, and so a method in your web service Domain Context getFoo() will be named getFooQuery() in the client code. 
If you cannot figure out what the name is, go to the Silverlight client project and click on “Show all Files” This will show hidden auto-generated files and the Domain Context proxy would be under the hidden folder “Generated Code” – foo.Web.g.cs, where foo.Web is your Web Service project. Open the hidden file, located the Domain Context class and see what methods it provides. Hopefully, you can locate the query method name.

Hope that helps…

 

WPF ListBox problem: Items collection must be empty before using ItemsSource

One issue I came across while using a ListBox with a DataTemplate, instead of a DataGrid was a compiler/xaml error stating that the Items collection should be empty…

This was a little baffling and I was wondering if there were data-binding problems in the code-behind, etc. Turns out the source of the problem was in the XAML.

I had:

<ListBox x:Name=”foo”>
     <DataTemplate>

and I needed to add in a ItemTemplate container tag, like so:

<ListBox x:Name=”foo”>
     <ListBox.ItemTemplate>
          <DataTemplate>

I think the error was happening because the framework was considering the DataTemplate as an item in the list, and hence the Items collection was not empty and messed with the binding.
Adding the ItemTemplate tag specified it as a template, and not a list-item

 

Lenovo T500 + ATI * Vista Aero = BSOD

I’ve been having major problems with my Lenovo laptop running Windows Vista. Every once in a few days, I get display freezes with “Display driver has stopped working” type of messages and the occasional BSOD (Blue screen of Death). I would get a message stating that the display driver (amdkmdap.dll) had stopped working.

The problem is a known Lenovo issue and is discussed here: http://forums.lenovo.com/t5/T400-T500-and-newer-T-series/R400-T400-T500-W500-display-driver-quot-amdkmdap-quot-crashes/m-p/103845

This, apparently, is a problem with the ATI graphics card drivers when they render Vista Aero, and can be fixed by going to the Lenovo support website and downloading the fixed drivers:
http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-71851

(If you’re worried about installing this stuff, try turning off Aero from the Display Settings and see if that works.)

This will install drivers for the ATI Catalyst suite.
I got errors when I ran the installer, and these were due to mismatched MFC dlls in the installer package and my computer.

After searching around, someone recommended to install the updated dlls from the Adobe website: http://www.adobe.com/support/products/enterprise/support_knowledge_center_livecycle_ES_server.html

I know it sounds weird, but it works. Adobe installers  had similar problem, and so released the fixes. Now, you should be able to run the ATI installer, which has pretty cool graphics in there.

Anyway, hopefully this fixes the display problems I’ve been having…

 

Silverlight Error: The name ‘InitializeComponent’ does not exist in the current context

After porting an old Silverlight application, I started getting compiler errors stating “The name ‘InitializeComponent’ does not exist in the current context”.

This was baffling and after poking around a bit, this is how I resolved it.
Note: My solution may be specific to my Silverlight installation and computer setup. I never quite know what the various bits are.

Essentially, the build is not generating the hidden partial classes named foo.g.cs for the application or page foo.xaml. These contain the InitializeComponent and are hidden files under the obj/Debug folder.

To fix the problem, right-click on the project with the errors and select “Unload”
Then right-click and select “Edit xxx”. This will load the project file xml in the IDE.

Locate the item <ItemGroup>, which is somewhere towards the bottom.
You will see blue squiggly lines under the Application element and the Page.

Change them to be <ApplicationDefinition Include=xxx> and <Page Include=xxx>
Note: There will be a blue squiggly line under <SilverlightApplication>true</SilverlightApplication>, but no need to fix that

Save the xml and right-click the Project and select Load. Say ok to unload open file and load and compile project.” Hopefully your problem was resolved.

 

Developing rich client–server apps with Silverlight, using RIA Services versus Adobe Flex Builder

Microsoft Silverlight and Adobe Flex are currently the 2 good options to make a rich client-web sevices app.

If you’re a .NET shop like us, you most likely have your web-services in C#. If you have a rich-client, it is most likely built in Flex/Flash. This is most likely market/business driven but also Flex has a decent model for building rich Internet clients consuming web-services and is platform independent (we’re not considering phones in this because Flex/Flash is no workie on many of them yet).

Although, Silverlight might take a while to reach a tipping point in the marketplace, the medium itself and related technologies have matured a lot and are quite compelling as a development platform, and would be my personal choice.
Silverlight definitely has the edge over Flex in terms of development, because it integrates tightly with the .NET IDE so you  have just one development platform and language which itself is a big win from a HR and team standpoint.

For development purposes, Microsoft has provided a framework called RIA (Rich Internet Application) Services that makes it easier to write a Silverlight Client that integrates with your web service.
I highly prefer the type integration it provides through library references instead of wsdl, which you would if developing with Flex.
Reflecting changes in web services (during development) seems to be a hassle with Flex Builder, if you regenerate from the wsdl and only need to copy over the new stuff if you want to do it selectively; I think a part of this hassle is our process/implementation.
A big hole in the strong typing via the proxy is that the proxy itself could be out of sync with the service, which does happen often during the development phase, and lead to runtime errors.

Apart from types being shared between the client and the server code, things like Validation rules are also shared, which is quite powerful.

This makes it a no-brainer to use Silverlight for Management Console/Support apps (because they are in-house and under your control) if you really want to go rich-client, while it might take some convincing of the business to use it for web apps, which honestly might be impossible as of now. 

Anyway, sticking to development, here is a quick overview of the various pieces involved in a RIA Services solution.

Project
You use the Project – New – Silverlight Application template (like you always have for Silverlight projects). Following this, you will see the New Silverlight Application dialog.
It is important to check the box “Enable .NET RIA Services” at the bottom of the screen (which will show up only if you have RIA Services installed)
So, you will end up with a Solution containing 2 projects, viz. the Silverlight client with the RIA link enabled and the Website Server project.

Data model
Define your data classes with the ADO Entity Framework designer

Service
This is the critical part, where you choose: Web Project – Add New Item – Domain Service class. Enter required details, which also let you choose Entities to manipulate, and you will end up with a class inheriting from the LinqToEntitiesDomainService of your Data Context class type.
The service class is decorated with: [EnableClientAccess()]  which exposes it to the client.
A Getxxx() method is generated to provide data.
Application logic should be added in/below the service class.

You can run the Project and see that the data entities are available in the client and server. This is an important distinction from writing a Flex client where there is no type sharing, and is a huge benefit for development.
This should not be confused with “no strong typing” – strong typing in Flex will be with proxy classes generated from the WSDL obtained by referencing your web service.

Client
As mentioned earlier, type sharing is achieved by generating proxy classes in hidden code when you build the Project. The proxy classes include your DataContext, Entities, etc.
You can then access data from the Service by using a generic LoadOperation class which is in the System.Windows.Ria.Data namespace.

I have purposely kept this post at a high-level to get you started. There are a lot of details which I will delve into in future posts.

Some good resources are:
http://www.nikhilk.net/NET-RIA-Services-Vision-Architecture.aspx

http://blogs.msdn.com/brada/archive/2009/03/19/what-is-net-ria-services.aspx

http://www.silverlightshow.net/items/Creating-applications-with-.NET-RIA-Service-Part-1-Introduction.aspx

 

UTC Timestamps (in .NET) and going down the curried rabbit-hole.

A good practice for a web service is to provide and store data in a locale agnostic way, e.g. timestamps should be stored as UTC and the data should also be returned/serialized in an agnostic way, so the client can apply localization settings, user preferences, etc. This is a good practice so that servers are location agnostic and the client does the lifting.

In the past, I returned a DateTime with the specification that it was UTC, so the client blindly localized it.
I recently ran into a problem where our Flex/Flash client used the UTC indicator to localize instead of blindly doing it, which meant that my method had to return timestamps marked as UTC, i.e. with a “z” at the end. There is an issue with that if you use .NET to write your web service because the XmlSerializer cannot just take a Datetime type and serialize it as UTC.

In fact, .NET framework 1.1 had no way to designate a timestamp as UTC or local and this messed up web service designs and frustrated developers because data had to be converted to a locale before it was returned/serialized in a web service.
This issue was addressed in .NET framework 2.0 by adding a DateKind flag to a DateTime type. So, to serialize (and mark) a DateTime as UTC, you use:

DateTime dt = new DateTime(timestamp, DateTimeKind.Utc)

Now, if you are like me, you think it might be easier to add an extension method to a DateTime type in your service layer (or lower layers, if you really need it there), so you could provide the synctactic sugar elegantly write

DateTime dt = timestamp.UTCKind

But, unfortunately that does not work…
Why not?

From what I understand, extension methods are implemented in .NET as delegates with currying, which limits the first parameter (of a delegate) to be a reference type – ergo you cannot extend a value type or, in the case of Datetime, a struct.

So, what is currying? Is it dinner time yet? (if you like Indian or Thai food)

Going further down the rabbit-hole of functional programming, currying is “transforming a function that takes n arguments into a function that takes only one argument and returns a curried function of n – 1 arguments”.
In layman terms, when you curry a function, you return a lambda expression which is then used in the “higher” calling function.

A good explanation here: http://blogs.msdn.com/ericlippert/archive/2009/06/25/mmm-curry.aspx
and here: http://blogs.msdn.com/wesdyer/archive/2007/01/29/currying-and-partial-function-application.aspx

Origins of its name: http://c2.com/cgi/wiki?CurryingSchonfinkelling

Here are some related articles:

http://stackoverflow.com/questions/1016033/extension-methods-defined-on-value-types-cannot-be-used-to-create-delegates-why

http://blogs.msdn.com/sreekarc/archive/2007/05/01/extension-methods-and-delegates.aspx

So, ultimately, I created a utility method that takes in a DateTime and returns a UTC type DateTime, i.e. its kind is set to UTC.

public static DateTime UTCKind(DateTime dt)
{
    return DateTime.SpecifyKind(dt, DateTimeKind.Utc); //set time as UTC
}