Am working on a Silverlight integration with SharePoint. I use the Client Object Model to fetch information from list of multiple site collections. To do this successfully, I currently use the ClientAccessPolicy.xml for the Client Object Model to fetch data from multiple Site Collections. Now the problem that I have is, my client does not allow the file ClientAccessPolicy.xml to be put on the Virtual Directory. Is there a workaround to this? Is there a way to fetch the lists from Site Collections without ClientAccessPolicy.xml
I`m fairly sure the only way to bypass the lack of a clientaccesspolicy.xml when using Silverlight is to create your own server-side web service proxy that wraps the SharePoint API/Services calls and exposes whatever you want to send to Silverlight from that web-service, keeping it in the same domain as the Silverlight app.
Related
Currently I am working on an ERP Project, Using Entity FrameWork and WCF at server side and WPF at client side. Since it is a big project , we have a lot of entities.What we did so far is, Created Service contracts for each Entities and exposed with multiple endpoints.The Problem is we had to add Service Reference for each Service and we are feeling difficult to manage these web services.
1.Is this a proper way ?
if yes,
2.Is there any way to allocate these web services (in classes or folders)..?
Thanks in advance.
You don't want to keep generating the proxy classes in the client.
Just move the POCO classes and contracts to single assembly which you can reference in the server and client. Then create the necessary channels in the client with ChannelFactory.
ChannelFactory(TChannel)
If you are dealing with many services you can create routing service which will behave like facade. Once you have routing service defined then all requests are going to be sent towards routing service and then, based on some criteria, provided to specific service. You are dealing with only one service so if any change in sub-services occures, for instance endpoint's address is altered, then such a change needs to be reflected only in routing service.
Finally i got how to deal with multiple Services
i am considering to use svcutil.exe in order to create proxy classes.
so that we can arrange those classes in folders, and also we can
get more control over proxies
I am building a proof-of-concept line-of-business Single Page App. I want to use ASP.NET web api for the REST service layer, and Backbone.js and Require.js on client. I would like to use modular structuring of js files and templates (Require.js) so the source code of the app would not end up in one html page.
I havent found an example how to lay out the project in Visual Studio, and what project type should I choose. Should Web Api be in one project, and web application in another, or should it be mixed. Any advice or best practice would be very appreciated.
Thanks!
What I did previously for the same goals was to put the WebApi and Web application in the same project. It makes thigs easier from the point of view that you will everything set up when you create the project in Visual Studio.
There is a slight problem in having the webapi in a different project: since you have to put that on a separate hosting or eventually on the same hosting but bound on a different port or virtual directory, it may need some time setting up IIS... eventually in the past we used the Url rewrite module to redirect calls from the Web App to the Web Api application. There may be simpler settings but again it will require a bit of time, depending on your confidence in setting up IIS...
For starter/proof of concept probably having everything on the same application will make things smoother. You may want to keep Domain Models and DB access in separate projects so if eventually you end up splitting the WebApi from the Web App you can still reference those two without problems.
In the end, the Web Application will only have one controller with one action (Home/Index maybe) and this will be the point of contact that will deliver all your html/css/js to the client. Being a SPA, everything from now on will be managed by Backbone on the client (navigation too), with the occasional call to your JSON Web Api endpoints to get and post data.
I've made a service for my silverlight 4 database (SQL) affairs (VS2010, C# ASP.NET web app), now I'm writing my SQL functions in this service, how can I use this functions? I've read some articles about deploying services but I think my case should not be much complicated, I have a big ASP.net web app with several web pages (I have a server running on winserver2008), it works great, also I have a SL app, what kind of files should I upload for using service? do I need an asmx? how can I create it? should I change anything in web.config?
what is the easiest way to use my service for communicating between SQL and SL? thanks
WCF RIA Services is the way to go. You do not want to bother with old-school ASMX web-services.
You will use an EF model and a DomainContext on the server to handle all database access via CRUD methods (Create, Read, Update & Delete).
On the client you will use the generated Domain Service client to access data.
Notes from my previous RIA post:
My suggestion is to always create RIA Service libraries instead of adding directly to a Silverlight application. Then you can link the Client-side library to any number of Silverlight applications, then link the .Web part of the RIA library to your website to provide the WCF service. Again the key is to migrate the config settings.
It will probably make a lot more sense if you create a new RIA services library project, add your EDM etc, then link the halves to a separate Silverlight app and your new ASP.net website.
Step-by-step:
Create RIA Services Library project by selecting Add New Project. Select Silverlight on the left. Select WCF RIA Services Class Library on the right. I will assume it is called the default name RIAServicesLibrary1 for this example. It will create a Silverlight client library called RIAServicesLibrary1 and a standard .Net library called RIAServicesLibrary1.Web for use by the Web server.
Add your EDMX to the RiaServices.web project. Select Add new item. Select Data on the left. Select ADO.Net Entity Data Model on the right. I will assume it is called the default Model1.edmx for this example. Connect it to your database tables etc.
Build your project so that the next step will find your data model.
Create a Domain Service referencing your EDMX models in your RiaServices.web project. Select Add new item. Select Web on the left. Select Domain Service Class on the right. I will assume it is called DomainService1.cs for this example. Choose your data items from the Add New Domain Service Class popup window by ticking the checkboxes. A set of RIA services objects and methods will be created for each item you select.
Add a reference to the client Ria services library project (RIAServicesLibrary1) to your Silverlight application.
Add a reference to the web RIA services library project (RIAServicesLibrary1.Web) to your hosting web application (e.g. you ASP.Net website).
Copy/merge the various sections in the RIAServicesLibrary1.Web/app.config file into your <webapplication>/web.config file. This will include any connection strings and the module sections.
Build the project again so that the Data Source window will see your new Domain Context data sources.
Use the RIAServicesLibrary1 client object (called DomainService1 in this example) directly from your Silverlight code like this:
DomainService1 client = new DomainService1();
or use the Data Sources window to drag/drop a new grid etc onto a page.
If the Data Sources window is not visible select the "Data" menu then the "Show Data Sources" option.
For more information try this Microsoft link: Using WCF RIA Services
I am currently getting myself up to speed with SharePoint 2010 and I am working my way through the different way SharePoint can expose silverlight applications.
As I understand it, the client object model is more restricted, and is for other applications to interact with SharePoint via WCF for example. An example would be a custom build system that retrieves reference data from SharePoint lists.
The server object model provides more functionality in SharePoint. One example is code written for a web part.
I have been told to deploy a silverlight application, you create the xap, make it accessible by SharePoint web front end, create a silverlight web part and point to it.
So, my question is, assuming what I have previously mentioned is more-or-less the case, can SharePoint access the server object model or is it the same as an external system for example, and uses the client object model?
I am learning all of this so happy to receive feedback on anything I may have not understood correctly.
You would access the client object model from Silverlight. Silverlight is a client. It runs in the user's browser, so it is not on the server, and therefore cannot access the server's features except via service calls. The client object model will provide you direct integration with various lists and functions, and makes it very easy to integrate.
Check out this video for more:
http://channel9.msdn.com/learn/courses/SharePoint2010Developer/ClientObjectModel/SilverlightClientObjectModel/
We have a Silverlight app which we wrote which calls a Silverlight-enabled data service. The Silverlight app cannot require a login, as it is required to present data to the unauthenticated public.
We have some schmoe who took the time to examine our Silverlight app, one way or another figure out what service it is calling, and then wrote his own client to slurp off the data so he can post it on his site and pretend like it is his. We need to prevent this.
How can i limit my data service somehow to ONLY accept requests from my silverlight app? I tried using the allow-from domain uri setting in the clientaccesspolicy.xml file to limit access to the service only from the domain in which the silverlight app sits (say mydomain.com). This did absolutely nothing though, and the service is still serving up requests to clients from outside the domain. (I tested this by putting my SL app on a different domain under our control).
What is the proper/best/most effective way to limit the data service so only our app can use it? Thanks!!!
I'm using SL 3 and .NET 3.5.
The clientaccesspolicy.xml tells the Silverlight application which Webservice it can consume. Not preventing people accessing the Webservice.
You can try using a authentication login even though its not required. This prevents 'schmoes' accessing your webservice.
Also use Dotfuscator to prevent 'schoes' to disassemble your Silverlight application and acquire the login.
Silverlight webservice security follows the same patterns you'd use for ASP.NET security, especially services exposed to AJAX. The best way to do make use of ASP.NET's authentication.
RIA Services is an even better way to handle this. It rides on top of the ASP.NET authorization, but validates on both the client and server-side automatically to combat service spoofing. It let you take care of both client and server-side authorization by adding attributes to your methods indicating that the method requires authorized access, and by which groups or users if you need to be specific.
In addition to wire-side security and obfuscation, remember that clients can attach a debugger to Silverlight applications running in their browser. See this example from MSDN Magazine's Security IQ Test, November 2008.