Live Chat Programs

Also see: The Internet is Officially Dead & Boring - Its the economy stupid !

I recently ran into what appears to be a bug in Silverlight 2 Beta 1’s handling of cross-domain web service access when using a clientaccesspolicy.xml file. I’m hoping this post might save a few other people the time it took me to work out what was going on here.

Here’s the executive summary: if the web service exposes resources whose URIs contain semicolons, you will not be able to access those resources cross-domain if you’re using clientaccesspolicy.xml. The workaround is to use crossdomain.xml instead.

Now for the more detailed version.

In case you’re not familiar with cross-domain web service access, here’s the basic idea. By default, a web browser won’t let client-side code go connecting to any old web site. Client-side code is allowed to make requests against the web site from which it was originally downloaded, and it should only have access to other sites if those sites opt in.

In pure AJAX sites, this is often achieved using a faintly smelly hack where web services return runnable script rather than simple data. Flash introduced a somewhat more formal mechanism by which a web site can declare that it’s happy to be accessed by client-side code from other domains. Silverlight now supports this feature as of v2 beta 1.

Here’s an example. If your web site offers a resource called /crossdomain.xml containing this:

<!DOCTYPE cross-domain-policy SYSTEM
 \"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd\">
<cross-domain-policy>
 <allow-access-from domain=\"*\" />
</cross-domain-policy>

(more…)

Also see: Alexbarn Leaves Microsoft…ARGH!

Be careful - these aren’t the same thing.

• LoadFrom() goes through Fusion and can be redirected to another assembly at a different path but with that same identity if one is already loaded in the LoadFrom context.
• LoadFile() doesn’t bind through Fusion at all - the loader just goes ahead and loads exactly* what the caller requested. It doesn’t use either the Load or the LoadFrom context.

So, LoadFrom() usually gives you what you asked for, but not necessarily. LoadFile() is for those who really, really want exactly what is requested. (*However, starting in v2, policy will be applied to both LoadFrom() and LoadFile(), so LoadFile() won’t necessarily be exactly what was requested. Also, starting in v2, if an assembly with its identity is in the GAC, the GAC copy will be used instead. Use ReflectionOnlyLoadFrom() to load exactly what you want - but, note that assemblies loaded that way can’t be executed.)

LoadFile() has a catch. Since it doesn’t use a binding context, its dependencies aren’t automatically found in its directory. If they aren’t available in the Load context, you would have to subscribe to the AssemblyResolve event in order to bind to them.

So, which one should you use? That depends on which binding context is right for you and whether it matters that the LoadFrom context may redirect the bind. Regarding the latter:

Also see: Bloggers in the Mavs Locker Room ?

It’s hard to decide how afraid to be of something that is
really bad and really rare.

This problem is currently one of the most controversial
issues in the United States.  Ever since September 11,
2001 , we have been wrestling with the question: How afraid of terrorism
should we be?

• We all agree that terrorism is really bad.  What happened
  on 9/11 was awful.
• But it’s also really rare.  I personally have never met a
  Muslim who wanted to hurt me.

How afraid should we be? 

• Some people are very afraid.  They focus more on the
  "really bad" side of the issue.  Many of these folks are willing
  to give up their own civil liberties just to feel safer. 
• Others are not afraid at all.  They focus more on the
  "really rare" side of the issue.  They prefer to spend their
  resources and attention in other areas.

This blog entry is not the place for me to take a stance on
any of these issues.  For now I will simply say that I understand both
perspectives.  This whole situation is simply the most obvious example of my
point, which was:

It’s hard to decide how afraid to be of something that is
really bad and really rare.

Issues like these are like an icy ski slope.  Some people
stand at the top.  Some people stand at the bottom.  Very few people stand
anywhere else.  It’s too slippery.

(more…)

Also see: Channel 9 Interview

Sliced bananas on opaque data (The expression lemma). Ralf Lämmel and Ondrej Rypacek.

