Given that Silverlight uses a cut down .net framework, can I reference Unity from a Silverlight project?
There is a special version of Unity for Silverlight which you ou can donwload from here. (If you use nuget it will reference the correnct dlls for you automatically)
However Unity for Silverlight has some restrictions:
XML configuration is not supported.
Because of differences in the Silverlight security model, only public types can be created and injected by the container. The desktop version allows you to also inject internal types.
The Unity interception mechanism is not supported.
Note that (thanks the info to #Sebastian Weber) Interception is also supported since the release of EntLib Silverlight Integration Pack. See MSDN for additional information.
But you can't use the Unity "desktop dlls" in your SL project.
It exist a special version of Unity for Silverlight. You can find it here
The latest version is 2.1 and is supported for Silverlight 3-5
Related
I have created a VS2013 solution that contains multiple projects. One of those projects is a portable class library targeting .NET 4.5+, Silverlight 5, Windows Store 8+ and Windows Phone 8 and this project contains a reference to an OData service in an accompanying web application.
The portable class library references Microsoft.Data.Services.Client.Portable (among others), added via nuget (WCF Data Services Client).
I have then added the portable class library to a WPF (.NET 4.5) application, a Windows Store application and a Windows Phone application and written some very basic test code to access the service. This works fine in Windows Store and Windows Phone.
The WPF application however will not compile. The errors are...
The type 'System.Data.Services.Client.DataServiceContext' is defined
in an assembly that is not referenced. You must add a reference to
assembly 'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The type 'System.Data.Services.Client.DataServiceQuery`1' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The thing is, I also added the WCF Data Services Client to the WPF application via nuget, but it does not add a reference to the portable library (packages\Microsoft.Data.Services.Client.5.6.0\lib\portable-net45+sl5+wp8+win8\Microsoft.Data.Services.Client.Portable.dll), instead adding a reference to the full framework 4.0 version (packages\Microsoft.Data.Services.Client.5.6.0\lib\net40\Microsoft.Data.Services.Client.dll) - which in turn is causing the error I am seeing.
Is there something I am doing wrong here or is this an error in the installation package? Note that if I delete the offending reference and add the alternative reference manually then all is well so though I have a work-around I would still like to know if I am the cause of the error.
Looking at the NuGet source code this behaviour seems to be by design.
The WCF Data Services Client contains assemblies for the following frameworks:
.NET Framework, v4.0
.NET Portable, net45, sl5, wp8, win8
Silverlight, v4.0
Installing this NuGet package into a project that targets .NET 4.5 will result in the .NET 4.0 assembly from the NuGet package being referenced. NuGet considers the more specific .NET framework to be a better match for your WPF project which targets .NET 4.5.
There is a comment in the NuGet source code about this when it looks for the best matching assembly in the NuGet package.
// Let's say a package has two framework folders: 'net40' and 'portable-net45+wp8'.
// The package is installed into a net45 project. We want to pick the 'net40' folder, even though
// the 'net45' in portable folder has a matching version with the project's framework.
What VS project type should I choose so that the data-transfer-objects that I create in it can be accessible in both in my Silverlight project as well as my WCF service project.
(I want to be able to reuse the DTOs that I define in both projects instead of having VS generate a new set in my Silverlight project when I create a web-service reference to the WCF service).
IE, my question is can the project be a Windows class library, or should it be a Silverlight class library (so as to reference it in both my Silverlight project as well as the WCF project).
You've got three main options:
Create two class library projects (one targeting Silverlight, the other the .NET Framework), and share the files between them, as I discuss in this article: http://www.silverlightshow.net/items/Building-a-Silverlight-Line-Of-Business-Application-Part-3.aspx
Create your class library as a Silverlight class library. Silverlight applications can't reference class libraries that target the full .NET Framework, but applications targeting the full .NET Framework (such as you WCF Service) can (generally) reference class libraries that target the Silverlight runtime.
Try out the Portable Library Tools (currently in beta): http://blogs.msdn.com/b/sburke/archive/2011/01/23/3-screen-coding-is-here-portable-library-tools-allow-you-to-target-multiple-net-platforms-with-one-binary.aspx
Have you thought of using RIA Services (or WCF Data Services) instead of a plain WCF service? RIA Services / WCF Data Services handles this problem for you, and adds other great functionality into the mix.
Hope this helps...
Chris Anderson
I am trying to integrate IronPython in my Silverlight application but am unable to do so. After downloading the binaries, every time I try to add the dlls as references in my VS2010 solution all I get is an error about them not being compiled for Silverlight. I have even tried downloading the source distribution, but cannot set the various projects making up the solution to build against Silverlight (the only choices I have are different versions of the .net framework).
As the IronPython website explicitly states Silverlight compatibility, why is it not working? Is there any easier way of getting scripting capabilities in my Silverlight app?
You have to use binaries from IronPython-2.6.1\Silverlight\bin folder in Silverlight.
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
I wanted to add System.Data.Linq to my Silverlight 3.0 app, but the only references that are available to me are listed as version 2.0.50727 or lower. Shouldn't I have access to more than that?
In my project's properties, my Target Silverlight Version is set to "Silverlight 3.0" (the only option), and I'm using Visual Studio 2010 Beta 2.
Is this expected behavior, or should I be able to add that reference, and more?
You can't access System.Data.Linq in Siverlight, this dll would make no sense in the sandboxed client-side silverlight runtime. Hence no such silverlight dll exists. What you probably need to be looking into is Entity Framework on the server plus WCF to access the data from Silverlight.
For reasons best known by Microsoft all the standard Silverlight dlls have the 2.0.5.0 version numbers even the new ones added to the Silverlight 3 SDK.
This is the version number of the controls in Silverlight 3. It confused me at first. Also it's System.Linq in Silverlight and should be included by default when you create a new project.
Silverlight 4 is a separate download to VS2010.