Just wondering if there are Silverlight (4) versions of the following assemblies
Microsoft.WindowsAzure.StorageClient
Microsoft.WindowsAzure.ServiceRuntime
Microsoft.WindowsAzure.Diagnostics
No, these libraries are not compatible with silverlight. First, the ServiceRuntime and Diagnostics libraries are completely useless to silverlight. Those are only relevant to hosted roles. As far as the StorageClient, while there is no dll for that there are a number of different approaches. I would recommend using the newly release RIA services for table storage as part of your solution. You can find that here: http://www.silverlight.net/getstarted/riaservices/
Also see this discussion for more details. Basically, you will want to use WCF services to expose you blob storage, etc. to your silverlight client. http://social.msdn.microsoft.com/Forums/en/windowsazuredevelopment/thread/b5e6775a-289f-438d-be79-8414f08c5c78
Related
I've been trying to sort this out for some time now..
I have a few .NET libraries that work as an SDK to an external application. I need to use that SDK both from a WPF Class Library and a Silverlight Class Library. I've been reading a lot of solutions including:
Portable Class Libraries - When I try to add the SDK libraries to the project, it complains that those libraries reference .NET 2.0 libraries and it is incompatible.
WCF RIA - I may be doing this wrong, but everywhere I turn, one step of the process is to create an Entity with the EF. Now, I don't want to access a DB, just those libraries.
But so far, no luck. Any ideas you would like to share?
As far as I know, it may not work if the old .NET 2.0 binaries have references to COM or system libraries. That could relate to your DB implementation. I have had this problem in a project in a previous job. We solved this by creating a WCF service as a in-between solution. That was WCF and not WCF RIA.
If the .NET 2.0 code is really old, you should check if it must be compiled as x86 and hosted as a 32-bits application on AppPool of the site that hosts the WCF service in the IIS.
But this is tricky business, and it all depends on the complexity of the old .NET 2.0 library file and its references.
So, I've been using WCF Ria services for a few months now and I am wondering why would anyone use WCF basicHttp webservice over using WCF RIA Services?
Someone told me that RIA Services is not good for Enterprise Level Applications and I am wondering why?
W/out RIA it seems you have to write validation logic in 2 areas, client and server. Also, RIA handles roles and membership fairly easily.
How much extra work is involved if you want to use WCF basicHttp webservice? What is the benifit over using RIA? and.. Does anyone have any good examples of an enterprise level silverlight application using wcf basicHttp webservice?
Thanks!
The issues with WCF support in Silverlight relates to the limited subset of the .NET Framework embedded in the Silverlight plug-in as it's essentially a scaled down version of the .NET Framework. As a result of the scaled down .NET runtime in the Silverlight plug-in, it does not have the same full support for WCF that you get from standard .NET projects. This was done to make the initial download of SL quick from a client perspective and increase time-to-market of SL as a product. Keep in mind that the SL plug-in has no dependency on an existing .NET framework being installed which is why Linux, Windows Phone 7, and OS X versions are on the market.
As time has progressed they continue to add in-demand features in. For example, Silverlight 5 will support WS-Trust (see here for a complete list of new features in 5).
I recommend you read this resource to see what you may miss out on by trying to call WCF Services from the client:
http://msdn.microsoft.com/en-us/library/cc896571(v=vs.95).aspx
Keep in mind you could very easily proxy out calls to more complex WCF services through RIA Services endpoints which are in effect calling the service directly from server-side.
As for using standard WCF instead of RIA ... there are advantages when your middle tier has multiple client types, though with RIA you could simply expose your endpoints out as SOAP 1.1 endpoints and require people to connect using that paradigm instead of WCF. You do not have to use RIA or nothing; you could mix and match to meet your requirements as you see fit. Personally I am big on just using RIA if at all possible.
It's fair to say RIA Services has had its growing pains. Some of my biggest bugbears with it (such as not having the ability to return complex objects that aren't entities from Invoke methods, and the lack of decent support for being used in an MVVM way) have mostly been fixed in RIA Services SP1. Some people I know using it in huge enterprise applications have had major headaches with it (at least in the early days). I'm not quite sure where things stand now in that respect, as to whether their particular problems have been resolved yet.
That said, I personally think it's a fantastic technology. It makes tasks that are painful with standard WCF services easy (my favourite is being able to specify queries on the client on methods in your domain service that return IQueryable, that execute on the server - making sorting/filtering/grouping/paging a breeze). Whether it's right for you depends on your scenario. It's designed primarily to make performing CRUD operations on entities easy, so if that's primarily what you need then its perfect. RIA Services is designed to be consumed by Silverlight application only however (at least for the moment). You can access them from other clients, but you don't get all the features that makes them so good. So if you need to support other client platforms, it may not be the right fit.
I think RIA Services is awesome, but ultimately it depends on your scenario as to whether they are right for your project. As a technology, it's geared towards particular scenarios, and isn't intended to solve all the world's software development problems. Some people who might complain about it possibly aren't using it in the way it was intended, and pushing its limits (that said, it isn't perfect either, and has had its issues). If you can possibly provide some more details (such as the scale of the application, the client platforms it needs to support, and the number of developers on the project), I'd probably be able to give you some more helpful advice.
Hope this helps...
Chris
I have a Silverlight app hosted in an Azure web role ASP project. The ASP project exposes a WCF service.
I would like to have one set of class definitions for the data types. Someone recommended making a third project (class library) and adding a reference to it from the SL and ASP. I started doing this, but the Silverlight project complained that you can only add references to Silverlight projects.
I then made a Silverlight class library and moved the data classes to it. However, I to add some .dll references, like to the Windows Azure storage client. Then the Silverlight class library tells me I can only add references to Silverlight 4-friendly .dlls, of which Windows Azure isn't one. Fantastic.
Is there something I can do to get around this, or am I stuck with a less elegant, redundant solution?
Multi-targeting is your best bet. There is an article explaining this in Visual Studio from Microsoft at:
http://msdn.microsoft.com/en-us/library/ff921092(PandP.20).aspx
Basically, you create both your Silverlight and standard .NET class libraries, each with a different name, and then include the same files into each. Usually the files are actually only in one of the class libraries and then soft linked in the second one.
The key is to ensure that the code in your files is compatible with both runtimes. If there needs to be separate implementation for some of your methods depending on the runtime then you need to separate these with pragmas (i.e. #ifdef SILVERLIGHT...).
If you're only doing data structures, however, there should be no issues as long as Silverlight supports the objects you are using.
See if using linked files as per this answer does the trick for you.
At the last PDC (can't remember which talk it was) they gave us the information that it will be possible to share assemblies between regular .Net 4 and Silverlight 4.
Unfortunately I can't find anything on this. Was this feature dropped? What options/limitations are there?
(There are similar questions on SO but they don't say if they apply to SL3 or 4.)
See Sharing Silverlight Assemblies with .NET Apps from the CLR Team Blog.
Basically if your assembly only references:-
Mscorlib
System
System.Core
System.ComponentModel.Composition
Microsoft.VisualBasic
That assembly can be shared by both frameworks with each framework using its own version of those references (that is .NET won't be attempting to load Silverlight's version of System.Core for instance).
Of course you will still need to limit your code to features of these references that are actually common across to the two frameworks.
Is it possible to build a good medium to full sized application using just silverlight as a host?
A few things that would be needed:
- dynamic pages (one silverlight "screen" can switch between screens, like a normal app.
- similar to a java applet which launches from the browser
I see that Telerik sells RadControls for WPF...but this is only useful (to me) if Silverlight can be a rich client platform through the web.
Although still a somewhat immature platform, Silverlight 2.0 supports many of the features that I would expect from a platform needed to create full sized applications.
Data access through web services and local data/object query support with Linq
Many feature rich controls such as datagrid, treeview, etc
A very usable subset of the CLR (common language runtime)
Access to restricted local storage on the client machine
It is cross platform
There are already some great add-ons, like Telerik and the Silverlight Control Toolkit
For your specific scenario, Microsoft has published a tutorial on Multi-page Applications
Absolutely. I've been looking into this and believe that it's as easy to do in Silverlight as it is in any other language. Remember that Silverlight 2 uses C# 3.0 and from that you can build anything that's not included in the Silverlight version of the CLR. Also, the fact that Microsoft gives you access to the .NET source code means that you can compile the missing parts of the .NET libraries with your application. (No idea about the licensing issues with that though.)
I've seen a presentation of a full featured CRM application two days ago. Although it's still alpha: It looks and feels like any office application. I don't know details but for me it's a proof of concept.