×

First time here?

You are looking at the most recent posts. You may also want to check out older archives. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS or email. Thank you for visiting!

One of the new features I mentioned in my What’s new/changed post on Silverlight 3 is the fact that any application developer can take advantage of the cached assembly functionality provided by Silverlight.  Let me show you how and start with the current situation.

Current Situation with Silverlight assembly references

If you are building a Silverlight application, chances are you are referencing assemblies either from the SDK, Silverlight Toolkit or other great Silverlight third party controls/frameworks.  When you Add Reference to these controls/frameworks, their assembly is copied to your application and packaged up in your XAP.  For some situations this is fine and you have no reason to care at all…it just works.  When you look at the AppManifest.xml file for your application you’ll notice the AssemblyPart nodes for each referenced assembly not in the core – and these are in your packaged XAP file.  Take a look at my sample application which has a reference to a simple 3rd party assembly: TimHeuer.SimpleFunctions.dll:

   1: <Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" 
   2:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="SilverlightApplication1" 
   3:     EntryPointType="SilverlightApplication1.App" RuntimeVersion="3.0.40624.0">
   4:   <Deployment.Parts>
   5:     <AssemblyPart x:Name="SilverlightApplication1" Source="SilverlightApplication1.dll" />
   6:     <AssemblyPart x:Name="TimHeuer.SimpleFunctions" Source="TimHeuer.SimpleFunctions.dll" />
   7:   </Deployment.Parts>
   8: </Deployment>

You can see that my custom assembly is included in the manifest as a separate AssemblyPart entry.  Looking at the XAP package contents you’ll also see it there:

Current XAP package

This is how we’ve been building Silverlight applications since Silverlight classic…um…I mean, Silverlight 2.  All of this will still work and if you do nothing, then no worries.

Introducing Application Library Caching (or External Assembly Parts)

In Silverlight 3 beta we introduced this feature to reduce the initial XAP package size of your application by providing external assembly parts for certain Microsoft components and controls.  In beta, it was a feature only reserved for Microsoft-delivered assemblies.  Now that we’ve released, we’ve opened this feature to any developer wishing to take advantage of it. 

What does it do?  Let’s take a look at perhaps a common referenced assembly: DataGrid.  When you add this assembly to your application, your XAP package will increase in size because it is not a part of the core (mine went from 4K to 204K because DataGrid also brings some other assemblies with it).  In Visual Studio, take a look at the properties dialog for your Silverlight application and you’ll notice a new checkbox:

VS Settings reduce XAP size

By clicking this checkbox you are telling Visual Studio to make sure that any assembly that offers this feature, to not package it in your XAP but to reference it as an external assembly part.  The result is two-fold: your manifest changes and your XAP no longer includes this assembly.  Take a look at what happened to my sample application’s AppManifest.xml when I enabled that feature:

   1: <Deployment --attributes removed for formatting only-->
   2:   <Deployment.Parts>
   3:     <AssemblyPart x:Name="SilverlightApplication1" Source="SilverlightApplication1.dll" />
   4:   </Deployment.Parts>
   5:   <Deployment.ExternalParts>
   6:     <ExtensionPart Source="TimHeuer.SimpleFunctions.zip" />
   7:   </Deployment.ExternalParts>
   8: </Deployment>

Notice the new node ExternalParts?  There’s no reference to my TimHeuer.SimpleFunctions.dll but there is one to a TimHeuer.SimpleFunctions.zip file as an ExtensionPart.  This is because my assembly has chosen to opt-in to enabling this feature if the developer wants to use it in their application deployment.  My XAP file also reduced from 6K to 4K in size (note: in my DataGrid example you’d see a reduction of approximately 200K).  Using this feature, when users visit your web application, the application and package are downloaded.  These files are added to the browser cache so they can be used on subsequent requests.

How is this accomplished?

So what’s going on here?  It’s actually quite simple and there are two ways you can do it as an assembly author (well, really one way, but two methods of how to provide your assembly deployment).  First, you have to make sure that your assembly has a strong-name key.  This is probably good practice anyways for your development team.  This gives you a public key token which you’ll need for this feature.

