Deployment catalog feedback

Feb 25, 2010 at 4:47 PM

Hi guys,

I've checked your new deploymentcatalog class.

And I have following suggestion.

Add support of external parts. Just parse manifest and load external parts zips that haven't been loaded before.

Without this feature all dynamicly loaded xaps are FAT, because they keep dlls inside it.

And PLEASE try to inform somebody in Silverlight Team to add assembly depedencies support for external parts.

Best regards,

Alexey Zakharov.

Developer
Feb 26, 2010 at 12:12 AM

Thanks for the feedback. We have actually considered adding support for ExternalParts but the cost of adding it was too high for the point where we were in the product cycle. We will however consider it again for future version of Silverlight. Just keep in mind you can still use it for assemblies that don't actually have any Exports in them because they won't show up in the catalog anyway.

Feb 26, 2010 at 5:25 AM

Hmm... Surely adding support of depenencies between external parts is hard. But  adding support for current external parts mechanism is rather easy. We have implemented it during one day for our framework.

Feb 26, 2010 at 7:10 AM

It's not as easy as it sounds. We did consider it.

First it requires us to use a convention that the zip name matches the assembly, a convention that SL itself does not impose.

Second, which is the primary reason we didn't do it, is that DC implements the async event pattern and fires update progress events, it was not clear how we would reflect progress as once the download completes and the XAP is ripped open, then you hae a new set of downloads to do with relation to the ExternalParts.

We will look into this going forward though.

Glenn

Feb 26, 2010 at 8:20 AM

Hi Glen,

>> First it requires us to use a convention that the zip name matches the assembly, a convention that SL itself does not impose.

As I see all microsoft dlls and event third parties (Telerik) are placing single dll per zip and i think it the best choice =)

>> Second, which is the primary reason we didn't do it, is that DC implements the async event pattern and fires update progress events, it was not clear how we would reflect progress as once the download completes and the XAP is ripped open, then you hae a new set of downloads to do with relation to the ExternalParts.

Currently we track only progress of xap and then progress freezes until all external part are loaded.

Have you tried request zip size for whole progress estimation in following way:

public void RequestLength()
{
    this._contentLengthRequest = WebRequestCreator.ClientHttp.Create(this._uri);
    this._contentLengthRequest.Method = "HEAD";
    this._contentLengthRequest.BeginGetResponse(new AsyncCallback(this.GetResponseCallback), null);
}

private void GetResponseCallback(IAsyncResult ar)
{
    this._loader._dispatcher.BeginInvoke(delegate {
        WebResponse response;
        try
        {
            response = this._contentLengthRequest.EndGetResponse(ar);
        }
        catch (WebException)
        {
            return;
        }
        var size = long.Parse(response.Headers[HttpRequestHeader.ContentLength])
 }); }
I haven't checked this approach yet, but it should work.