Earlier versions of the SDK had Parser.LoadBaml, but the latest version does not. We want to have many XAML snippets (100's) stored as BAML resources and be able to load them dynamically by name. I can get Visual Studio to store a XAML file in a project as a BAML resource, but when I get a stream for that resource and call Parser.LoadXml (the only thing that looked like it might handle this), it doesn't work. Is there a way to get an object tree constructed from a compiled BAML resource
Alternately, will storing the XAML snippets at Application scope (myapp.xaml) in <Application.Resources> cause lengthy startup times Will construction of those resources be defered until they are requested Does the first request cause all of the resources to be constructed, or are they loaded one at a time Finally, is this behavior something to be counted on, or subject to change
Thanks.
- Gerald

LoadBaml gone?
Khalid K.
To create a logical tree from a given resource, you can use Application.LoadComponent(). This works with both BAML and XAML.
I don't know offhand the extent, but storing XAML snippets in your Application definition will cause lenghty startup times.
Regards,
Ashish Shetty
Program Manager, Windows Presentation Foundation
renju_dom
Application
.LoadComponent(new Uri(name+".baml", UriKind.RelativeOrAbsolute));ashk1860
Thanks.
Gerald
Cat the Dark
You say that web deployment model is weak Strange,I always thought that Avalon is simply managed web browser platform.It's not very useful to package everything in exe dll even from maintenance point of view,not talking about granularity of versioninig.Web platform is so successful because it's easy to deploy and manage=>it's highly dynamic environment,if avalon will drop web deployment model-it'll losing not gain in any means!It's very sad news for me,that avalon returns to desktop programming roots though it's grows up on web technologies.
Let's make it worse or more difficult to use than before Turn away from this road,while you can IMHO.
Best wishes.
Dim
>> storing XAML snippets in your Application definition will cause lenghty startup times. <<
Actually, I would be surprised if it did. In compiled xaml, we delay-load resources, so if it isn't used, it isn't loaded.
The reason we removed LoadBaml is because we want to strongly, strongly encourage everyone to only use baml inside their .exe's and .dll's, and not have .baml files floating around loose. There's both security and versioning concerns with loose .baml.