Algebraic data types and catamorphisms (folds) play a central role in functional programming as they allow programmers to define recursive data structures and operations on them uniformly by structural recursion. Likewise, in object-oriented (OO) programming, recursive hierarchies of object types with virtual methods play a central role for the same reason. There is a semantical correspondence between these two situations which we reveal and formalize categorically. To this end, we assume a coalgebraic model of OO programming with functional objects. In practical terms, the development prepares for refactorings that turn sufficiently disciplined functional folds into OO programs of a designated shape (and v.v.).

I haven’t even glanced at the paper yet, but it looks extremely interesting, and it’s directly related to some recent discussion. This blog post from Ondrej is also relevant.

Also see: Playing Multiple Simultaneous Sounds in WPF

One of
the suggestions for a blog entry was the managed memory model.  This is timely, because we’ve just been
revising our overall approach to this confusing topic.  For the most part, I write about product
decisions that have already been made and shipped.  In this note, I’m talking about future
directions.  Be
skeptical.

< ?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" /> size=2> 

So what
is a memory model?  It’s the
abstraction that makes the reality of today’s exotic hardware comprehensible to
software developers.

size=2> 

The
reality of hardware is that CPUs are renaming registers, performing speculative
and out-of-order execution, and fixing up the world during retirement.  Memory state is cached at various levels
in the system (L0 thru L3 on modern X86 boxes, presumably with more levels on
the way).  Some levels of cache are
shared between particular CPUs but not others.  For example, L0 is typically per-CPU but
a hyper-threaded CPU may share L0
between the logical CPUs of a single physical CPU.  Or an 8-way box may split the system into two
hemispheres with cache controllers performing an elaborate coherency protocol
between these separate hemispheres. 
If you consider caching effects, at some level all MP (multi-processor)
computers are NUMA (non-uniform memory access).  But there’s enough magic going on that
even a Unisys 32-way can generally be considered as UMA by
developers.

(more…)

Also see: Passing the Community Torch: In Search of a New Chief Executive in Redmond

Also see: Framework Design Guidelines: LINQ

Also see: Manual CRUD operations with the Telerik RadGrid control

Actually, I didn’t make it to be fun or silly, but rather to create a neat little client-side application for a good friend of mine. Could have just as easily written a basic PRNG index swizzle and gotten identical results, but it seemed like this chance tree is going to just make my life entirely easier if I have it always available as a tool. Not going to worry about implementing the swap filters and other features, but if you need to do some random selection in a web browser, maybe you’ll find it useful.

Code-Only: Client-Side OO Javascript Vector Chance Tree for probability selection.

Also see: A VS.NET Macro to Generate Machine Keys.

I recently made the verbal error of saying that for the new BASE element changes in IE 7 you had to put your tag inside the HEAD element. Well, someone pointed out to me rather quickly that on Firefox you could just have a bare TITLE and BASE followed by some body content and away you go the page would validate and parse properly. Well, we do the same thing in IE, and it is called implied tags in HTML. There are some gotchas though.

First, I’ll start with the trick… What in the heck is IE doing?
<HTML id=”dumpInternals”><TITLE></TITLE><BASE href=”foo”><BUTTON onClick=”alert(dumpInternals.outerHTML)”>Click Me!</BUTTON></HTML>

That is your boilerplate. When you click on your button there you’ll find that IE is actually putting the TITLE/BASE in the implied HEAD of the document and then putting the BUTTON into the implied BODY. Good stuff, and the document is still perfectly valid. Issues can arise when you do this though because you aren’t necessarily realizing what elements belong in the HEAD and which belong in the BODY and so you might terminate your HEAD enclosure early and put a bunch of random elements that don’t belong in the BODY into the BODY.

This won’t look right without your IE 7 Beta 1, since the BASE element is going to wrap a bunch of stuff, but you can get the gist. The below will show you that the second BASE ended up inside of the BODY. That isn’t good, we don’t look for BASE elements there and it won’t get used. (Read my previous post on IE 6 behavior and you’ll see that it used to get used because of some container magic, but not anymore, we are compliant).
<HTML id=”dumpInternals”><TITLE></TITLE><BASE href=”foo”><BUTTON onClick=”alert(dumpInternals.outerHTML)”>Click Me!</BUTTON><BASE href=”foo”></HTML>

