I am trying to us ILMerge via nuget to merge two SharePoint assemblies in to my plugin dll. The assemblies are;
Microsoft.SharePoint.Client (v16.1)
Microsoft.SharePoint.Client.Runtime (v16.1)
They seem to successfully merge in to my single plugin dll and i can see the required classes etc if I inspect the dll with JustDecompile.
When debugging the plugin, it throws a security exception;
Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0
The code successfully steps over the creation of 'ClientContext()' which is located in the Microsoft.SharePoint.Client dll, but then fails when it reaches the 'new SharePointCredentials()' line which is held in the Microsoft.SharePoint.Client.Runtime dll.
using (var srcContext = new ClientContext(url))
{
srcContext.Credentials = new SharePointOnlineCredentials(username, securePassword);
I am stuck as to why this might be happening. It is Dynamics 365 online and SharePoint online. The credentials supplied to the constructor are correct. Any pointers would be greatly appreciated. I really don't want to have to create a web service instead of ILMerging the SharePoint dlls.
This is almost undoubtedly related to the to the method being called requiring permissions that Dynamics 365 Online does not allow. That is usually the cause of a System.Security.Permissions.SecurityPermission error in a Plugin/Workfrom running in Dynamics 365 Online.
It's been a longtime, but if memory serves me correctly the SharePoint client libraries do not work in Dynamics 365 sandbox plugins (and all online plugins are in the sandbox.)
Unless you can find a way to make the calls without the libraries, using the SharePoint REST API, you'll have to either create a web service or (in my opinion the preferable if possible solution is to) use Azure Service Bus to handle the execution.
As Nick says, unfortunatelly Sharepoint.client.dll will throw you a “System.Security.SecurityException: That assembly does not allow partially trusted callers” error even if you use ILMerge to deploy it.
It is a limitation from Sandbox and there is nothing we can do until Microsoft deals with this.
But for the time being, the best way is to do oldschool httprequests as explained here: https://code.msdn.microsoft.com/SharePoint-Integration-c5f21604
Good Luck!
Related
Previously when provisioning list, libraries, site columns, content types, list definitions etc in SharePoint I typically used SharePoint features, deployed via a WSP - or used PowerShell scripts. This meant I had a package that could be deployed to DEV / TEST / PROD.
I'm working with SharePoint within Office 365 and unsure on the best way to provision lists / libraries / features within SharePoint.
Options:
No Code Sandboxed Solutions
Trying to avoid using these as the information from Microsoft on whether they are deprecated is flaky - however sandboxed solutions would allow me to deploy features with list definitions etc. I know sandboxed solutions with c# are definitely deprecated, but the info around no code solutions is poor.
Apps
I know apps can provision at both the app and host web level, but creating lists, libraries etc using the CSOM seems like a lot of effort and a step backwards.
PowerShell
The SP Online PowerShell is nowhere near as powerful as on-prem SP. I can provision site collections through this, but not lists or libraries...
I'm keen to know how other developers are deploying to Office 365, specifically around provisioning sites with specific list definitions, libraries, content types and so on...
Thanks
Microsoft did clarify the position on No Code Sandbox solutions - http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx
Also if you are looking at using Powershell to deploy then you might want to go down the route of using CSOM from within PowerShell - SharePoint Client Browser for SharePoint 2013 is good for setting up a session also very good for viewing the content of a 365 tenant - http://spcb.codeplex.com/
I have been using code based provision for almost two years without any issues at all.
Server side model works just fine, CSOM has some limitation but stil cool one and JSOM could deliver the same feature set as both CSOM and SSOM, sorta 95% :)
PowerShell is not the best option as it hard to integrate into CI, put some unit testing and regressions.
As you mentioned, this is "step back", but if only you don't have any framework or foundation for that. My libraries are internal one, but there is SPGenesis at codeplex and SPMeta2.
As community don't really care, need or with such libraries for provisioning (yep, let's face it), there are much such libraries at all, but there are lots of "MVP" samples sorta "hello world" level.
Finally, what I would suggest is to invest your time and effort in code based provision.
This is a future, that's it ;)
UPD
Struggling with SharePoint's API inconsistency, bugs, "by-design" behaviour, unaffordable amount of time to write, support and upgrade WSP packages and XML, a team of passionate SharePoint professionals decided to come up with robust, testable and repeatable way to deploy such artifacts like fields, content types, libraries, pages and many more.
Enjoy and let us know how it goes.
SPMeta2 at GitHub
SPMeta2 at Nuget
SPMeta2 Documentation Wiki
SPMeta2 Bugtracker
I am trying to use a Visual Webpart in a sandbox solution. However every I deploy it: it gives me the following error:
Error 1 The deployment type "TemplateFile" of file "VisualWebPart1UserControl.ascx" in Project Item "VisualWebPart1" is not compatible with a Feature in a Sandboxed Solution.
I did some research and found out that Visual WP is not supported in Sandbox solutions. Is there anyway I can have Visual WP in a sandbox solution?
And is there any specific reason as to why Visual WP is not really supported in Sandbox solution.
Use VS Sharepoint Power Tools. It has Visual Web Part item template for sandbox solutions.
http://visualstudiogallery.msdn.microsoft.com/8e602a8c-6714-4549-9e95-f3700344b0d9/
Please follow this link
Restrictions on Sand boxed Solutions in SharePoint 2010
http://msdn.microsoft.com/en-us/library/gg615454.aspx)
it will provide you the detaisl about the limitation of Sandboxed solution.
RoManiac is correct, you can not deploy visual web part in Sanboxed solution as it contains user control.
Mark as answer if it helps you.
You can deploy a solution directly onto your SharePoint Server farm, or you can deploy the solution into a sandbox. A sandbox is a restricted execution environment that enables programs to access only certain resources, and that keeps problems that occur in the sandbox from affecting the rest of the server environment. Solutions that you deploy into a sandbox, which are known as sandboxed solutions, cannot use certain computer and network resources, and cannot access content outside the site collection they are deployed in.
Normally, a Visual Web Part cannot be sandboxed, as it needs to work outside the sandbox in order to load the underlying user control for the Visual Web Part.
This is how to have a Visual WP in a sandbox solution:
http://msdn.microsoft.com/en-us/office365trainingcourse_lab_2_1_topic3.aspx
I'm just learning how to develop an application for Sharepoint.
As far as I can see there are three types of integration into Sharepoint possible:
Sandboxed Solution (limited resource access but easy to install etc)
Farm Solution (installation only available from administrator)
Standard application (maybe .net MVC) with referencing the Sharepoint assembly to access the SPS functionality
Is that correct and complete or am I missing something?
There are quite a few ways to develop for SharePoint depending on your scope, requirements, etc. My knowledge is more in the SP2007 realm than 2010 and my answer reflects that.
JavaScript
Using Content Editor Web Parts you can customize the look of SharePoint, interact with List Data and do some interesting UI effects just using jQuery and the SPServices Plugin. These solutions don't require package and deployment.
Custom Content Type
These can be created through the SharePoint UI or defined through custom XML documents and deployed via WSP. Essentially these are just a collection of field definitions that are related in some logical way. Content types can be added to a list to have all the fields automatically available. In addition, they provide a convenient way of mixing and matching data in the same list (think of roll-ups or backing up list data) though I've never used them in this way.
Event Receiver
Event Receivers can be created to respond to specific events in SharePoint. If you attach an Event Receiver to a list, you can listen for and respond to events like an item or attachment being added, updated, deleted in both a synchronous (-ing) fashion - so you can implement validation and cancel the operation - or asynchronously (-ed) - to do some post-processing once SharePoint is done processing the item. Event Receivers are processed by the Front-End SharePoint server which handled the request which triggered the event. This is different than Timer Jobs and Workflows which are executed by any server in the farm that happens to be available.
Further, Event Receivers can be attached to lists based on their type (apply to all lists of this ID type) or they can be associated with a Content Type and become associated with a list that way (when the content type is added to the list, so too is the event receiver added).
Feature Receivers are a special kind of Event Receiver in that they respond to a Feature
being activated or deactivated to do some additional work. Many people refer to this extra work as Feature Stapling since it lets you perform additional tasks on-demand that couldn't otherwise be done using just XML documents.
Timer Job
A Timer Job is a piece of code that is run on a schedule. It's not executed in the W3WP process like Event Receivers are but rather via the TimerService. Because of this, certain features or values are missing from the SPRequest object. Developing Timer Jobs is more difficult and, in practice, more error prone, more difficult to debug, etc. than Event Receivers.
Workflow
Workflows can be created using SharePoint Designer or Visual Studio. The major difference between these are features available to you at design time. SharePoint Designer Workflows are easier to create and get going but tend to be buggy in SharePoint 2007. Further they are not easily packaged and deployed across environments but rather are associated directly to the list in which you created them (in 2007; in 2010 there is extended capability to allow packaging or even migration into Visual Studio for more complicated customization).
Using Visual Studio gives you more depth and capability but like Timer Jobs they are often difficult to "get right" and they are also processed by the Timer Service process.
Web Part
A custom Web Part is very similar to a regular ASP.NET web part with some extended capability within the SharePoint context. You have access to the SPRequest object and thus all the contextual information (current user, current list/web/site, etc.) to do your work. You can access external databases, make use of most ASP.NET controls, etc.
Custom ASPX Page
If a Web Part isn't sufficient for your needs or you want control over the full page, you can create SharePoint-enabled web pages. These are standard ASP.NET pages decorated with the proper SharePoint master page and deployed into a subdirectory of the hive LAYOUTS directory. With this you have similar access to the current request state as with a Web Part but you have more control over the entire page render.
Custom Web Application
If you have need for a standalone application, you can still take advantage of SharePoint's authentication and authorization tools without running directly in its context. To do this, create an IIS Web Application and set the Application Pool Identity to the same as SharePoint. Alternatively you could make a virtual directory within your SharePoint application pool but this is generally not recommended. You will still be constrained to using the .NET Framework 2.0 runtime if you want to use the SharePoint Object Model at all. This setup seems rarely used in the field since most of the time you can accomplish your needs by just using custom ASPX pages or web parts.
Regarding your specific questions:
Sandboxed solutions are just a special type of solution that restricts the namespaces your web part, etc. have access to. For instance your code can't reach out to access lists outside of its permission area. It can't send email on your behalf. You can increase your rights by using custom permission sets but this is an advanced topic. I just wanted to point out "sandboxed solution" isn't a type in and of itself, it just describes a restriction where previously none existed (SP 2007 GAC-deployed solutions).
Regarding your question regarding an MVC application using the SharePoint Object Model, like I mentioned you are still restricted to running in .NET 2.0 runtime.
EDIT: I forgot (at least) one more option!
List Service / Other ASMX Services
SharePoint has a number of web services you can consume to interact with Lists among other things. In this case, your application can be developed using any technology (or runtime!) you wish as long as it knows how to consume the ASMX services. The functionality available isn't as rich as using the Object Model directly (which is why I often forget to consider it) but it does allow your code to be more decoupled from the SharePoint environment itself. In 2010 there are a lot more options for Client Services to provide even greater functionality.
For developing a solution in visual studio you can go for Sandbox solution and farm solution. If you are having SharePoint 2013, then you will have another better option which is App Part development.
Since Sandbox solution is depricated from SharePoint 2013 onwards, i suggest you should not go with Sandbox solutions. Better to go with App Part development.
I am adding a service reference in VS.NET 2010 using
http://[orgname].api.crm.dynamics.com/XrmServices/2011/Organization.svc?wsdl
URL but it doesn't get the entities from the CRM, just get rest of the information
so how do it add reference to it, i have checked
http://bingsoft.wordpress.com/2010/10/21/crm-2011-beta-discovery-and-web-service-urls/
Have you tried using the crmsvcutil tool. http://msdn.microsoft.com/en-us/library/ff681561.aspx
Here you can find the steps (they are pretty straightforward) you need to follow to work with your CRM Online instance. You use the crmsvcutil.exe tool to generate the metadata of your organization.
I need to programatically interface with SharePoint folders, files and lists from outside SharePoint. Most tutorials focus on working within SharePoint itself, or at least on the same server where SharePoint is installed. I need to automate some tasks from completely different servers -- tasks that require reading SharePoint lists, browsing folders, checking files out and in, reading files stored in SharePoint libraries, etc. It used to be easy using UNC folder and file paths. Now many of our SharePoint sites don't allow UNC access (probably for good reasons), but my needs are the same. What languages / libraries / interfaces will allow this? I'd like to be able to do this from server-side .NET code and from PowerShell scripts (not on the SharePoint server). Thanks for any pointers.
SharePoint offers a web services API. I won't claim it's particularly friendly or fun, but it does work. You can get started learning here.
Use Sharepoint Web Services which provides a suite of standard web service endpoints you can use to do most anything you can through the objet model API.
You can use SPServices whichis a jQuery library which abstracts SharePoint's Web Services and makes them easier to use. It also includes functions which use the various Web Service operations to provide more useful (and cool) capabilities. It works entirely client side and requires no server install.
Here's anoth example of SPServices in use Example
if you are using SharePoint 2010 you can use the Client Side Object Model (http://msdn.microsoft.com/en-us/library/ee537247(v=office.14).aspx). It will help you to access sharepoint objects, lists and everything. There are 3 types one for C#, Silverlight and Javascript.
there are more than one methods:
use csom (client side object model)
use rest services
use sharepoint out of the box web services.
If you want to be able to choose the language in which you program, I'd recommend using the Sharepoint REST API. I'm writing my service in Java, requesting data in JSON, and using Jackson to parse it into Java Objects.