Hi there,

I am working with a startup ISV that is interested in developing a RIA using Silverlight 2.0. The first Beta of this technology is due out soon.

As you may or may not know, Silverlight uses the 3.5 version of .NET, but with a subset of the framework libraries.

Will the LLBLGen libraries support Silverlight? Your planned LINQ to LLBLGen provider would really shine here, as Linq to SQL is not supported in Silverlight 2.0. (Probably because SQLClient is not present in Silverlight, I believe)

Perhaps at the least the ORMSupport library could be compatible, even if the DB provider is not. Then perhaps the DataAccessAdapter could be leveraged server side to do the data commits.

Any comments on this would be appreciated.

Thanks!

tomahawk wrote:

Hi there,

I am working with a startup ISV that is interested in developing a RIA using Silverlight 2.0. The first Beta of this technology is due out soon.

As you may or may not know, Silverlight uses the 3.5 version of .NET, but with a subset of the framework libraries.

Will the LLBLGen libraries support Silverlight? Your planned LINQ to LLBLGen provider would really shine here, as Linq to SQL is not supported in Silverlight 2.0. (Probably because SQLClient is not present in Silverlight, I believe)

Perhaps at the least the ORMSupport library could be compatible, even if the DB provider is not. Then perhaps the DataAccessAdapter could be leveraged server side to do the data commits.

Any comments on this would be appreciated.

Thanks!

We got the same question yesterday in the helpdesk forum. Let me quote my answer:

The generated code is supported on .NET full framework or compact framework. Silverlight seems to be a stripped down framework of .NET but how much of the full framework is stripped out of it... unclear. My guess is that they've WPF + compactframework.

If silverlight will require a different build of our framework, because a compiled assembly on .NET 2.x won't run as it has to be compiled against a different mscorlib (as is the case with compactframework) we probably won't support it for a long time as all those conditional compilation stuff is a true pain to maintain.

However, if MS has learned from their mistakes with the compact framework, it might be that it's simple: compile an assembly on .NET and run it on silverlight. Although I don't expect it to be that simple. As our code links to winforms code it might be that code has to be excluded as well as code which affects asp.net. So it's likely that the ormsupportclasses won't load because they reference assemblies not available on silverlight.

So, a first test might reveal what's it going to be: if it works out of the box: great. If it doesn't, it's unlikely it will get support soon.

That linq to sql isn't supported on silverlight is likely due to the fact that the Expression objects aren't on the silverlight .net version. It's also not supported on compact framework, because essential stuff misses.

As I see Silverlight as a UI only framework for thin clients, I really dont think Linq is an option on silverlight (if you need a thick client, use WPF): silverlight communicates with services to work with data.

The biggest pain with these stripped out frameworks is that MS always finds ways to remove code which is essential in one way or the other so extra work has to be done to work around these limitations. This also brings maintenance issues. As we have learned the hard way with compact framework support which wasn't easy, we aren't really thrilled to jump onto the silverlight wagon, especially because the silverlight framework is a UI framework for thin clients, not a framework for full blown fat clients (WPF is then more suitable)

Personally I fail to understand why silverlight is even there, beyond flash-like applets inside browsers: if it's used for apps outside a browser, why not use WPF?

Personally I fail to understand why silverlight is even there, beyond flash-like applets inside browsers: if it's used for apps outside a browser, why not use WPF?

If I had to guess: - .net is moving cross-platform, slowly (step by step functionalities will be added) - full blown WPF won't run on Nokia mobile phones, will it? - easier to develop for Silverlight, at least for .net developers

BTW, I might be wrong, but I think Silverlight still runs within the browser

mihies wrote:

BTW, I might be wrong, but I think Silverlight still runs within the browser

Yeah, as far as I know, silverlight runs within the browser.

mihies wrote:

Personally I fail to understand why silverlight is even there, beyond flash-like applets inside browsers: if it's used for apps outside a browser, why not use WPF?

If I had to guess: - .net is moving cross-platform, slowly (step by step functionalities will be added) - full blown WPF won't run on Nokia mobile phones, will it?

But... will silverlight? Or will that be silverlight CF.NET edition? I.o.w.: is Silverlight's platform == cf.net or is it a subset (ugh) or is it 'yet another subset of .net', which will mean it will surpass cf.net)

But... will silverlight? Or will that be silverlight CF.NET edition? I.o.w.: is Silverlight's platform == cf.net or is it a subset (ugh) or is it 'yet another subset of .net', which will mean it will surpass cf.net)