The next thing you have to do is provide the external part manifest for your assembly.  This is a simple XML file that does not have to be included *in* your assembly, but needs to exist in the same physical place as your assembly (i.e., right next to it in the file system).  This file must also be named <AssemblyFileName>.extmap.xml.  As an example in my sample, my custom assembly is TimHeuer.SimpleFunctions.dll and my file will be TimHeuer.SimpleFunctions.extmap.xml.  The contents of the file is simple and here is mine for this sample:

   1: <?xml version="1.0"?>
   2: <manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   3:           xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   4:  
   5:     <assembly>
   6:         <name>TimHeuer.SimpleFunctions</name>
   7:         <version>1.0.0.0</version>
   8:         <publickeytoken>f265933def965411</publickeytoken>
   9:         <relpath>TimHeuer.SimpleFunctions.dll</relpath>
  10:         <extension downloadUri="TimHeuer.SimpleFunctions.zip" />
  11:     </assembly>
  12:  
  13:  
  14: </manifest>

Taking a look at this manifest, let me point out some important things.  The obvios of the assembly short name and version are there.  The publickeytoken node must be there as well.

NOTE: How do you obtain your public key token from a signed assembly?  Man I wish there was a tool in VS (plugin maybe) that made this simple.  But just get to the Visual Studio command prompt and execute: sn.exe –T <path-to-assembly>

Notice the next two nodes: relpath and extension.  The relpath node is the name of your assembly file.  The extension node indicates where to get the package for the assembly part.  Here’s where it might help to explain the options.  First, the endpoint to the extension part will be a ZIP file.  Within that file can exist your assemblies.  Take a look at the downloadUri attribute.  This tells the Silverlight application where it is going to get the zip file.  If you just specify a file name like the above two things will happen.  Your external part will be packaged into the ZIP file name you provide here and then that zip will be deployed alongside your XAP file (not in, but alongside it like in the ClientBin directory).  This means that wherever your XAP is, so does this ZIP need to reside.  After compiling your application you’d see it in your web applications folders like my sample here:

Alongside deployment

You can, however, provide a URI to the file.  Let’s look at a modification of the above:

   1: <?xml version="1.0"?>
   2: <manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   3:           xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   4:     <assembly>
   5:         <name>TimHeuer.SimpleFunctions</name>
   6:         <version>1.0.0.0</version>
   7:         <publickeytoken>f265933def965411</publickeytoken>
   8:         <relpath>TimHeuer.SimpleFunctions.dll</relpath>
   9:         <extension downloadUri="http://timheuer.com/asmcache/1.0/TimHeuer.SimpleFunctions.zip" />
  10:     </assembly>
  11: </manifest>

Notice the different downloadUri attribute.  This is a unique URI that must be accessible by the Silverlight application (i.e., don’t put an Intranet URI here if you are using this feature on those bigger web tubes).  The resulting AppManifest.xml now looks like this:

   1: <Deployment --removed attributes for readibility-->
   2:   <Deployment.Parts>
   3:     <AssemblyPart x:Name="SilverlightApplication1" Source="SilverlightApplication1.dll" />
   4:   </Deployment.Parts>
   5:   <Deployment.ExternalParts>
   6:     <ExtensionPart Source="http://timheuer.com/asmcache/TimHeuer.SimpleFunctions.zip" />
   7:   </Deployment.ExternalParts>
   8: </Deployment>

And notice my project no longer has a local ZIP file in the ClientBin alongside my XAP:

Project explorer

This now tells Silverlight that it will need to get this assembly extension from this remote location.  This operation is done asynchronously by the runtime and you don’t have to add any additional code to request it.  Basically if your downloadUri is a file name, the build system packages the assembly into a zip file and deploys it alongside your XAP file.  If the attribute is an absolute URI, you are then responsible for providing the ZIP yourself and will need to ensure it is packaged and in that URI location point.

Why would you use this?

You may be asking yourself why or when you’d want to use this feature.  After all, in the end, the assembly will still be downloaded.  So whether or not it is in your initial XAP or later in a ZIP assembly request, the bits will still get to the end-user.  So why?

I can think of two initial scenarios where you’d want to consider this.  If you are a component vendor and want to provide a location for your consumers to get your bits, you could do this.  This may help manage a central location of known versions and enables the application developer to get the bits from the source rather than have to deploy them to their servers.  The second scenario I can think of is one of enterprise common assemblies.  If your team develops common components that all applications should use, then you can provide a central location to deliver these from and ensure people are using the correct bits/versions.

Things to look out for

As with any new feature, I’m sure you may be skeptical…and perhaps somewhat confused (if so, I apologize).  One of the obvious things to look out for in this feature is that if you rely on those referenced assemblies and you aren’t packaging them in your XAP or aren’t deploying them from your own servers, you are depending on that remote location to deliver them.  The natural concerns about latency, uptime, firewalls, etc. come into play here so be sure to understand your architecture choices correctly.

