Silverlight Web Client

R

Rich

There's no Silverlight Managed Newsgroup yet - MSDN concierge says to post my
question here. Please re-route, if nec.

I am writing a VERY simple Silvelight app. It's for a
presentation/demonstration and therefore NEEDS to be simple.

App needs to download XML info from server to Silverlight client.

This works in XP...

Sub OnLoad(ByVal Sender As Object, ByVal e As RoutedEventArgs) _
Handles Me.Loaded

Dim _webClient As New WebClient()
AddHandler _webClient.OpenReadCompleted, AddressOf XMLLoaded
_webClient.OpenReadAsync(New Uri("Movies1Xml.Xml", UriKind.Relative))

End Sub

Protected Sub XMLLoaded(ByVal Sender As Object, ByVal e As
OpenReadCompletedEventArgs)
If e.Error Is Nothing Then
Dim rss As XElement = XElement.Load(e.Result)
Dim movieArray As XElement = rss.Element("Movies")
Dim movieElements As IEnumerable(Of XElement) = movieArray.Elements("Movie")
...
End If
End Sub

Does not work in Vista (even when I run Visual Studio "as administrator").

"Movies1.Xml.Xml" is in ClientBin, where the .xap is. In Vista, when I use
UriKind.Relative, Exception is "NotSupported" and InnerException says "Uri
Prefix not defined". If I use a full path to the file with UriKind.Absolute
- I get a SecurityException.

I even tried a clientaccesspolicy.xml file on the server - no luck. What do
I need to do to make this work in Vista?
 
A

Alex Clark

Is there an overload for the constructor of Uri that accepts a prefix (or
possibly a property you can set)? It looks to me like the unmanaged network
stack in XP probably assumes "http" if the URI doesn't specify it, whereas
Vista probably doesn't for some convoluted security reasons.
 
R

Rich

--
Richard Laird, MCSD.NET


Alex Clark said:
Is there an overload for the constructor of Uri that accepts a prefix (or
possibly a property you can set)? It looks to me like the unmanaged network
stack in XP probably assumes "http" if the URI doesn't specify it, whereas
Vista probably doesn't for some convoluted security reasons.
Click to expand...
 
R

Rich

I think you're right about assuming "http" - I think I read somewhere that
that's a default and could be that that's just not the case with Vista. I
looked for a "prefix" property but don't see that in a Uri object. There is
a Uri builder that we can use to construct a Uri and specify more properties
than the Uri constructor itself allows. One of those properties is "scheme"
that allows for stuff like "http", "https", "ftp", etc.

But the UriBuilder seems to create only absolute Uri objects. The result is
the same as if I instantiate a Uri with the full path and specify
UriKind.Absolute - a SecurityException.

I really think a relative path is the way to go on this because there are
(and should be) cross_site access restrictions on Silverlight clients,
although this isn't cross-site anyway. (What was it you said about
convoluted security in Vista?). But I'll go with anything that works!

Anyway, thanks for the suggestion.
 
A

Alex Clark

Hi Rich,
But the UriBuilder seems to create only absolute Uri objects. The result
is
the same as if I instantiate a Uri with the full path and specify
UriKind.Absolute - a SecurityException.
Click to expand...

Could you use the shared "MakeRelative" or "MakeRelativeUri" functions to
create a URI from the absolute URI you create? Perhaps that would preserve
the scheme property whilst making it Relative?
I really think a relative path is the way to go on this because there are
(and should be) cross_site access restrictions on Silverlight clients,
although this isn't cross-site anyway. (What was it you said about
convoluted security in Vista?). But I'll go with anything that works!
Click to expand...

I think the cross-site restriction stuff is Silverlight-specific rather than
Vista-specific from what I recall, and I've always felt it was a bit
over-zealous but I think it's just MS trying to appear ultra security
conscious and reduce the possibility of people writing Silverlight malware
(as if that will stop them).

I can see Vista enforcing that Scheme restriction also, and in fairness it
is slightly bad practice for an OS to just blindly assume that
"somesite.somewhere.com/somefile.exe" automatically means
"http://somesite.somewhere.com/somefile.exe" because naturally those could
be two very different files if the original Uri was supposed to be referring
to an FTP site.

Hope you find the answer (and I'd be interested to know what it is when you
do),
-Alex
 
R

Rich

Alex...

Thanks again for the suggestion. The MakeRelative method is listed as
obsolete but I was able to use MakeRelativeUri to basically resolve the
issue...

Dim u As New Uri("http://localhost:49771/WebSampleApp/ClientBin/")
Dim u1 As New
Uri("http://localhost:49771/WebSampleApp/ClientBin/MoviesXml.xml")
_webClient.OpenReadAsync(u.MakeRelativeUri(u1))