I really hope Silverlight is one and only. Otherwise, yes, the mess will be getting to mega proportions. BTW, Nokia press release: http://www.nokia.com/A4136001?newsid=1197788

Fairly sure it's another subset. Read the Scott Gu's post here. http://weblogs.asp.net/scottgu/archive/2008/02/22/first-look-at-silverlight-2.aspx

The reasoning behind using silverlight as opposed to WPF is that it's cross-platform, it runs in the browser. There are still people out there on Macs that want to run your app. WPF is great, but it not only requires a newer pc, but also a hefty framework download.

Since they've added a DataGrid control, I'm assuming they're including System.Data.

Here's a question, if my app references a missing assembly (say System.Data.SqlClient), will it copy it over during the launch of my app in the browser? Thus getting around the missing assemblies quandary?

That linq to sql isn't supported on silverlight is likely due to the fact that the Expression objects aren't on the silverlight .net version

According to this wikipedia post, full support for Linq to object including expression trees are supported.

http://en.wikipedia.org/wiki/Silverlight#Silverlight_2

tomahawk wrote:

Fairly sure it's another subset. Read the Scott Gu's post here. http://weblogs.asp.net/scottgu/archive/2008/02/22/first-look-at-silverlight-2.aspx

Silverlight 2.0 is a subset of .net 3.5, no doubt about that - and that's fine. The question was whether the Silverlight running on Nokia (or any mobile device) is subset of Silverlight running on desktop PC or not. Or if there are going to be different Silverlight 2.0 versions.

If expression trees are usable on silverlight, linq is usable, but then again, who cares: it's on the client, in a browser. You can't access a local database, so the database is always on the server, and expression objects aren't serializable, so you need a serializable querying method. However, best practises for services dictate you use message based webservices, so the client is very thin, and calls methods on the service which do work, instead of using the service as a lowlevel tier (== chatty, burned down servers)

So we're looking at webservice usage of entities. Our entities are serializable to xml, the problem might be that the runtime lib is referencing assemblies which aren't supported by silverlight. That might be ok, the CLR loads assemblies on demand and if silverlight never touches code which calls into these assemblies, nothing to worry about.

The problem is with 'subset'. To keep the frameworks small, MS cuts down the mscorlib. This requires that any assembly compiled on normal .NET, needs to be recompiled against the smaller mscorlib. This is the case with the compact framework for example. And this is a true pain.

The biggest pain is in the cut-out overloads of methods and classes. For example a SortedList isn't available on the compact framework. StringBuilder.AppendFormat(string, ...) isn't supported, you need StringBuilder.AppendFormat(null, string, ...) as the overload AppendFormat(string, ...) is 'overkill' apparently.

This makes supporting code which runs fine on .NET on a stripped down platform like compact framework and silverlight a pain: developing new code always results in noncompiling code on these platforms, or worse: you write a piece of code and it's not portable to these platforms because an essential concept isn't there. This is the case with the DI code on compact framework: it's impossible to enumerate the assemblies in an appdomain on the compactframework, as it doesn't have the concept of an appdomain.

that's why we are reluctant to say "we'll support these platforms": it's a ton of work and not a lot of people use it. IF it's easy to port the code, e.g. no recompile or code rewriting for these platforms: no problem.

I can't find any exact information about what's missing in the silverlight 2 framework. The wikipedia article smells like marketing written up front. 'Linq is supported' yeah, what does that mean? If it's that vague, why is it mentioned in the wikipedia article.. So to find out I've to install the beta1 of the SDK. I'm not sure if that will break my 2008 box, so I won't do that on that box, the problem is that installing it on a virtual machine requires vs.net 2008 to be present on that virtual machine as well. And that's very slow to install on a virtual machine.

Isn't there any MSDN lib online about the framework details?

(edit) http://msdn2.microsoft.com/en-us/library/bb404716.aspx It contains the reference of the .NET framework supported.

So looking at that list, it's clear this requires at least a custom build of the runtime lib. Perhaps we can re-use the nmake file of cf.net for the silverlight platform, not sure. It truly depends on how much necessary stuff they've cut out. Also the generated code has to be trimmed down, so similar to the compact framework.

Fun...

Edit: There's no System.Data ? Hmm... I'm not sure, but why don't they have System.Data?

'Linq is supported' yeah, what does that mean?