If you are using an absolute URI for the downloadURI attribute, there are two things you should consider.  First, if it is going to be delivered from a different domain than the XAP file, then a valid cross-domain policy file must exist at the domain serving the assembly package (zip).  Second, treat the absolute URI as a unique identifier.  Version should be unique as well.  Consider a URI naming scheme along the lines perhaps of something like this:

   1: http://timheuer.com/asmcache/1.0/TimHeuer.SimpleFunctions.zip

This way each version of the assembly library cache is unique.

If you have checked that “reduce XAP size…” checkbox and then try to also check the out-of-browser settings, you’ll be greeted with:

Warning with out-of-browser and assembly cache settings

Unfortunately right now the assembly caching feature is not available in out-of-browser experiences.

Summary

The assembly caching feature is a cool feature to be able to take advantage of when your architecture makes sense to leverage it.  It isn’t going to be for everyone, but that’s what makes it great – it is an opt-in feature for you as the assembly developer as well as the consumer.  With a few simple steps you can take your Silverlight assembly and prepare it for use on this feature as described above.  What do you think of assembly caching?


This work is licensed under a Creative Commons Attribution By license.


7/13/2009 10:27 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Hi Tim,
Thanks for this, this is a great feature.
I've been using my own tricks for reducing XAP size and caching assemblies which I'll post on my blog soon.

One question on this topic:
Can you give an example of how to do this using .NET assemblies instead of custom ones? I'm currently working on a project that uses LINQ, which is a seriously big assembly and expands the size of my xap a lot. I would like to use this feature for that assembly.

One comment:
The images in the article do not seem to work in my IE8... They work fine in FF.

Thanks,

Rob Houweling
7/13/2009 11:04 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Rob, I think the images are having trouble because the link to the site was thru https. Changing the url to http fixed it for me.

Tim, great details! To me the most exciting part about this feature is that it makes updates smaller. Now I can update my code, deploy a new version, and presumably only my xap (now much smaller) would need to be downloaded instead of the whole "classic" xap file containing everything -- much of which hasn't changed. Very exciting!!!

Q: Are all relevant external assembly parts downloaded before an app will start to run or does SL allow your app to start and silently download them in the background sometime before they're actually used? -- assuming they aren't needed immediately.
7/13/2009 11:41 PM | # re: Silverlight 3: Cached Assemblies and you can to!
bob, I think you should look the directory "c:\Program Files\Microsoft SDKs\Silverlight\v3.0\Libraries\Client\"
there are many extmap.xml file
7/14/2009 5:22 AM | # re: Silverlight 3: Cached Assemblies and you can to!
This is a great feature! I've been waiting for it since Silverlight 2 release date ;). I wonder if Flex/Flesh provides something like caching asseblies?
7/14/2009 7:32 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Rob -- The assemblies for MSFT bits (SDK, etc) are already enabled for this feature (the ones that would be enabled and Linq is one of them). The downloadUri is still your application though as MSFT chose not to host them at this point. Re: site icons...no idea -- someone mentioned that the link came across as SSL and I have no idea why.

Tim - They are downloaded after the app is loaded and done async. But they are all downloaded when the app starts so if your app 5 steps later needs a reference, it is likely there. What would you like to see in this regard? Is that satisfactory?

Marc -- no idea, they work for me, check the URL to make sure it isn't https as someone else suggested.

Danijel - I have no idea if Flex provides something like this, but I know they have the similar 'old' style ;-) (which you can still use as well) of downloading your own assemblies via resource streams, etc.
7/14/2009 7:32 AM | # re: Silverlight 3: Cached Assemblies and you can to!
I'm trying to use SL 3.0.
What about references in projects?
I have installed SL 3, sdk and VS 2008 tools. But in "add reference" dialog I can see only 2.0.5.0. version and less, but not 3.0.0.0.
Even .dll says that it has 3.0.40624.0 version, but VS 2008 shows 2.0.5.0.

