add reference to Silverlight project from other non silverlight project - silverlight

I have Silverlight application using NHibernate as a ORM. I have projects for Data(mapp and entities), data access and Silverlight. I want to add to SL project reference to data access to execute methods, but SL can only get reference from other SL project.
How can I omit it? If I host data access project on WCF I could reference WCF to SL?
Please help ! :)

Yes, you can expose your data access assembly as a bunch of WCF services and then call them from the SL application.
There is also another way - make a Silverlight class library, and then add new linked files to it - those linked files being the class files from your data access assembly.
Here is a previous answer that explains the linking, although you should note that because your data access classes will now being using the Silverlight runtime you may not have access to all the System namespaces that you want (although you can pick and choose what files you want to add to the new project, and refactor the ones that don't work because of this).

Related

MVVMLight, Silverlight, Entity Framework

I have created
a) a basic application MVVMLight framework.
b) another project in the same solution having an Entity Model (NorthwindModel.edmx).
c) a WCF service to retrieve data through the entity model.
Now I want to link a, b, and c together. How do the project mentioned in a) above interact with the other two? How can I display/bind the data using the edmx in the View of the MVVM?
Do I have to write code in the ViewModel class/classes to achieve this?
I browsed through many websites, checked many questions here on SO, but none seems to throw any light for me in this regard. The examples that I saw involved a lot of coding in the ViewModel class. If that's the only way to go about it, then why do people say MVVM with Silverlight requires very little coding?
You can use WCF RIA Services to bridge the gap between ASP.NET and Silverlight.
Get Started - WCF RIA Services
You will need to create a Silverlight library project, add entity files as link to the project.
This will enable you to use the Entities in your Silverlight application.
how to add files as link
Actually you need a Web project where you host your webservices, then you need your business logic layer and data access layer where you retrieve data, then you need the entities and a silverlight entities project. After this you create your Silverlight project and add web service reference to it and thats it, now you are ready to use MVVM.
I think you could use this to refer how to build a solution with multiple projects and also have entity framework with WCF RIA services.
To ensure you project is running MVVM light you could use Nuget to inject the necessary files into your client project. Information on this is available here

Sorrow with Data Transfer Objects in Silverlight / WCF

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.

Unable to set a reference to System.Data.dll in a Silverlight client project

I created my first Silverlight application. In the client project, I want to define a Dataset object. To do so, I figured I first need to reference the System.Data namespace in the dll of the same name.
When I add a reference to the dll, I get a msg that "it was successfully added," I see thje dll in copied to the bin folder, and then it promptly removes the referenced dll from the bin folder.
Why?
There is no Dataset class in the Silverlight SDK in fact there is no System.Data namespace for Silverlight.
Silverlight only has access to fraction of the features you would find in the full .NET framework. Certainly many of these older concepts such as the DataSet whilst still useful in some places are now being replaced with new approaches such as Entity Framework.
You should consider looking in to WCF RIA Services if you want to do some serious data work with Silverlight.

Silverlight 3 Ria Services reference

I have a Silverlight project where functionality is segregated across multiple Silverlight libraries due to the size and complexity of the application. I am having problems figuring what is the best way to decouple the RIA Domain Service that gets generated from the Website project. I need to be able to access data from the other libraries as they will be loaded dynamically into the main Silverlight application as needed.
I ended up taking the code that gets generated by Visual Studio in the Generated_Code directory of the main Silverlight application and creating multiple Silverlight libraries to separate the Ria DomainContext, the authentication service, entities, and other Domain services that we had written. I then extracted interfaces for the DomainContext, etc and put them in their own library. Using Microsoft's Unity Framework for Silverlight I was then able to decouple all my modules from the main project. All my modules now use the interfaces. There is one IoC container in the main application where I register all of the classes that implement the interfaces and they get injected into the pages as they are instantiated. Not that compliated after all. The only thing to remember is to leave the EnableClientAccess attribute on the Domain Services classes in the server but remove the ASP.Net server project link from the main Silverlight application. I read that they are planning to make this easier in the final release of Ria services/Silverlight 3 since other people have complained about the tight coupling created by the current setup.

Is the System.Web.Silverlight reference needed?

We are just getting into Silverlight development at my workplace. Somehow two of our dev machines have been configured differently. I noticed that one of them has access to System.Web.Silverlight in the reference list, and the other doesn't. Both can create and run Silverlight applications from scratch.
What does System.Web.Silverlight do? Is it a legacy reference? If we need it, where do we get it from?
This dll provided the ASP.NET Silverlight server control which was designed to make it easier to create the object tag needed to describe the silverlight plug-in.
This server-side control was removed as of Silverlight 3, you are now expected to build the object tag yourself.
So yes its legacy so you don't need it.
Anthony is correct. If you are having trouble after you upgrade your products to Silverlight 3 - or just want an example on how to insert your SL app in to a page, create a new SL3 project and check out the sample ASPX and HTML pages (which are pretty much the same as each other now...)

Resources