EventSetters in Theme ResourceDictionary

Question

MSDN says on event setters:

Event setters cannot be used in a style that is contained in a theme resource dictionary. This is because a theme resource dictionary at run time is often loose binary XAML (BAML) files, and does not have any scope defined where accompanying code-behind that defines the handlers can exist.

This is confirmed by the first answer to this SO question, which states:

a resource xaml can't have a code behind file, they are usually called "loose xaml". You can read about that in the msdn about EventSetter.

However, I do not yet understand the limitations to event setters. I have tried using a code-behind file for a resource dictionary. I have assigned an event handler for an event of a control contained within a template defined within a style in said resource dictionary - and it worked.

Adding an event setter to a style in the same resource dictionary, on the other hand, results in an exception.

Have I hit a special case where it happens to work?

Or does setting an event handler in a template always work, but if so, then why can't I use an event setter in a style in the same resource dictionary?

My question boils down to:

What exactly is meant by MSDN's statement that a theme resource dictionary is often loose binary XAML - how often, under what circumstances exactly?

Answer 1

It means that it is compiled on its own not with a code behind or within the namespace.

Or to put it another way there is no code portion to a loose xaml file, it could be read in from a database as text for instance or generated on the fly as text and loaded without any codified association.

as to weather it is a valid reason or not. That's up to each developer but this is what loose xaml means.

Edit:

In response to your comment, I would imagine they are specifically referring to Resources and Styles as these are the most common "loose files" and in general most people do not back them with a code file. Personally I view it as a cope out. They could have easily added a Loose=True attribute and solved this problem.

Realistically the issue is not with the volume of loose files or the frequency with which they are used, it has to do with the fact that a rule was made to compensate for a missing feature. It would be much easier if they just said you cannot do x,y,z because we haven't built support for it, rather than saying it is because of some arbitrary number of loose xaml files.