Thanks.
7/14/2009 8:26 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Tim, that's actually what I was hoping to hear! ... that the app starts running while it is still downloading the other assemblies. The end result of course being that my app will start up faster because it doesn't have to wait for everything to finish. I suppose if I needed one of those controls immediately there might be a strange delay (curious what the user would see?) but it sounds like I could also go out and turn off the feature or modify the manifest to include relevant assemblies in my main xap to deal with that. Good to know and great work on SL3!
7/14/2009 8:29 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Ivan -- the assembly file versions didn't change I don't think.
7/14/2009 8:33 AM | # re: Silverlight 3: Cached Assemblies and you can to!
I've always used reflector to get the public key token of an assembly. Seems a bit nicer then the command line for me. It's even easier if you've added reflector to the "send to" list. Then it's just right click the dll, send to reflector. I feel like it saves me time anyway :)
7/14/2009 9:42 AM | # re: Silverlight 3: Cached Assemblies and you can to!
When I compile my solution, the zip files never get copied to the ClientBin folder, and I get an unhandled error ("InitializeError, Failed to download a platform extension"). The zip files are created, but they only end up in the Bin/Debug folder of the silverlight project folder. I'm assuming that they should be automatically copied to the ClientBin folder of the asp.net project as well? Or am I missing something here?
Thanks.
7/14/2009 12:18 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Hi Tim,

Thanks for your always excellent posts.

One thing that I'd like to clarify which seems that Tim Greenfeld also asked but I don't think you responded to that question.

If there was no changes to the these external assemblies will they keep on being downloaded again and again when the app loads? My guess is that it won't be downloaded, hence the name "cached assemblies", just wanted to confirm.

If the answer is positive (I hope) how does it determine a file change, is it thru the date/time of the assembly or on the version number?

Thanks in advance.
Shloma Baum
Pioneer Interactive, Inc.
7/14/2009 12:57 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Shloma -- they leverage the browser cache at that point, so as long as the bits haven't changed and they are in the browser cache, that would be used.
7/15/2009 7:35 AM | # re: Silverlight 3: Cached Assemblies and you can to!
One more time... How does SL3 determine whether or not an external assembly has changed? Time/Date stamp? Version number? Some sort of checksum?

I work for an ISV that offers a variety of solutions (CRM, reporting, dashboarding, etc.) to businesses in the form of web apps. Assembly caching would be a nice way of delivering controls to the browser, such that they are available to any given solution without having to include them in every solution's XAP. Very cool!

BTW, Flex does NOT offer similar functionality at such a low cost. Like you said, it allows the old-school method of custom code to download the external resource, but nothing close to the simplicity offered by SL3.
7/15/2009 9:43 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Hi Tim
Any joy on the image in a dataform problem?
7/15/2009 10:07 AM | # re: Silverlight 3: Cached Assemblies and you can to!
David -- SL3 doesn't do any caching itself...as I mentioned in this iteration we rely on the browser to provide that. The extension assemblies are subject to the cache control policies set on the response headers from the origin size of the assembly package.
7/15/2009 10:22 AM | # re: Silverlight 3: Cached Assemblies and you can to!
So this basically means that the xap files will be way smaller since we could exclude all the 3rd party and MS components but only include in the xap those app specific stuff which changes rather more often, man this is sooo cool and I'm not even sure what you don't mention this for a "use case" and you "try" to find a use case for the 3rd party vendors or to share assemblies with multiple apps, I see this as a huge benefit even for a single application that I would only xap the app logic and exclude/cache the other assemblies.

Hope I'm correct and this is a really cool new benefit that I've been hoping will get in SL4 and you guys dropped the ball on 3.
7/17/2009 7:31 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Tim,

This is such a great feature. It is so nice to cut our xap file in half on a large application! For the user that may view the site many times a week, the user can have a much better experience.

As always, you produce a concise but well explain example that allows us to implement the feature in minutes instead of fighting for hours through poor documentation.

Thanks again,

Bruce
7/19/2009 4:30 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Great article and comments!
I would like to know if it is possible to notify the user while the SL application is downloading the needed DLLs, keeping the user away from some views referencing not yet downloaded DLLs.

Also, let's say an application has 5 tabs for different tasks. The view in of the tabs will need very large DLLs (several MBs). In this case I would like to delay the loading of the DLLs for this part of the application. Any ideas?

Thanks

/anders
7/19/2009 8:04 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Tim, how can I know when third part bits was fully downloaded? There is an event or something?

If I try to use before download finish I get an exception?

Thanks
7/19/2009 8:26 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Vitor - yes you'd get an initialize exception.
7/20/2009 4:12 AM | # re: Silverlight 3: Cached Assemblies and you can to!
And how can I know when download finish?
7/22/2009 4:38 PM | # re: Silverlight 3: Cached Assemblies and you can to!
"The downloadUri is still your application though as MSFT chose not to host them at this point."