Also see: Life Calculus

There was a time not so long ago when we built “home pages”.  Glorviously extravagant, naievely simple web sites that said who we were, and what we were about.   On those home pages, we put news & announcements, and often, links to static pages of content.   If we wanted to interact with visitors, we included guest books, maybe a simple message board, or just displayed our email address prominantly so others could drop us a note.    All of this was created by hand with the expectation that changes would be few and far between.

Eventually this became such a common approach for building a web site, that we tried to standardize these things.  At the same time, we discovered that a frequently updated web site received more visitors than one that was static or rarely updated.  As a result, content-management features were added to speed updates, forums were improved to include user avatars, threading, and email subscriptions.  Finally, the news & announcements became data-driven, annotated with metadata, and archived for historical review.

The current incarnation of this evoulution is what we call the Weblog.   A weblog is still nothing more than an “about” page, news, articles, and forums, it just has evolved a few new facets and appendages to impower users to interact in new (and hopefully better) ways.   Today, we can hardly imagine a web site without at least 1 RSS Feed.  In fact, most web sites today (nearly) completely revolve around their News & Announcements and the related RSS feed.  Yet, we must remind ourselves that the RSS feed is useless by itself.  It is an evolution FROM a web site, not an evolution OF a web site.  It is nothing more than an alternative delivery vehicle for information, not neccessarily a replacement for the weblog (read web site).

Also see: Binding to .NET Frameworks Assemblies

First, obviously, find the two types for which the cast failed and verify that they are the same type or otherwise castable.

Next, if the type was just deserialized, also verify that its assembly successfully loaded in the target appdomain.

If everything seems fine, check to see if the assemblies for those two types are loaded from different locations and in the same appdomain. (The actual cast is done in just one appdomain, even if the exception happens when passing a type between two appdomains.) Even if the bits of those assemblies are totally identical, if they are loaded from different paths, they will be considered different, so their types will be considered different. (See Comparing Already-Loaded Assemblies.)

A quick way to check for that is to examine the loaded module window of a debugger to see if that assembly was loaded multiple times. If it was, break on module loads to get the callstack for the unexpected load. If that’s inconvenient, try getting the Fusion log.

Usually, the problem is that:

1. The assembly is available in the GAC (or the ApplicationBase) and loaded there by static reference (something was compiled against that assembly).
2. It has also been loaded dynamically by path, from another path (LoadFrom(), LoadFile(), etc.).
3. Then, the code tries to cast the type from (2) to the corresponding type from (1).

To fix this, once you find the offending caller, you will need to either cause the two types to be (more…)

Also see: Trust Microsoft with Claimspace (my response pending)

Also see: Tagspace, Meet Claimspace

Also see: Bloggers in the Mavs Locker Room ?

Say you’re debugging your application and you see that version 1.0 of an assembly is being loaded when you thought it should be version 2.0. Where is the reference to 1.0 coming from?

The easiest way to find out is to look at the Fusion log for this bind. If the version 1.0 assembly was successfully loaded, use the ForceLog/”Log all binds” option of FusLogVw. Then, look for the line in the log showing the calling assembly:

Calling assembly : referencingAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=12ab3bf24c56c45b.

It shows the display name of the calling assembly when available. It doesn’t tell you whether this is a static or a dynamic reference because Fusion doesn’t know or care (that doesn’t matter for binding purposes). So, this could mean that referencingAssembly was built against the other 1.0 assembly, or that it asked for it at runtime via Assembly.Load(), etc.

Sometimes the calling assembly is not specified in the log. There are a few possible cases where that happens:

• The assembly was requested by unmanaged code (interop).
• The calling assembly was in another appdomain (AppDomain.CreateInstance(), etc.).
• The calling assembly had not been loaded through Fusion (Assembly.Load(byte[]), Assembly.LoadFile(), etc.).