Absolutely, if you have SPContext.Current, you don't need to dispose any objects inside. The point is, that SPContext.Current is binded to a SPRequest object, which represents current web page request. So basically, if you will dispose SPContext.Current.Web in your code, it will no longer be available for any other pending code.
But, if you will create your ...
So I was intregued as to the actual answer as I have always left it in. I guess one of the reasons why is that I think its good practice and hasn't caused me any problems. This plus Visual Studio puts it in when you override the function.
However, it looks like you should leave it in as when reflected this is what's implemented underneath:-
public virtual ...
Pass around ClientContext.
Call .ExecuteQuery() as few times as possible, bundle/batch up with .Load().
Once is usually enough, only in a very few cases do you need more.
Do not pass around Web.
You need to reference other members from ClientContext, such as Site.
Do not pass around an URL (either as String or Uri).
Initialization method ...
But you can make such calls in SharePoint 2013:
var crossSiteContext = new SP.ClientContext("http://url-of-another-siteCollection/");
var crossSiteWeb = crossSiteContext.get_web();
It depends on what you need to do.
RunWithElevated only runs as the Application Pool Identity, so you might not have access to other web applications, only other site collections in the current web application, but you can be guaranteed that you will be running as a user that exists (the AppPool identity).
With UserToken, you need to be sure that the user ...
We can either manually do it through central admin or by using powershell commands.
I would prefer doing this through powershell
To uninstall and remove Farm solutions use the Uninstall-SPSolution and Remove-SPSolution cmdlets (Use -WebApplication attribute if the solution has webapplication-scoped resources):
Uninstall-SPSolution –Identity ...
Generally speaking you will want to use SPQuery to only query items you're interested in.
Unless you're doing
SPList oList = web.GetList("XYZ");
for(int i=0; i < oList.Items.Count; i++)
string strLstItemName = oList.Items[i].Name; // << BAD, as you use Items here, so you fetch them from DB each loop
there shouldn't be any relevant ...
AllowUnsafeUpdates=true; is not required to add/delete/update list items unless you are doing these operations in Page_Load or other Get methods. Both CASE 1 and CASE 2 does not look good in terms of best practice.
Problems with both case code:
Do not use oSPWeb.Lists["MyList"]; instead use oSPWeb.Lists.TryGetList("MyList1");
Do not use list.Items.Add(); ...
Yes its possible to have a single server SharePoint 2016 development Farm.
The machine needs to have atleast 16 GB RAM available. The processor should be 64 bit and 4 cores. Also there needs to be 80 GB space available for system drive and 100 GB for second drive.
Step by step guide - Single server 2016 installation & configuration
Install SP 2016
You need to understand SharePoint from an end-user perspective
You need to try to implement business solutions using the features provided by the SharePoint platform. Only when you can't should you consider opening Visual Studio and writing custom code.
You need to understand that SharePoint development is not like other .NET development. You have to have a ...
It depends on how frequently you want search to include recently added content.If the content on any site is updated too frequently (like Sharepoint.StackExchange :-) ) and you want user to search it out, Set high frequency.
However, Remember that Crawling happens at the cost of performance.
Please check this article as well how to plan crawl : http://...
I would recommend you to store things like connection strings in secure storages. For example, SPWeb.Properties require only read permission for site, and they can be revealed easily by any advanced user, for example using SharePoint ECMAScript Client Object Model.
So if you store user name and password for accessing DB in the connection string, it would be ...
Any kind of hardcoded path is, in general, opposite from best practice so opening a SPWeb or SPList object directly from its full server URL is a no-no.
To get the SPWeb object, if you are sure your code will always run in your desired web it is perfectly okay to use SPContext.Current.Web. In all other cases, you might want to look at something like the ...
You can define another navigation provider that pulls the data from a different source. Typically I use a SharePoint list, but you could use an XML file, database, or whatever makes the most sense for your requirements.
The menu control placed on the MasterPage can either have the data source repointed, or you could decide to put a second control on the ...
Matt and Randys' Master Pages make branding from scratch really easy. If you need hep with basic Themes rather than branding (or to save hours of work) use Microsoft's Theme Builder - I wrote a post on what everything relates to here: -> Theme-ing really does help you save some time on the base CSS.
Many points can be taken in consideration while choosing web application or site collection. Some important ones are:
1) Web application provides isolation. If your web application uses a unique application pool in IIS, the isolation is at Process level. If your web application uses a shared application pool in IIS, the isolation is at Application Domain ...
You can do it in InfoPath, cascading drop downs. But since you said you need to do it in jQuery, there is a very useful library, called SPServices, available to assist. Marc has created a function in the library to do cascading drop downs, which is exactly what you want.
Look over that information and see if it's helpful.
I used the following techniques a few times (with SP2007 and SP2010) :
Create a SharePoint project "YourLibrary", that contains all the shared code.
Package the code in a separate WSP
The most important part : create a Farm Feature, empty, auto-activated at the install
The 3rd point is important, because your projects that depends on this ...
It depends on the "context". In a web part or application page, use SPContext. A lot of example code you see on the web uses a console app for simplicity - these would use the SPSite constructor with a string parameter representing the url. In a Feature receiver you'd use (SPWeb)properties.Feature.Parent.
Bottom line is, if the code is being executed ...
In the code behind the code may look like this:
var url = SPContext.Current.Web.Url + "/_layouts/myPage.aspx;
"CustomScript", "OpenDialog('" + url + "', 994, 1000, 'Title of the script', null);", true);
function OpenDialog(strPageURL, width,...
About your code: Since you are checking the value of an SPListItem in a different SPWeb but in the same SPSite, I think something like this will be better:
using (SPWeb web = properties.Site.OpenWeb("WebName"))
SPList list = web.GetList("/Path");
SPListItem item = list.GetItemById(theID);
From the MSDN article you posted:
Do not ...
As per my suggestion, Better to use field's internal name, in future if you may rename your field that doesnot affect the field which you updating on it. because field's internal name never change so no need to update code, whereas display name changed on rename field, so you need to update the code as per you define(renamed) field name
Objects like Web, ClientContext are passed by reference, that is they are not copied. So there is no need to worry about performance. However, as mentioned by @eirikb, pasing ClientContext between methods make more sense as you can then load whatever objects you want from it inside the method.
If you can whip up a console app and schedule it and it does the job - then great. I probably would rely on PowerShell. I prefer being able to monitor and alter scripts if needed without having to recompile or open up VS to make the edit. When working with data I've also used SSIS packages on SQL server.
If you are running SharePoint locally you have an ...
Assuming your site collections are in same web application, you can easily use xml sitemap.
Below are the steps:
1) Create a xml sitemap(myxml.sitemap for example) at root web application directory.
2)In web.config, under providers section, add :
<add name="MySPXmlContentMapProvider" siteMapFile="myxml.sitemap" type="Microsoft.SharePoint.Navigation....
I've seen some organizations use a single site collection to hold everything, and create more site collections than they need so they struggle with administration and maintenance. Both of those extremes can be bad. It is really about trying to find the sweet spot for how your sites will be used and maintained.
Awhile back I wrote a pretty detailed blog ...
I would consider looking at Web Templates - see Anders Rask's slide deck & code from #SPSUK http://sites.wizdim.com/andersrask/sharepoint-2010/slide-decks-and-demo-code-from-my-sharepoint-saturday-uk-session/
In essence, save as a site template, import to Visual Studio and package up with the appropriate elements (cutting out elements you don't really ...
There are a number of options. Wictor has an interesting post - http://www.wictorwilen.se/Post/Six-ways-to-store-settings-in-SharePoint.aspx
Personally for the complexity of some configuration elements within the systems i work with I would use the web.config and utilse the SPWebConfigModification class to apply the changes to all Web Front End servers.