I think I've read somewhere "LINQ to Objects".

mihies wrote:

'Linq is supported' yeah, what does that mean?

I think I've read somewhere "LINQ to Objects".

Also Expression<> voodoo is possible (The Expression objects are there, so you can construct lambda's compile them to a delegate and run them), but no system.data, so no datatables...

..and expression objects aren't serializable, so you need a serializable querying method

They aren't natively serializable, but you can use serialization surrogates to enable this. (For an example of this see the TextFlow project www.codeplex.com/TextFlow)

Since System.Data is missing from Silverlight, LLBLGen objects would be a HUGE help to building a Silverlight application. After looking at your WCF sample (WCF is supported in Silverlight) yesterday, this would be the way to go for data access.

Because Silverlight lacks certain components (System.Data, SqlClient) to make data access easy, this creates a marketing opportunity for LLBLGen. (Of course, typedviews are out =( )

Microsoft released Silverlight 2 beta 1 yesterday.

http://silverlight.net/GetStarted/ (at the bottom of the page)

tomahawk wrote:

..and expression objects aren't serializable, so you need a serializable querying method

They aren't natively serializable, but you can use serialization surrogates to enable this. (For an example of this see the TextFlow project www.codeplex.com/TextFlow)

But what's the point? Isn't it far better to simply call a method on the service which performs the action for you instead of going through all the mess of serializing a query specification? After all, it's SOA best practise 101 to use message-based services.

Since System.Data is missing from Silverlight, LLBLGen objects would be a HUGE help to building a Silverlight application. After looking at your WCF sample (WCF is supported in Silverlight) yesterday, this would be the way to go for data access.

You mean, entities on the client etc. ? Yes that could work. The thing is though that to make that work first, we've to create an ORMSupportClasses dll which runs on the silverlight platform Sadly silverlight's platform is smaller than compact framework's so we've to create another subset. I'm not sure how easy that is. We use nmake files to build the runtimes so it's not hard to exclude classes from the build. But we've to wait and see what they come up with in later versions of the framework, as MS tends to change a lot between beta1 and beta2 as that's their only allowed window of oppertunity to make changes to an already published api.

Otis wrote:

Since System.Data is missing from Silverlight, LLBLGen objects would be a HUGE help to building a Silverlight application. After looking at your WCF sample (WCF is supported in Silverlight) yesterday, this would be the way to go for data access.

You mean, entities on the client etc. ? Yes that could work. The thing is though that to make that work first, we've to create an ORMSupportClasses dll which runs on the silverlight platform Sadly silverlight's platform is smaller than compact framework's so we've to create another subset. I'm not sure how easy that is. We use nmake files to build the runtimes so it's not hard to exclude classes from the build. But we've to wait and see what they come up with in later versions of the framework, as MS tends to change a lot between beta1 and beta2 as that's their only allowed window of oppertunity to make changes to an already published api.

Is there any news on this front? Or are you holding back your resources until SL 2 goes final? I would be very interested to say the least!

Silverlight is a framework which is very limited and there's little known about the final version of the framework, i.e. what will be in it. So for now, our framework wont' run on silverlight. If you want to use our framework with silverlight, create a webservice and serialize dto's.

Silverlight 2 Beta 2 is out, which contains the full set of libraries that will be shipped in the final version of Silverlight 2. Any news on this front?

RobA wrote:

Silverlight 2 Beta 2 is out, which contains the full set of libraries that will be shipped in the final version of Silverlight 2. Any news on this front?

No.

The point is: is there any real benefit of having llblgen pro code on a silverlight client? I don't accept 'it's cool' as a real benefit . The thing is: the compact framework was also such a framework which would be great, but it was such a big pile of work and it's such a big pain to write new features (as they often break because some class/method isn't supported on the framework so you've to hunt for workarounds, IF possible at all.) that we really dont' want to go there again. Looking at the silverlight framework as an even lighter framework than compact framework, I don't think it will be a great choice to write code for that.

Besides that: you can always use dto's and webservices.

I understand your point, and I think your right. I think the way to go is WCF with DTO's defined in DataContracts. (for versioning, serialisation order etc.) I currently have that setup working, which is quite fast. Only problem what I'm having is state-tracking on the Silverlight client.

But my point was, it would be 'cool' to have a (WCF) Service to which both a desktop and silverlight client could call to, where both clients use LLBL entities via WCF. But still I understand your opinion about it. It's the same opinion as Microsoft, thats probably the reason not to bother implementing System.Data. Silverlight uses WCF and WPF which both work pretty well with DTO's.

Yes, I think readonly DTO's are what's suitable for silverlight. It's not useful for a full blown fat client, otherwise WPF and a .NET client should be used.

for what it is worth, i have ported (hacked) ormsupportclasses focusing on adapter entities/collections and xml rehydration and got it working in a limited use case passing strings back and forth via soap.

i am in the process of redoing the port and addressing some of the hacks that i made in the interest of getting a proof.

template generated dbgeneric source compiles and works in SL after removing serializable code and some other stuff i just stubbed or omitted willy nilly. thus the redo.

once i get a clean port of the dbgeneric subsystem i will examine implementing some of the dataaccess adapter interfaces to wrap async service calls.

while it may seem overkill, i am tasked with creating some high profile business app ui in SL and do very much look forward to a cross platform llble experience. it is a worthwhile experiment for me.

unless there is something that i completely missed i think i can have a workable demo in a few weeks.

the resultant library is around 300k right now but i expect it to be half that when i prune out the code that is not needed/useful in sl.

Frans: 1 Q: since i have compact25 on both ends I plan to add a switch in ormsupportclasses on both sides to emit/consume field index instead of field name to bring the payload size down. off the top of your head can you see an issues with that?

sky.sanders wrote:

for what it is worth, i have ported (hacked) ormsupportclasses focusing on adapter entities/collections and xml rehydration and got it working in a limited use case passing strings back and forth via soap.

i am in the process of redoing the port and addressing some of the hacks that i made in the interest of getting a proof.

template generated dbgeneric source compiles and works in SL after removing serializable code and some other stuff i just stubbed or omitted willy nilly. thus the redo.

once i get a clean port of the dbgeneric subsystem i will examine implementing some of the dataaccess adapter interfaces to wrap async service calls.

while it may seem overkill, i am tasked with creating some high profile business app ui in SL and do very much look forward to a cross platform llble experience. it is a worthwhile experiment for me.

unless there is something that i completely missed i think i can have a workable demo in a few weeks.

the resultant library is around 300k right now but i expect it to be half that when i prune out the code that is not needed/useful in sl.

You might want to look at the CF.NET specific builds. These don't have the remoting stuff, but I don't know if the SL .net variant is compatible with the CF.NET variant (likely it's not).

Frans: 1 Q: since i have compact25 on both ends I plan to add a switch in ormsupportclasses on both sides to emit/consume field index instead of field name to bring the payload size down. off the top of your head can you see an issues with that?

I don't think that's a problem, as the entity is instantiated first, after that the fields are instantiated, so if you use the index to index into the freshly created Fields object, it should be fine.

You might want to look at the CF.NET specific builds. These don't have the remoting stuff, but I don't know if the SL .net variant is compatible with the CF.NET variant (likely it's not).

CF<->SL is hit and miss but the conditionals are helping me out a lot.

biggest problem i had/am having is reimplementing the intention of reflection and componentmodel without dragging in 100k of mono/ssccli OR significantly modifying the usage in dbgeneric code.

the api for reflection and component model has been pruned and then put in a blender. I think I can maintain end to end fidelity using sl reflection. fingers crossed.

glad to hear that index to index is viable. maybe another flag on XmlFormatAspect is warranted in release? ;-)

sky.sanders wrote:

You might want to look at the CF.NET specific builds. These don't have the remoting stuff, but I don't know if the SL .net variant is compatible with the CF.NET variant (likely it's not).

CF<->SL is hit and miss but the conditionals are helping me out a lot.

Ok I really don't understand why they didn't pick the CF.NET framework to begin with. That would have helped a great deal.

biggest problem i had/am having is reimplementing the intention of reflection and componentmodel without dragging in 100k of mono/ssccli OR significantly modifying the usage in dbgeneric code.

the api for reflection and component model has been pruned and then put in a blender. I think I can maintain end to end fidelity using sl reflection. fingers crossed.

I hope it's maintainable for you when we update the runtime libs with bugfixes...

glad to hear that index to index is viable. maybe another flag on XmlFormatAspect is warranted in release? ;-)

Heh, well it's more compact, I'm sure, but not sure if people can live with XML looking like <customer> <1>1</1> <2>Foo Inc</2> ... (but then again, XML should be machine readable, not human readable, it's not for humans, however unfortunately not every human thinks about XML that way... )