This is a simple question, more theoretical than anything.
What's the real difference between a custom object and a PSObject in Powershell ?
Why and when would you create them ?
Thanks!
PSCustomObject arrived with PowerShell 3.0. I woulddefine it as 'refined version' of PSObject as it addresses a couple of annoyances with PSObject including display order (PSCustomObject keeps the order you specified), some performance enhancements.
Here is a link to more discussion on this.
PSObject is used as a wrapper object for all objects in PowerShell. This includes custom objects. If you create a PSCustomObject, you're really just creating a PSObject under the covers.
Related
while accessing the data iterated over foreach is not visible outside of foreach loop, Even if i can access then again foreach is loaded automatically.
can somone explain about this typical behavior of foreach in logic app
?
SS for your reference :
Timely help would much appreciated...
Thanks in advance !!!
The output of an action called within a ForEach would be an array of objects. You can use the square bracket operator in case you want one specific item or any of the collection functions as described here:
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-definition-language#functions
Could anybody help me to get List Item by unique Id in SharePoint without using List? I know the List Item unique Id, but I haven't information about List. Using Client Object Model I can do the following:
using (SP.ClientContext clientContext = new SP.ClientContext(...))
{
**SP.List list = clientContext.Web.Lists.GetById(listId);**
SP.ListItem listItem = list.GetItemById(listItemId);
clientContext.Load(listItem);
clientContext.ExecuteQuery();
...
}
Unfortunately, in this code I use listId, but the problem is that in my task I don't know listId, I have only ListItem Guid. Since I have unique Id, I believe that there must be a way to get this Item without using any additional information.
You've posted a snippet with a Client Object Model, so I suppose it's a preffered object model for the solution. However, if it's acceptable for You, I've found some information on how to achieve this using server side object model, which You may find helpful.
It seems that this can be done using SPWeb.GetFile(Guid itemGuid) if the item exist in the root site.
If you want it to work also for subsites, you can use SPWeb.GetSiteData method to invoke caml retrieving an item as explained in this article: http://www.chakkaradeep.com/post/Retrieving-an-Item-from-the-RootWeb-and-Subwebs-using-its-UniqueId.aspx.
You can also take a look at this thread on SO for some additional information:
SharePoint: Get SPListItem by Unique ID.
If you have any issues using those methods, let me know. I'll also look for alternatives for this to run with Client Object Model and I'll post them if I find some, however, it seems to be more difficult to achieve.
I read the msdn article about disposing objects in http://msdn.microsoft.com/en-us/library/ee557362(office.14).aspx
now I'm really confused about this.
consider this example
SPList List = SPContext.Current.Web.Lists["DemoList"];
SPListItem Item = List.GetItemById(ItemID);
is it ok to use this or better to use:
using (SPWeb web = SPContext.Current.Web)
{
SPList List= web.Lists["DemoList"];
SPListItem Item = List.GetItemById(ItemID);
}
or it makes no difference
thanks
You don't need to dispose of the SPWeb in this case as you didn't create it. You only need to dispose of an SPWeb object (and SPSite object) if you are responsible for instantiating the object.
So in the following instance you would need to call dispose (or have dispose automatically aclled using the "using" statement) as you were responsible for new-ing up the SPSite..
void CombiningCallsBestPractice()
{
using (SPSite siteCollection = new SPSite(SPContext.Current.Web.Url))
{
using (SPWeb web = siteCollection.OpenWeb())
{
// Perform operations on site.
} // SPWeb object web.Dispose() automatically called.
} // SPSite object siteCollection.Dispose() automatically called.
}
The "using" statement is equivalant to calling web.Dispose() at the end of the block, but is more readable and the disposal is less likely to be forgotten.
If you are worried about whether you have any undisposed objects in your SharePoint code I strongly recommend using SPDisposeCheck. This tool will analyse your assembly and point out all the places where you could have an undisposed object. It's great! :-)
I read a statement about SPWeb once, which said "SPWeb is like a cute girl - if it is not yours, don't touch it, if it's yours - take care of it".
So, if you created a new instance of SPWeb class, you have to dispose it. If you took it from somewhere else - the SPContext.Current object - leave it as is.
UPDATE
Oh, I found the post and it is a little different:
Dispose is like a pretty girl, if you
see it, call it... but don't break
rule #1. i.e. don't call a pretty girl
that isn't confirmed unattached, .. if
her large mammalian boyfriend finds
out, he may knock your teeth out. This
rule applies to general .NET as well.
Just to be clear, since the link you reference is to SharePoint 2010... There are several changes between WSS 3.0 and SharePoint 2010 Foundations (essentially WSS 4.0), one of which is that you are no longer required to dispose of a SPWeb object, only the SPSite object when referenced from the SPSite in a using block. Seems to be a bit out of synch with the link you provided. I am not sure if that documentation is out of date or will be updated. However, I have heard the SPWeb not needing a dispose call several times. Not sure in what context that is true now after reading that article. Something that will be further expanded I assume as the release date approaches.
In regards to the code you reference above, it as others have said, since you have not created the object, you do not have to manage the object. In fact, if you get a SPSite (and SPWeb in WSS 3.0) from the SPContext object you will run into issues with SharePoint if you dispose of the object, since the SharePoint runtime instantiated it.
As mentioned above, SPDisposeChecker is a very useful tool. Roger Lamb also has a great article explaining Dispose best practices
http://msdn.microsoft.com/en-us/library/aa973248.aspx
http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx
I have 2 question here,
Scenario:
I have created a document library with my own list definition, having the default document library settings. There are quite number of document libraries created using my definition. Now I wanna change the version settings to limit number of major versions to 5.
I came across "MajorVersionLimit" List element property of Schema file, unfortunately this is available only for Content Migration schema alone. It didn't work for me.
Question 1:
Is there any simple mechanism where I can enable such settings across my site collection?
I know I can write piece of .NET code to change this.
Question 2:
If I do this, Will it break the list from its list definition?
Thanks in advance.
~Yuva
I don't know how you can set these values via the configuration file, but they are exposed on an SPList object. So the trick is to find a way to capture when a new list is created from your template, and then set the fields (SPList.MajorVersionLimit and SPList.appropriately) appropriately.
I haven't tried this, but here's where I'd start.
In the ListTemplate element configuration file, set the 'NewPage' property to a aspx page that should get displayed when the user clicks the 'create' button in the UI.
In the code behind for that page, create the list manually (using the OM) and set the properties.
There may be a better way, but I don't see it. Good luck.
The MajorVersionLimit argument does work with schema.xml. Just remember to check the Create a version each time you edit a file in this document library? option.
It's actually not true, you can set MajorVersionLimit through Scheme.xml (as List element attribute), it worked perfectly well for me . There is no support for these attributes through intellisense.
The solution was described on Doug "bobthebuilder" McCusker blog ( http://suguk.org/blogs/sharepointhack/archive/2008/01/14/7809.aspx )
In my opinion the easiest way to modify existing webs is to write a small PowerShell script setting the spWeb.MajorVersionLimit, some thing like this:
#Set up connection
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$spSite = new-object Microsoft.SharePoint.SPSite($siteurl)
for($i=0; $i -lt $spSite.AllWebs.Count;$i++)
{
$spWeb = $spSite.AllWebs[$i]
for($j=0; $j -lt $spWeb.Lists.Count;$j++)
{
$aList = $spWeb.Lists[$j]
if( $aList.Title -ceq "dokumenter") # case sensitive
{
if( $aList.EnableVersioning -eq $false)
{
$aList.EnableVersioning = $true
$aList.MajorVersionLimit = 5;
$aList.Update()
}
}
}
Such as:
Sealed Methods you might have liked to extend
Exceptions thrown are more vague than is helpful
Elimination of Connected Content which was a major feature in MCMS 2002
HTML is stripped from fields when stored and returned. No easy option to work around this problem
Creating an SPWeb takes an eternity.
Nonexistant migration path from MCMC 2002
I wish that the Sharepoint object model was purely managed code. Although having .NET wrappers is convenient, having to worry about disposing the many objects that implement IDisposable is a pain. It's so easy to run into memory issues when dispose does not get called in a WSS app. And I thought the reason for moving to .NET was to free developers from having to deal with memory management...
How about refactoring Properties that result in additional database calls to methods instead, for example the Items property on SPList.
Any of the SPList API could use a complete rewrite. Trying to deal with libraries with nested folders is a complete nightmare with the list being completely flattened with no obvious hierarchical structure.
Another wonderful addition would be adding interfaces to SPWeb, SPList and other Sharepoint classes to aid testing.
Has anyone seen this method:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx This method shows the unbelievable nonsense that Sharepoint exposes to developers.
My personal favourite is the SPField.GetFieldValue Method. I have no idea why they designed it the way they did, but to me it does hardly make sense. To get a object out of a ListItem you have to do somethine like:
SPField field = ((SPList)list).Fields.GetField("FieldName");
object fieldValue = field.GetFieldValue(((SPListItem)item)[field.Title].ToString());
Getting an object out of a ListItem is IMO a basic operation, so this should not be that complicated.
Inconsistencies when passing field names to methods or arrays. For example:
SPFieldCollection.ContainsField(): Internal name or display name
SPFieldCollection.GetField(): Internal name or display name
SPFieldCollection.GetFieldByInternalName(): Internal name
SPFieldCollection.Item: Display name
SPListItem.Item: Internal name or display name
SPListItem.GetFormattedValue(): Internal name or display name
SPViewFieldCollection.Exists: Internal name
To put the icing on the cake, there is usually no documentation about whether a method takes internal and/or display name.