How to cancel inprogress workflow?
SPWorkflowCollection itemWorkflowCollection= listItem.Workflows;
foreach (SPWorkflow itemWorkflow in itemWorkflowCollection)
{
//cycle workflows associated to the item (listItem)
if (!itemWorkflow.IsCompleted && itemWorkflow.InternalState == SPWorkflowState.Running)
{
foreach (SPWorkflowTask taskWorkflow in itemWorkflow.Tasks)
{
//cycle throught all tasks associated to the workflow
//if task is not completed
if (taskWorkflow["PercentComplete"].ToString() != "1")
{
//you can cancel or change the running tasks before canceling the workflow
taskWorkflow["Status"] = "Canceled";
taskWorkflow["PercentComplete"] = 1;
web.AllowUnsafeUpdates = true;
taskWorkflow.Update();
}
}
SPWorkflowManager.CancelWorkflow(itemWorkflow);
}
}
Enjoi...
Friday, March 2, 2012
Monday, February 20, 2012
Query to get Lock Site Collection in SHarepoint 2007.
Query to get Lock Site Collection in SHarepoint 2007.
BitFlags-131072 For Read Only Site COllection
BitFlags-1 Adding Content Prevented
BitFlags-0 for None
BitFlags-3 for No Access
SELECT dbo.Webs.SiteID as SiteID,dbo.Webs.Id AS WebGuid,
dbo.Webs.Title AS WebTitle,
dbo.Webs.FullUrl AS WebUrl
FROM dbo.Webs INNER JOIN
dbo.Sites ON dbo.Webs.SiteId = dbo.Sites.Id AND dbo.Sites.BitFlags = 131072
AND dbo.Webs.ParentWebId is null
BitFlags-131072 For Read Only Site COllection
BitFlags-1 Adding Content Prevented
BitFlags-0 for None
BitFlags-3 for No Access
SELECT dbo.Webs.SiteID as SiteID,dbo.Webs.Id AS WebGuid,
dbo.Webs.Title AS WebTitle,
dbo.Webs.FullUrl AS WebUrl
FROM dbo.Webs INNER JOIN
dbo.Sites ON dbo.Webs.SiteId = dbo.Sites.Id AND dbo.Sites.BitFlags = 131072
AND dbo.Webs.ParentWebId is null
Wednesday, February 15, 2012
Tuesday, February 7, 2012
http://wcftutorial.net/Difference-between-WCF-and-Webservice.aspx
End Point
Bindings and Behavior
Contracts and Service host
Message and Channel
WCF client and Metadata
http://www.dotnetcurry.com/ShowArticle.aspx?ID=766
http://learn2expert.net/DotNetInterview/COM/COM.aspx
End Point
Bindings and Behavior
Contracts and Service host
Message and Channel
WCF client and Metadata
http://www.dotnetcurry.com/ShowArticle.aspx?ID=766
http://learn2expert.net/DotNetInterview/COM/COM.aspx
New Folders in Sharepoint 2010 14 Hive:
New folders available in SharePoint Hive folder are,
Policy
UserCode
WebClients
WebServices
Policy
UserCode
WebClients
WebServices
Sharepoint 2010 Alerts
By default alerts can be send only through e-mail. But we can change that default setting by using the new DeliveryChannels Property of SPAlert class. This DeliveryChannels property, specifies the delivery method of the alert.
The following snippet used to set the SMS delivery method to the Alert.
oAlert.DeliveryChannels = SPAlertDeliveryChannels.Sms;
SPAlertDeliveryChannels is the enumerated member, which specifies the method of delivering alerts.
Email-Delivery as E-mail
Sms-Delivery as SMS Message
The following example code used to update the sms delivery method to all the alerts for every user available in Current website.
SPWeb oWebsite = SPContext.Current.Web;
SPUserCollection collUsers = oWebsite.Users;
foreach (SPUser oUser in collUsers)
{
SPAlertCollection collAlerts = oUser.Alerts;
foreach (SPAlert oAlert in collAlerts)
{
oAlert.DeliveryChannels = SPAlertDeliveryChannels.Sms;
oAlert.Update();
}
}
Enjoi...
The following snippet used to set the SMS delivery method to the Alert.
oAlert.DeliveryChannels = SPAlertDeliveryChannels.Sms;
SPAlertDeliveryChannels is the enumerated member, which specifies the method of delivering alerts.
Email-Delivery as E-mail
Sms-Delivery as SMS Message
The following example code used to update the sms delivery method to all the alerts for every user available in Current website.
SPWeb oWebsite = SPContext.Current.Web;
SPUserCollection collUsers = oWebsite.Users;
foreach (SPUser oUser in collUsers)
{
SPAlertCollection collAlerts = oUser.Alerts;
foreach (SPAlert oAlert in collAlerts)
{
oAlert.DeliveryChannels = SPAlertDeliveryChannels.Sms;
oAlert.Update();
}
}
Enjoi...
Tuesday, January 31, 2012
including additional assemblies in the WSP with Visual Studio SharePoint development tools
http://blog.mastykarz.nl/including-additional-assemblies-wsp-visual-studio-sharepoint-development-tools/
Thanks to above blog....on including a very good article on including additional assemblies in the WSP with Visual Studio SharePoint development tools
The new Visual Studio SharePoint development tools simplify work for SharePoint developers. Out-of-the-box the tools have some great functionality and knowing about these gems allows you to fully benefit of the power of the new tools. One of such gems can be used to make the process of provisioning multiple assemblies with a simple SharePoint Solution (WSP) easier.
How many times did you have to manually write the contents of the Manifest.xml file? Whenever you wanted to deploy an assembly with a WSP package, you had to figure out its fully qualified (4-part) name and include it in the Manifest.xml file. At some point the process got simplified thanks to tools like WSPBuilder but before that, you had to do everything manually.
The whole development story of SharePoint solutions has changed with the new Visual Studio SharePoint development tools. Using the new tools you can deploy additional assemblies with just a few mouse clicks.
Taking you there…
Let’s assume that you have the following projects: MySharePointProject which contains some SharePoint artifacts and MySharePointProject.Controls which is an ordinary Class Library that contains only the code of some controls.
Using the MySharePointProject you would like to package the Controls project including the SafeControls entries.
What you need to do is to double click on the Package project item: the Package Designer will open.
In the Package Designer you click the Advanced button. In the Advanced view you click the Add button and choose the Add Assembly from Project Output… menu option.
From the Source Project dropdown list you choose MySharePointProject.Controls project.
Then in the Safe Controls section, you click the Click here to add a new item button to add a new Safe Controls entry. And here’s where the magic happens.
…almost all the way.
In the Namespace column you enter MySharePointProject.Control – the namespace where your controls are located. The Assembly Name column can be used to provide the name of your assembly (fully qualified if the assembly will be deployed to GAC).
If it’s not the first time that you’re reading about the Visual Studio SharePoint development tools, the odds are high that you have heard about the Replaceable Parameters: tokens that are being replaced with something else during the build process. The list of out-of-the-box available tokens is really impressive, but in this scenario, one of them takes the attention in particular. Using the $SharePoint.Project.AssemblyFullName$ token you can specify that you want to include the fully qualified name of your assembly. During the build process, the Visual Studio SharePoint development tools will find this token and replace it with the actual fully qualified name of the assembly. There is however one challenge when dealing with additional assemblies.
The way the Visual Studio SharePoint development tools work at the moment is, that they use the context information from the project being built and use it to provide the replace value for the Replaceable Parameters. While it works in the most scenarios it gives you not the desired results here. If you use the $SharePoint.Project.AssemblyFullName$ token as the value for the Assembly Name column in a Safe Control entry, the generated Manifest.xml will contain the fully qualified name of the MySharePointProject assembly instead of the MySharePointProject.Controls assembly that we used in the reference. Does this mean that we cannot make use of the tokens and go back in time to the 2007 era when we had to do things manually? Not quite…
In my previous article I wrote about extending the packaging process of the Visual Studio SharePoint development tools. This is one of the scenarios when being able to extend the packaging process saves you a lot of time and keeps you productive! By using a custom Replaceable Parameter you can use a token in the Safe Control Assembly Name column and replace it with the actual fully qualified name of the referenced assembly just before the Manifest.xml file will be packaged.
Extensibility to the rescue: Introducing Imtech.VisualStudio.SharePoint.Tasks
To get the job done we need a couple of things. First of all we need a custom MSBuild task that will translate our custom Replaceable Parameter with the name of the referenced assembly. This is being done by the Imtech.VisualStudio.SharePoint.Tasks assembly. The assembly contains a custom MSBuild task that reads the contents of Manifest.xml, retrieves all Assembly elements, and replaces the $Imtech.SharePoint.AssemblyFullName$ tokens with the full name of the assembly referenced in the Assembly tag.
The next thing that we need to do, is to create a custom targets file. This does two things. It registers our custom task responsible for replacing the tokens and hooks it up with the packaging process of the Visual Studio SharePoint development tools. The targets file should contain the following contents:
?123456
We override the AfterLayout target what allows us to easily open the assemblies referenced in Manifest.xml. Additionally we are sure that our tokens are being translated before the Manifest.xml gets packaged in the WSP.
The next step is to hook up the custom targets file with the project file so that it will be used by the build process. You can do this by adding an Import element right under the one that contains a reference to Microsoft.VisualStudio.SharePoint.targets.
The last thing to do is to go to the Safe Controls dialog, add a new Safe Controls entry and use the $Imtech.SharePoint.AssemblyFullName$ token in the Assembly Name column.
If you’ve done everything right and choose Package, you should see the $Imtech.SharePoint.AssemblyFullName$ token properly replaced with the fully qualified name of the MySharePointProject.Controls assembly. You can see the Manifest.xml file used in the WSP package in the pkg\Debug\MySharePointProject directory under the MySharePointProject project.
Summary
Visual Studio SharePoint development tools provide you out-of-the-box not only with a great set of tools, that help you do your job as a SharePoint developer easier and faster, but also a very powerful extensibility framework that allows you to tailor the tools to fit your specific needs.
Thanks to above blog....on including a very good article on including additional assemblies in the WSP with Visual Studio SharePoint development tools
The new Visual Studio SharePoint development tools simplify work for SharePoint developers. Out-of-the-box the tools have some great functionality and knowing about these gems allows you to fully benefit of the power of the new tools. One of such gems can be used to make the process of provisioning multiple assemblies with a simple SharePoint Solution (WSP) easier.
How many times did you have to manually write the contents of the Manifest.xml file? Whenever you wanted to deploy an assembly with a WSP package, you had to figure out its fully qualified (4-part) name and include it in the Manifest.xml file. At some point the process got simplified thanks to tools like WSPBuilder but before that, you had to do everything manually.
The whole development story of SharePoint solutions has changed with the new Visual Studio SharePoint development tools. Using the new tools you can deploy additional assemblies with just a few mouse clicks.
Taking you there…
Let’s assume that you have the following projects: MySharePointProject which contains some SharePoint artifacts and MySharePointProject.Controls which is an ordinary Class Library that contains only the code of some controls.
Using the MySharePointProject you would like to package the Controls project including the SafeControls entries.
What you need to do is to double click on the Package project item: the Package Designer will open.
In the Package Designer you click the Advanced button. In the Advanced view you click the Add button and choose the Add Assembly from Project Output… menu option.
From the Source Project dropdown list you choose MySharePointProject.Controls project.
Then in the Safe Controls section, you click the Click here to add a new item button to add a new Safe Controls entry. And here’s where the magic happens.
…almost all the way.
In the Namespace column you enter MySharePointProject.Control – the namespace where your controls are located. The Assembly Name column can be used to provide the name of your assembly (fully qualified if the assembly will be deployed to GAC).
If it’s not the first time that you’re reading about the Visual Studio SharePoint development tools, the odds are high that you have heard about the Replaceable Parameters: tokens that are being replaced with something else during the build process. The list of out-of-the-box available tokens is really impressive, but in this scenario, one of them takes the attention in particular. Using the $SharePoint.Project.AssemblyFullName$ token you can specify that you want to include the fully qualified name of your assembly. During the build process, the Visual Studio SharePoint development tools will find this token and replace it with the actual fully qualified name of the assembly. There is however one challenge when dealing with additional assemblies.
The way the Visual Studio SharePoint development tools work at the moment is, that they use the context information from the project being built and use it to provide the replace value for the Replaceable Parameters. While it works in the most scenarios it gives you not the desired results here. If you use the $SharePoint.Project.AssemblyFullName$ token as the value for the Assembly Name column in a Safe Control entry, the generated Manifest.xml will contain the fully qualified name of the MySharePointProject assembly instead of the MySharePointProject.Controls assembly that we used in the reference. Does this mean that we cannot make use of the tokens and go back in time to the 2007 era when we had to do things manually? Not quite…
In my previous article I wrote about extending the packaging process of the Visual Studio SharePoint development tools. This is one of the scenarios when being able to extend the packaging process saves you a lot of time and keeps you productive! By using a custom Replaceable Parameter you can use a token in the Safe Control Assembly Name column and replace it with the actual fully qualified name of the referenced assembly just before the Manifest.xml file will be packaged.
Extensibility to the rescue: Introducing Imtech.VisualStudio.SharePoint.Tasks
To get the job done we need a couple of things. First of all we need a custom MSBuild task that will translate our custom Replaceable Parameter with the name of the referenced assembly. This is being done by the Imtech.VisualStudio.SharePoint.Tasks assembly. The assembly contains a custom MSBuild task that reads the contents of Manifest.xml, retrieves all Assembly elements, and replaces the $Imtech.SharePoint.AssemblyFullName$ tokens with the full name of the assembly referenced in the Assembly tag.
The next thing that we need to do, is to create a custom targets file. This does two things. It registers our custom task responsible for replacing the tokens and hooks it up with the packaging process of the Visual Studio SharePoint development tools. The targets file should contain the following contents:
?123456
We override the AfterLayout target what allows us to easily open the assemblies referenced in Manifest.xml. Additionally we are sure that our tokens are being translated before the Manifest.xml gets packaged in the WSP.
The next step is to hook up the custom targets file with the project file so that it will be used by the build process. You can do this by adding an Import element right under the one that contains a reference to Microsoft.VisualStudio.SharePoint.targets.
The last thing to do is to go to the Safe Controls dialog, add a new Safe Controls entry and use the $Imtech.SharePoint.AssemblyFullName$ token in the Assembly Name column.
If you’ve done everything right and choose Package, you should see the $Imtech.SharePoint.AssemblyFullName$ token properly replaced with the fully qualified name of the MySharePointProject.Controls assembly. You can see the Manifest.xml file used in the WSP package in the pkg\Debug\MySharePointProject directory under the MySharePointProject project.
Summary
Visual Studio SharePoint development tools provide you out-of-the-box not only with a great set of tools, that help you do your job as a SharePoint developer easier and faster, but also a very powerful extensibility framework that allows you to tailor the tools to fit your specific needs.
Subscribe to:
Posts (Atom)