Just to get this straight: Let's say both domain A and domain B hosts System.Xml.Linq, and they each have a Silverlight application that uses Xml Linq.
So first I visit domain A, and the browser will download the linq assembly and cache it.
Then I visit domain B. Two things could happen:
1. Silverlight detects the publickey is the same and reuses the cache from domain A.
2. Silverlight detects that the assembly is on a different domain, so it treats it as a different assembly and downloads the linq assembly yet again (making the assembly caching almost worthless).

Please tell me the first thing is what will be happening. If not, unless I frequently update my app, I might as well not use this feature until we all start using a microsoft run site for hosting the assemblies.
7/22/2009 5:24 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Morten -- the cache is the browser cache -- so it is URI based and the runtime isn't doing anything specific -- so #2 is happening here. You are correct in situations like LINQ and common ones that it isn't as helpful as something like your organization's common controls, etc. As to why we (MSFT) didn't host the common ones like we did in beta...I think it pretty much came down to time in figuring out how to reliably provide an SLA on that feature. I'll double check the reasoning and see what I can come up with. I'll also put a post together of how you can selective decide what to cache (manual process).
7/27/2009 3:03 AM | # re: Silverlight 3: Cached Assemblies and you can to!
I have published a blog post explaining an Assembly Cache example I think a common Silverlight 3 application can benefit from: stulic.blogspot.com/.../...g-in-silverlight-3.html
7/28/2009 6:54 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Hi Tim

You mention Toolkit assemblies at the beginning of your blog post, but as far as I can tell the Toolkit does not include the required extmap.xml files for each assembly. This means when I use the Toolkit, switch on 'Reduce XAP size' and build my XAP file, that the Toolkit assemblies would still be compiled into my XAP file.

Do you know if there are extmap files for the Toolkit available somewhere? Or are we all going to have to roll our own?

Thanks for a great post.
7/28/2009 8:05 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Snympi - they do not have the XML file for some reason...check out this tool to help make the process faster: blogs.microsoft.co.il/.../...ity-extmap-maker.aspx
7/29/2009 2:31 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Excellent tool! Thanks for the heads up.
7/31/2009 4:18 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Snympi - also, you should log a work item request on the toolkit site http://silverlight.codeplex.com for this. I know we are already aware of it, but helps to keep us honest :-)
8/4/2009 3:40 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Hi Tim,
Would you mind answering this question "And how can I know when download finish? " from Vitor? Since you get an InitializeException when you try to use an assembly wich is not yet downloaded, it would be handy if we could somehow know when an assembly is downloaded and available for use.
8/4/2009 5:01 AM | # re: Silverlight 3: Cached Assemblies and you can to!
I experimented a bit, creating DLL's that were 90mb+ (simply embedding large resources) and enable caching on them and i dont seem to get an InitializeException. What the runtime seems to do is, first download the initial XAP, wich is faster because the DLL's arent included. So the Silverlight plugin progress indicator flies to 100 percent. Then it stays at 100 percent while all the external assemblies are downloaded. When this is complete the initial UI of your application shows. It doesn't matter whether you actually use the assembly at that time, all assemblies are downloaded when the progressindicator for the initial XAP reaches 100 percent. this way, it is certain that all required assemblies have been loaded, the downsize is, you really can't show any custom progress indication while downloading the assemblies in the background, even worse, your application is unresponsive. It would have been nice if the default progress indication of the silverlight plugin would somehow show that it was busy downloading assemblies, because just staying at 100%, makes it look like the application has frozen.

FYI, all of the above behaviour is consistent with Flex Runtime Shared Libraries.
8/29/2009 5:16 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Hi Tim,
How does it work with your previous example regarding dynamically loading assemebly? How can I check if a related assembly part is already in cache so that I do not need to download them?
9/2/2009 10:48 AM | # re: Silverlight 3: Cached Assemblies and you can to!
David -- the cache is the browser cache. There is no Silverlight API to be able to check them. We make the request and if it is in the browser cache and still valid, it uses that (if-modified-since headers), if not, we get it.
9/5/2009 10:55 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Trying to add reference to SL project I got the following message:

---------------------------
Microsoft Visual Studio
---------------------------
You can't add a reference to System.Data.dll as it was not built against the Silverlight runtime. Silverlight projects will only work with Silverlight assemblies.
---------------------------
OK
---------------------------

