BKDC

"exePath must be specified when not running inside a stand alone exe."

Ever seen this exception before? I sure didn't....before yesterday, that is, when my custom wrapper over .NET's System.Configuration.Configuration class decided to go down in flames once used in a IIS hosted WCF service.

Why I'm relying on a custom wrapper is an entirely different story but seeing how many people are having problems dealing with the .NET's default Configuration object, I might just release it in the open if anyone needs it. Let me know.....

After a quick check I figured out that there's actually nothing wrong with my web.config file - it was my wrapper that didn't properly read the configuration file because.....Microsoft managed to introduce (patch??? bolt on???) one brand new way of figuring out on what plannet your config file is located. As if two was not enough.......

Welcome to VirtualPathExtension, the newest addition to the already schizoid family of Mr. OpenExeConfiguration, Mrs. OpenWebConfiguration and their lil' son HttpContext. There's little information out there about it but a couple of links were of great help:
WCF equivalent to MapPath? and Wenlong Dong's great post about reading configuration data from hosted WCF services.

public Configuration GetDefaultConfig()
{
    Configuration cfg;

    System.Web.HttpContext ctx = System.Web.HttpContext.Current;

    //WCF services hosted in IIS...
    VirtualPathExtension p = null;
    try
    {
        p = OperationContext.Current.Host.Extensions.Find<VirtualPathExtension>();
    }
    catch (Exception ex)
    {
    }

    if (ctx != null)
    {
        cfg = WebConfigurationManager.OpenWebConfiguration(ctx.Request.ApplicationPath);
    }
    else if (p != null)
    {
        cfg = WebConfigurationManager.OpenWebConfiguration(p.VirtualPath);
    }
    else
    {
        cfg = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
    }
    return cfg;
} 

If you don't like the try/catch part, check for null!=OperationContext.Current to see if you're in a hosted environment.

PS: relative paths stored in config & IIS hosted environments don't mix well. You can use HostingEnvironment.MapPath for that but more on this later.

UPDATE (thanks Ian G):

My tests were conducted with IE7/Firefox 3b5 and RC1. Unfortunatelly, I did not know about the fact that the beta/rc versions of Firefox 3 as well as Silverlight 2b1 seem to suffer from a few deadly bugs:

http://tempvariable.blogspot.com/2008/04/silverlight-and-firefox-3.html
https://bugzilla.mozilla.org/show_bug.cgi?id=424013
http://blog.sublimeintervention.com/userscripts/slff3unfuck.user.js

After running several tests on Seamonkey 1.1.9, IE7 & Firefox 3 RC2 all I can say is that both Seamonkey (and, I assume, 2.x versions of Firefox as well as IE7 can properly render Silverlight apps using the embed tag and data="data:application/x-silverlight," attribute. Firefox 3 RC2 simply crashes.

Well, Firefox 3rc2 also crashes if I try to......you know......browse web pages on the Internet :p, sneeze or simply try to start it.

<embed
data="data:application/x-silverlight,"
type="application/x-silverlight-2-b1"
src="uri_to_your_sl_control"
width="500" height="500"
source="uri_to_your_sl_control"
onerror="javascript:alert('error');"
background="white"/>

You can safely ignore the rest of the post.....


ORIGINAL Post below

For reasons not worth mentioning here, I had to embed a silverlight control without the use of javascript, iframes and/or the <object> tag. Since you're here, I assume that you already know that there's virtually null, nill, none, zero, 0 documentation out there about how silverlight can be used with the <embed> tag.

Frankly, I can't even say that I know the difference between <object> and <embed>. For all I care, it's just politics but, as I found out, they do seem to work in slightly different ways.

In case you wonder, here's the MSDN official way of instantiating a silverlight plugin: http://msdn.microsoft.com/en-us/library/cc189089(VS.95).aspx Yup, it seems a bit outdated but that's a different story.

What I needed was a way to instantiate the control using the <embed> tag. Without further delay, here's the working result:

<embed id="slp" data="data:application/x-oleobject;base64,QfXq3+HzJEysrJnDBxUISgAIAAAYLgAAQ1gAAAwAAAB3AGgAaQB0AGUAAAAAAAAAAAAAAHwAAABoAHQAdABwADoALwAvAHAAYQB5AHUAcAAuAHUAYgBpAHEAdQBpAHQAeQAuAHIAbwAvAEMAbABpAGUAbgB0AEIAaQBuAC8AYwBvAG0ALgBiAGsAZABjAC4AdwBpAGQAZwBlAHQAcwAuAGEAZABkAGU"
type="application/x-silverlight-2-b1"
src="[uri to your silverlight control]"
width="400" height="120"
source="[uri to your silverlight control]"
onerror="javascript:alert('error');"
background="white">


As you can see, it's a fairly standard 'translation' that mapped all the object params to attributes. The only difference is in the data attribute. Microsoft says that the data attribute "Streamlines the instantiation process. The data attribute is required, and it is recommended that the value be the Silverlight application MIME type - data:application/silverlight."

I tried setting the value to "application/silverlight," as recommended but without any success; the control simply didn't show up. Using IE Developer Toolbar I discovered that the actual value for data is "data:application/x-oleobject;base64,QfXq3+HzJEysrJnDBxUISgAIAABXKQAAAh8AAAwAAAB3AGgAaQB0AGUAAAAAAAAAAAAAAE4AAAAvAEMAbABpAGUAbgB0AEIAaQBuAC8ARgBsAGEAdwBsAGUAcwBzAEMAbwBkAGUAUgBlAGcAZQB4AFQAZQBzAHQAZQByAC4AeABhAHAAAAAYAAAAAAAAABYAAABfAF8AcwBsAEUAcgByAG8AcgAwAAA"
Not sure what it is, what it does or how it got there but it works. Enjoy!