It's a good work-around but less than ideal because it's not portable, since
the base Uri is hard-coded. Trying to pass that information from the server
would require guess what? The WebClient! So, it's a Catch-22.
(Potentially, the base Uri info might be included in a config file but I
don't think Silverlight supports Configuration types.)

Using the WebClient class for client/server data interaction seems to be a
key aspect of Silverlight. (Using a Web Service, of course, is also an
option. I'd devote the time to re-building my solution with a Web Service
but I suspect that I'd encounter the same issue and there's lots of other
stuff to do right now.) After a client is loaded and initialized, it should
be able to access content from its server that was not included in the
original .xap file (think graphice, video, database content). Otherwise, the
..xap content could get monstrous.

That's why I wanted to include an example in the presentation I am
preparing. It's sort of a drag to have to explain that it doesn't really
work that well!

I think you are correct in saying that cross-site access restrictions are a
Silverlight feature and not Vista-specific. But this little demo app is not
cross-site anyway. The client should be able to access data from the server
that initiated it without any base Uri. (In fact, including the server base
Uri in the .xap code seems a little questionable, security wise.) That's why
it works in XP (and in documented examples).

Thanks again.
 
A

Alex Clark

Rich,

Have you had a look around for sample code on the MSDN website? I know MS
have created loads of sample projects, snippets and videos and for something
so fundemental as exchanging data between the client and server there *must*
be an example project somewhere. Maybe we're both missing something really
obvious, as the Uri workaround seems like a bit of a hack - particularly
when I consider that you've now got to hardcode the base URL into your app.

If this really is the only solution to it, then MS need a very prompt kick
on the Connect website - something like this simply shouldn't be this
difficult or cumbersome!

Cheers,
Alex
 
A

Alex Clark

http://msdn.microsoft.com/en-us/library/cc189021(VS.95).aspx

I cannot see anything that indicates different methods on Vista, and in fact
I didn't see example code relating specifically to creating the Uri. I also
checked out:

http://msdn.microsoft.com/en-us/library/cc189008(VS.95).aspx

....which didn't really cover the issue, nor did it provide any sample code.

All I can think of to help is that your SL app probably has some kind of
"Application.BaseUri" property, or something like that, which would allow
you to use the MakeRelative hack we spoke about earlier in the thread
without resorting to hard-coding the actual URL.

Aside from that, I'd strongly suggest posting it onto the Connect website -
seems to me MS need to look in to this one.

Cheers,
Alex
 
R

Rich

Thanks Again, Alex

No, the article I posted doesn't address the issue of creating a Uri except
to indicate that you should be able to use a "Relative" uri and be done with
it...

wc.OpenReadAsync(new Uri("imgs.zip", UriKind.Relative), imgPart);

This, of course is exactly what I coded, except that I'm using Xml,instead
of an image embedded into a zip file. But the content type is not the issue,
only the Uri addressability.

As far as "Application.BaseUri" or some equivalent. I looked at that, too.
"Application", of course, encapsulates the AppDomain of the Silverlight app,
not the server. These, normally, would not even be on the same machine.

Thanks for the suggestion about re-posting. what do you mean by "Connect"
website. Doesn't MS monitor this site. It's supposed to be a "Managed
Newsgroup, right?

The MSDN concierge told me to post here. When I pointed out that this
Newsgroup sounded too general for what I know to be a Silverlight specific,
he said post it here anyway and that it would be re-routed, if necessary.
 
A

Alex Clark

Hi Rich,
As far as "Application.BaseUri" or some equivalent. I looked at that,
too.
"Application", of course, encapsulates the AppDomain of the Silverlight
app,
not the server. These, normally, would not even be on the same machine.
Click to expand...

I had a look around and the following property looks promising:

App.Current.Host.Source.AbsoluteUri
Thanks for the suggestion about re-posting. what do you mean by "Connect"
website. Doesn't MS monitor this site. It's supposed to be a "Managed
Newsgroup, right?
Click to expand...

http://connect.microsoft.com

You use the above website to provide feedback and bug reports to MS. Often
MS will respond with workarounds, or at the very least acknowledge there is
a problem - particularly if enough other Connect users vote on your issue as
being a problem.

Although these are managed newsgroups, I MS only respond to MSDN subscribers
(and then only if you've set up your posting alias properly). Also MS
appear to be gradually downgrading the newsgroups in favour of the web-based
forums. Note that there are no WPF or SL specific newsgroups, despite the
tech being around for a while now. MS just aren't investing here any
longer. :-(
The MSDN concierge told me to post here. When I pointed out that this
Newsgroup sounded too general for what I know to be a Silverlight
specific,
he said post it here anyway and that it would be re-routed, if necessary.
Click to expand...

Yeah... the concierge "helpline" people are not always the sharpest tools in
the box, that's for sure... In fact I've never really been 100% sure what
their purpose is. The description for them seems to say something like
"help with any non-technical issues surrounding your subscription", so I'm
not sure if they're able to direct you to the right newsgroup or if they're
more suited to finding out why your latest DVD shipment hasn't arrived yet.
In either case, I've never had much luck with them on the few occasions I've
resorted to using them.

Cheers,
Alex
 
Top