Any suggestions?
9/8/2009 7:18 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Hi Tim,
Thanks for the nice writeup,
though i have a question while i was testing this feature on my local environment i found that somehow my xaml finishes loading and thereafter also it waits for all the dependencies to show up on the screen. i.e it waits for all the zip files to be downloaded until then nothing is shown on my screen, is this the desired behaviour, if yes then what actually am i gaining by reducing the size of the xap file.
Also i have made a custom progress bar which hangs on 100% completion and still waiting for all the zip files to get downloaded which is bad user experience when i am not using this feature everything works as planned at 100% the xaml loads and renders on the page.
So what do you think.
Thanks
9/8/2009 4:21 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Aashish -- this is the behavior. The benefit is the next time your app loads everything will be in cache. And if you change something in your main app but not the satellite assemblies then it will be the only thing re-downloaded.

For the 100% progress issue, I'd love to see a reproduction and some log files.
12/23/2009 12:03 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Hi Tim,
Thanks for the info. I was searching for a way to load dll's dynamically and invoke methods based on an Interface (at the client side, like addons/extensions) when I found this article, doesn't seem to be the same thing, but would this work? I'm thinking that just updating the ZIP file would make new implementations of the Interface available?

Do you know of any good article on what I'm trying to achieve?
12/25/2009 5:04 PM | # re: Silverlight 3: Cached Assemblies and you can to!
Awesome post!
1/31/2010 11:34 AM | # re: Silverlight 3: Cached Assemblies and you can to!
I have his working perfectly now, but I manually copy the file to the Bin/Release directory. I have tried all he build actions to get it to copy there by itself, but none work. How do I include it in the project an have it copy to the correct build directory?
Gravatar
6/11/2010 1:33 AM | # re: Silverlight 3: Cached Assemblies and you can to!
hi Tim,

I ma having an error and I would like to confirm with you about this:
All .zip files have to been downloaded completely before the application begin to get starting-up ? this mean nothing of code need to handle in this case? right

Thanks Tim
8/13/2010 3:18 AM | # re: Silverlight 3: Cached Assemblies and you can to!
How can I create customUI if my application cache file is larger? Now silverlight shows some circles only.
1/5/2011 2:06 PM | # re: Silverlight 3: Cached Assemblies and you can to!
What's solution for that? caching assemblies loading progress bar....
1/19/2011 9:04 AM | # re: Silverlight 3: Cached Assemblies and you can to!
I am using 3rd party infragistic dll in my silverlight 3 project. I see that it does not create the respective zip files to be used for application library caching feature. other system dlls are working fine and creating respective zip files except this infragistic dll. Is there any way to implement infragistic dll in zip rather than in xap file? Thanks.
3/13/2011 11:35 PM | # re: Silverlight 3: Cached Assemblies and you can to!
I wonder if it's possible to "outsource" satelite assemblies with language specific resources from XAP somehow. Our SL client app is really huge and even though it is divided in modules that are loaded on demand, there is a lot of resources. Currently we have 4 languages, each of them adding hefty 400KB to XAP size. Asuming that we'll have twice more functional (and resources) and more languages being supported it would be extremely helpful to be able to load satelite assemblies on demand.
6/10/2011 12:24 AM | # 
Hi Tim,
Thanks for the nice write up,
i have one question when i set all the things and press F5 (in my app multiple startup project (silverlight project , Wcf Project)) it show me a error
but when i set single startup project (silverlight.web) then it will work fine
can u please give me a reason for this
8/22/2011 11:30 AM | # re: Silverlight 3: Cached Assemblies and you can to!
Hello, my xap was about 5M, with some third part assemblies, some of them not signed. In order to signed them, I used http://signer.codeplex.com/, I signed the assemblies, write the <AssemblyFileName>.extmap.xml and now my xap file is about 500K.

I have a fast development cicle, I publish a new xap file every two weeks, so library caching it's great, the only part that change is my xap not the third part assemblies, the user experience in every update is faster!

Thank you to Tim and all the silverlight team, you do a great work, and you inspired us!
4/19/2012 6:00 AM | # re: Silverlight 3: Cached Assemblies and you can to!
My silverlight app is referring 3rd party silverlight dll of V1.0.0.0 and I want my app to load this 3rd party dll dynamically. I can do this as you explained in this article. Is it possible to load V2.0.0.0 of 3rd party dll without rebuilding my app. If yes, can you please route me to a proper link that explains how?

 
Please add 3 and 5 and type the answer here:

DISCLAIMER:

The opinions/content expressed on this blog are provided "ASIS" with no warranties and are my own personal opinions/content (unless otherwise noted) and do not represent my employer's view in any way.