This is one of those “..note to self” blogs to document for future reference the meaning of the exception message:

Format of the initialization string does not conform to specification starting at index 0

To me this actually means:

When the provider is being initialized with a collection of key/value pairs, the string that defines those key/value pairs is not properly formatted.

Perhaps that would be obvious to most but in my case, the exception would be difficult to track down in the field since a provider to my provider was actually throwing the exception.  In particular, my provider (AspNetSqlMembershipProvider) had a properly configured ConnectionStringName attribute but the format of the corresponding connection string (in the web.config connectionstrings section) was not properly formatted as “data source=…”. (I had gone with the proverbial connectionString = "Foo" to see if/how it would blow.) 

In fact, it was the SqlClient Data Provider that was originating the exception, at least in my case.

I post this here so that if I get “oldTimers” or if anyone else suffers from the exception, it may help offer a clue.

Brian Mishler

 

 

In an earlier blog, I mentioned how through the use of Dynamic MasterPages, I could have my web site change its format based on some arbitrary condition such as the browser type. Here, I have assembled an example to illustrate Dynamic MasterPages in action.

 

For this sample, I have created a single web form that contains our page content. This form (childPage.aspx) gets its layout from a master page (masterpage1.master) but when a particular condition is encountered (query parameter “foo” provided), the child will use the layout from a different master page (masterpage2.master).

 

Since we might have dozens of pages that need to dynamically change their layout, I have created a class called “WebFormBase” that inherits from System.Web.UI.Form and as I add each new web form, I will have it inherit from my custom base class rather than from the default System.Web.UI.Form. Now when I add code into “WebFormBase”, my child form (and any other forms that derive from “WebFormBase”) will enjoy that code.

This is a good practice, especially in large web sites, for many obvious reasons.

 

To load our “childPage” with different query parameters, I created “default.aspx” with two hyperlinks.

1. The first hyperlink loads “childPage.aspx” with no query parameters.
2. The second hyperlink loads “childPage.aspx” with the query parameter, “foo”.

 

This figure illustrates how the same child page looks when different (dynamic) master pages are applied:

 

 

Here is my custom base class, WebFormBase, into which I have added a single event handler to check for the “foo” querystring parameter.

public class WebFormBase : System.Web.UI.Page

{

    protectedoverridevoid OnPreInit(EventArgs e)

    {

        base.OnPreInit(e);

        if (Request.QueryString.Get("foo") == null){

            this.MasterPageFile="~/MasterPage1.master";

        }

        else{

            this.MasterPageFile="~/MasterPage2.master";

        }

    }

}

 

The following code is for “ChildPage.aspx”, the web page whose layout is controlled by the two master pages. Notice that the MasterPageFile attribute is initially defined as “MasterPage1.master” and also that Inherits=”WebFormBase” causes the web form to inherit from our custom class rather than the built in webforms base class.

 

<% @ Page Language ="C#" MasterPageFile ="~/MasterPage1.master" Title ="Variable Page" Inherits ="WebFormBase" %>

< asp : Content ID ="foo" ContentPlaceHolderID ="ContentPlaceHolder1" runat ="server">

< div style ="background-color:White;padding:10px 10px 10px 10px">
This is the content that is embedded in the child page. Depending on the dynamically selected master page, my surroundings may differ.
</div>

</ asp : Content >

 

One final note is that since I have defined that ContentPlaceHolderID=”ContentPlaceHolder1”, the alternate master page must have a content place holder named “ContentPlaceHolder1” or the page will erupt at runtime.

 

Feel free to download and run the sample web site which is available as a Zip file near the bottom of this post. As always, any comments and opinions are appreciated.

 

 

 

So in another blog, I mentioned a technique where I could hide obsolete content throughout my site by simply placing ContentPlaceHolders into hidden panels in the MasterPage.  In that context, this practice might be a temporary fix pending a visit to each page in the web site.

Since our business involves a lot of mobility and we invite customers to visit our web site from their pocket pc, I’ve been thinking that this technique of "hiding" content placeholders might offer a better way to create a Pocket PC friendly user experience. 

Currently, I substitute the CSS file or even redirect the user to a special section of my web site whenever I detect they are using Pocket IE. You can see this in action if you visit http://www.pocketforms.net (first in your browser then from your pocket pc.)

