foreach ($grp in Get-SPFeature | Group-Object SolutionId) {
$sol = Get-SPSolution -Identity $grp.Name
Write-Host $sol.Name '(ID:' $grp.Name '), Count:' $grp.Count -ForegroundColor Blue
foreach ($fd in $grp.Group | sort DisplayName ) {
Write-Host $fd.DisplayName '(' $fd.Scope ')'
}
Write-Host
}
Pages
▼
29 Aug 2013
6 Aug 2013
System.Diagnostics.Debugger.Break() for debugging Features
In certain cases, there is no easy way to debug FeatureActivating or FeatureDeactivating methods either because there is no UI process to attach to or you are deploying the project from Visual Studio. For example, If you set a breakpoint inside the asynchronous FeatureActivating method - it will not hit during execution unless you are somehow attached to the correct process.
So, for debugging purposes, you can include System.Diagnostics.Debugger.Break(); inside the FeatureActivating method:
public override void FeatureActivating(SPFeatureReceiverProperties properties)
{
System.Diagnostics.Debugger.Break();
// Feature code...
}
At the time System.Diagnostics.Debugger.Break() is executed you System will show you a dialog box with an exception, prompting you to select a desired way to debug "a problem". It's not a problem of course :) Then you have to select your Visual Studio SharePoint project which should be already open. After a few moments you will be redirected to the System.Diagnostics.Debugger.Break(); and you will see that your lovely breakpoint actually worked fine. Now you can go on and continue debugging.
So, for debugging purposes, you can include System.Diagnostics.Debugger.Break(); inside the FeatureActivating method:
public override void FeatureActivating(SPFeatureReceiverProperties properties)
{
System.Diagnostics.Debugger.Break();
// Feature code...
}
At the time System.Diagnostics.Debugger.Break() is executed you System will show you a dialog box with an exception, prompting you to select a desired way to debug "a problem". It's not a problem of course :) Then you have to select your Visual Studio SharePoint project which should be already open. After a few moments you will be redirected to the System.Diagnostics.Debugger.Break(); and you will see that your lovely breakpoint actually worked fine. Now you can go on and continue debugging.
Feature Stapling changes for MySites in SharePoint 2013
In case of My Sites, Elements.xml for the feature stapler you have to change TemplateName="SPSPERS#0" to TemplateName="SPSPERS#2"
So, the resulting XML might look just like that:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<FeatureSiteTemplateAssociation Id="91a39059-e694-4c80-8341-e18db90c0c58"
TemplateName="SPSPERS#2"/>
</Elements>
So, the resulting XML might look just like that:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<FeatureSiteTemplateAssociation Id="91a39059-e694-4c80-8341-e18db90c0c58"
TemplateName="SPSPERS#2"/>
</Elements>
5 Aug 2013
ULS, SharePoint Foundation Monitoring High Leaving Monitored Scope (EnsureListItemsData). Execution Time=XXX
Ever wondered what this message meant in ULS?
First of all, there is a public SPMonitoredScope class that allows us to discover performance bottlenecks.
One of the implementations of this method looks like following:
public SPMonitoredScope(string name, uint maximumExecutionTime, params ISPScopedPerformanceMonitor[] monitors)
If maximumExecutionTime parameter is set to 250, a debug message will be written to ULS when a certain piece of code runs more than 250 milliseconds.
When SPList.GetItems method is executed you don't immediately get data from DataBase because this method is differed until the actual data is requested somewhere. So, when you try to debug performance bottlenecks you might find that this method executes pretty fast. However, when, later you try to request SPListItemCollection the internal EnsureListItemsData method is run. This exact method will ensure that the actual data is retrieved. This is where it might take quite some time to get your List items. Let's see at the internal implementation of the EnsureListItemsData method:
protected void EnsureListItemsData()
{
using (new SPMonitoredScope("EnsureListItemsData", 250, new ISPScopedPerformanceMonitor[] { new SPSqlQueryCounter(1) }))
{
// Code that fetches data from the Database
}
}
As you can see, maximumExecutionTime parameter is set to 250 milliseconds.When the process of getting List data from SPList gets longer that this time you will see this message:
ULS, SharePoint Foundation Monitoring High Leaving Monitored Scope (EnsureListItemsData). Execution Time=XXX
I hope it sheds some light on this mysterious ULS message.
First of all, there is a public SPMonitoredScope class that allows us to discover performance bottlenecks.
One of the implementations of this method looks like following:
public SPMonitoredScope(string name, uint maximumExecutionTime, params ISPScopedPerformanceMonitor[] monitors)
If maximumExecutionTime parameter is set to 250, a debug message will be written to ULS when a certain piece of code runs more than 250 milliseconds.
When SPList.GetItems method is executed you don't immediately get data from DataBase because this method is differed until the actual data is requested somewhere. So, when you try to debug performance bottlenecks you might find that this method executes pretty fast. However, when, later you try to request SPListItemCollection the internal EnsureListItemsData method is run. This exact method will ensure that the actual data is retrieved. This is where it might take quite some time to get your List items. Let's see at the internal implementation of the EnsureListItemsData method:
protected void EnsureListItemsData()
{
using (new SPMonitoredScope("EnsureListItemsData", 250, new ISPScopedPerformanceMonitor[] { new SPSqlQueryCounter(1) }))
{
// Code that fetches data from the Database
}
}
As you can see, maximumExecutionTime parameter is set to 250 milliseconds.When the process of getting List data from SPList gets longer that this time you will see this message:
ULS, SharePoint Foundation Monitoring High Leaving Monitored Scope (EnsureListItemsData). Execution Time=XXX
I hope it sheds some light on this mysterious ULS message.
2 Aug 2013
ManagedLink Attribute for Web Part Properties that Converts Absolute URLs to Relative Ones
[ManagedLink] above the web part property automatically converts full Urls to relative ones. very useful for fool proofing against incorrectly typed URL's.
For example, http://portal/Lists/CustomList/Forms/Display.asxp becomes l/Lists/CustomList/Forms/Display.asxp
C# example:
[WebBrowsable(true),
Category("Configuration"),
Personalizable(PersonalizationScope.Shared),
WebDisplayName("Friendly Display Name"),
WebDescription("Values: Whatever value you need")]
[ManagedLink]
public Uri URI { get; set; }
For example, http://portal/Lists/CustomList/Forms/Display.asxp becomes l/Lists/CustomList/Forms/Display.asxp
C# example:
[WebBrowsable(true),
Category("Configuration"),
Personalizable(PersonalizationScope.Shared),
WebDisplayName("Friendly Display Name"),
WebDescription("Values: Whatever value you need")]
[ManagedLink]
public Uri URI { get; set; }
Validate Web Part Properties using WebPartPageUserException
throw new WebPartPageUserException("OMG Something went wrong!");
Download and Install SharePoint 2013 Prerequisites on Windows Server 2012
These PowerShell scripts will automate downloading and installing the SharePoint 2013 Prerequisites on Windows Server 2012. The scripts will assist those who need to install SharePoint 2013 'offline' or wish to manually install its Prerequisites on Windows Server 2012.
Here is the link
Here is the link
Detect installed SharePoint 2010 or 2013 products using PowerShell
This PowerShell function returns a hash table to the pipeline containing SharePoint 2010 or 2013 products and the SharePoint Build Version installed on your server.
Here is the link.
Here is the link.