With Dynamic MasterPages, I can programmatically select a specific master page based on the requestor's browser type.  The pocket pc (or smartphone) master page, for example, can reference a style sheet (.CSS file) which is appropriate for the device and also hide superfluous ContentPlaceHolders such as banners and advertising.  This approach works much better than a pure CSS approach since hidden content is omitted server-side and never sent to the client.

The following code was inspired by Keith Smith's presentation at the Orlando .Net User Group and can be used to programmatically switch to the Pocket PC friendly master page when a "Windows CE" (pocket pc) browser is detected.  In the following code, the master page, pocketpc.master, changes the layout, hides some of the content and references a CSS file with fonts and layout which are better suited for the smaller form factor of a pocket pc.

protected void Page PreInit(object sender, EventArgs e) {
    if(Request.Browser.Browser.ToLower.Contains("windows ce")){
        this.MasterPageFile = "~/pocketpc.master";
        }
        else {
        this.MasterPageFile = "~/MasterPage.master";
    }
}

In VB.Net, it looks like this:

Protected Sub Page PreInit(ByVal sender AsObject, ByVal e As System.EventArgs) HandlesMe.PreInit
    If Request.Browser.Browser.ToLower.Contains("windows ce") Then
        Me.MasterPageFile = "~\pocketpc.master"
    Else
        Me.MasterPageFile = "~\MasterPage.master"
    EndIf
EndSub

Notice that the opportunity to swap out the MasterPageFile occurs in the PreInit method which occurs early in the page lifecycle (before any custom controls are loaded.) This means that the code cannot be placed into a web custom control (which would be really convenient) but, instead must be placed into the inline code or code-behind file of each page. 
Rather than adding this code to each page, this begs for a technique you always hear Carl Franklin, Richard Campbell and their guests talking about on .Net Rocks. That is, to have all your web forms inherit from a custom class rather than from the default, System.Web.UI.Page. When you add behaviors such as variable MasterPages to your custom page class, then all of your (derived) web forms will inherit that behavior as well.  Since each of my pages inherit from a class called “webFormBase”, I simply added the code into the Page PreInit event within webFormBase and I get automatic master page switching.

Watch for another blog on this subject for a generic sample of this in action.

 

 

 

Last year, I re-designed our corporate web site to use the MasterPages feature in what was then the Beta version of Visual Studio 2005. I did not bother to read the documentation (which is a testament to their ease-of-use) and if I had, I might have discovered how default template placeholders work.

 

Like a lot of folks, I created a Master Page first and then created web forms that "used a selected master page". When you create a new form in this way, content panels which correspond to each of the Master Page's ContentPlaceholders are automatically inserted into the page. The next step is obviously to add a bunch of page-specific content into each panel. This was very intuitive and for me, my efforts were well rewarded when I later changed the layout of my master page and everything fell into place.

 

At last week's Orlando .Net User Group (ONETUG) meeting here in Orlando, Microsoft's Keith Smith gave a really great presentation on Master Pages and Atlas. He demonstrated how to add content into the ContentPlaceHolders of the Master Page, then, by simply omitting the corresponding content panel on a detail page, the (default) content of the Master Page's ContentPlaceHolder is rendered in its place.

 

Since I had gotten into the habit of adding an empty ContentPlaceHolder to the Master Page then updating each web form with the corresponding content, I might never have realized that the ContentPanel on each form is optional. A few months ago, in fact, I systematically updated every one of my web pages with a ContentPanel corresponding to a new ContentPlaceHolder. Ironically, most of the new content panels received the same user control which, of course, could have been the default content of my new ContentPanel.

 

Live and learn!

 

Going the other way, I had a situation where I needed to get rid of obsolete Content Panels on my web pages. Each of my pages included a content panel into which I had placed an image control with a unique graphic for the page.  When I deleted the corresponding ContentPlaceHolder from the master page, each of my pages complained that the ContentPanel had an invalid ContentPlaceHolder attribute. While I would ultimately want to visit each page and delete that ContentPanel (or recycle it with different content), I was able to instantly omit the content by restoring the ContentPlaceHolder in my master page and placing it into a hidden Panel Control.