Using PowerShell we can do more program oriented things like retrieving lists in the site, retrieving sub web details etc., where as we cannot do these things with STSADM command. We can do all things with PowerShell what we can do with STSADM command.
Showing posts with label Differences. Show all posts
Showing posts with label Differences. Show all posts
Tuesday, May 14, 2013
STSADM vs PowerShell
Using PowerShell we can do more program oriented things like retrieving lists in the site, retrieving sub web details etc., where as we cannot do these things with STSADM command. We can do all things with PowerShell what we can do with STSADM command.
Thursday, March 29, 2012
JavaScript Vs JQuery
According to my knowledge JavaScript only supports 32 bit Browsers. where as JQuery supports all browsers irrespective of 32 bit or 64 bit.
Tuesday, January 31, 2012
Asp.Net WebPart Vs SharePoint WebPart
As you might have guessed already, WSS 3.0 is implemented on top of ASP.NET 2.0. SharePoint Web Applications are nothing more than ASP.NET 2.0 sites with some modifications under the hood. In addition, the new SharePoint web part framework extends the ASP.NET 2.0 web part framework. That offers great flexibility since ASP.NET developers are now even closer to the SharePoint development platform. A large number of posts recommend the use of the ASP.NET WebPart class instead of the WSS WebPart class. Some of them actually suggest that the web part framework in WSS is there just for backwards-compatibility and should be avoided. In my personal opinion, I support the use of the WSS class for SharePoint web parts, and the use of the ASP.NET class for ASP.NET web parts. There is a fuzzy line though between them since the first inherits from the second. I am not totally against ASP.NET web parts in WSS but I believe they should be avoided as your web parts become more sophisticated.
Let us consider the scenario where you need to develop a web part that displays information from your backend system. Probably you will need the same web part in ASP.NET and WSS so I cannot see why the ASP.NET web part framework should not be used. There is no need for any services provided by SharePoint besides the hosting of the web part itself. Now you also have the need for resources such as images, style sheets and other supporting files. This is the point where trouble arises. SharePoint will deploy your web part resources in a special folder called "wpresources" under the root of the web application(s) you have your web parts deployed. This special folder holds all the resource files required by the web parts deployed to the web application. Each assembly gets a dedicated subfolder under the "wpresources" folder containing its own resource files. The name of that subfolder will correspond to the assembly name and in case the same assembly is deployed more than once (different versions in the GAC perhaps) the subfolder name might include version and public key. How will you "calculate" the path to your resources in ASP.NET? I can only wish you luck in that scenario but in the case of the WSS WebPart class, you have a very powerful method called ReplaceTokens. ReplaceTokens accepts one string parameter and returns almost the very same string with the difference that it processes some specific tokens within the parameter and replaces them with SharePoint specific values. For example:
ReplaceTokens("Hello, _LogonUser_") will replace "_LogonUser_" with the username of the current visitor.
Here is a list of other tokens:
That should make your life easier since it can return the resources folder for your web part. Let us move on to the scenario where you also need to create a document library at the site where your web part is loaded and in that document library, you need to save a daily report from your backend system. Thinks start to look grim again for the ASP.NET option since it cannot "talk" to SharePoint directly. You can reference Microsoft.SharePoint.dll or any other required assembly but that will be sacrificing the deploy-outside-SharePoint requirement. In this requirement is apparent that you need to separate your ASP.NET web parts from the WSS web parts.
Another good example to show that the WSS web part framework is not here just for your old web parts will be privilege elevation. You have a web part that does some background operations that require administrative access. You can’t give administrative rights to everyone, so what will you do? You can go down the same path as SharePoint developers used to go in WSS 2.0: impersonate another identity. That sounds great! Solution found! To implement it you will need to call unmanaged API and provide a username and password with credentials. Now I have seen many of this web parts and people have passed passwords through web part properties, in a file on the server or web.config itself. The next concern is exposure of the administrative credentials so you might want to encrypt them in a file and soon you realise you have added more components to your solution than you expected in the first place without even discussing any implications of calling unmanaged API. However, the WSS web part framework comes to the rescue; you can execute code with full rights using this simple code:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// your elevated code here
});
Again, that is as simple as "ABC" to implement and largely reduces the amount of code you need to write and test, not to mention that this is a more secure option with no credentials needed in the immediate code.
These are few of the benefits and weaknesses of the WSS web part framework over ASP.NET web part framework. Clearly, the WSS framework is not here for backwards compatibility only, but also to provide features specific to SharePoint and development around it.
Let us consider the scenario where you need to develop a web part that displays information from your backend system. Probably you will need the same web part in ASP.NET and WSS so I cannot see why the ASP.NET web part framework should not be used. There is no need for any services provided by SharePoint besides the hosting of the web part itself. Now you also have the need for resources such as images, style sheets and other supporting files. This is the point where trouble arises. SharePoint will deploy your web part resources in a special folder called "wpresources" under the root of the web application(s) you have your web parts deployed. This special folder holds all the resource files required by the web parts deployed to the web application. Each assembly gets a dedicated subfolder under the "wpresources" folder containing its own resource files. The name of that subfolder will correspond to the assembly name and in case the same assembly is deployed more than once (different versions in the GAC perhaps) the subfolder name might include version and public key. How will you "calculate" the path to your resources in ASP.NET? I can only wish you luck in that scenario but in the case of the WSS WebPart class, you have a very powerful method called ReplaceTokens. ReplaceTokens accepts one string parameter and returns almost the very same string with the difference that it processes some specific tokens within the parameter and replaces them with SharePoint specific values. For example:
ReplaceTokens("Hello, _LogonUser_") will replace "_LogonUser_" with the username of the current visitor.
Here is a list of other tokens:
| Token | Value |
| _WPR_ | Gets the base path to Web Part class resources |
| _WPQ_ | Gets a unique identifier for a Web Part |
| _LogonUser_ | Gets the Request.ServerVariables( "LOGON_USER" ) |
| _WPID_ | ID Property |
| _WebLocaleId_ | The LCID of the Web site |
| _WPSRR_ | Gets the server-relative path to Web Part class resources |
That should make your life easier since it can return the resources folder for your web part. Let us move on to the scenario where you also need to create a document library at the site where your web part is loaded and in that document library, you need to save a daily report from your backend system. Thinks start to look grim again for the ASP.NET option since it cannot "talk" to SharePoint directly. You can reference Microsoft.SharePoint.dll or any other required assembly but that will be sacrificing the deploy-outside-SharePoint requirement. In this requirement is apparent that you need to separate your ASP.NET web parts from the WSS web parts.
Another good example to show that the WSS web part framework is not here just for your old web parts will be privilege elevation. You have a web part that does some background operations that require administrative access. You can’t give administrative rights to everyone, so what will you do? You can go down the same path as SharePoint developers used to go in WSS 2.0: impersonate another identity. That sounds great! Solution found! To implement it you will need to call unmanaged API and provide a username and password with credentials. Now I have seen many of this web parts and people have passed passwords through web part properties, in a file on the server or web.config itself. The next concern is exposure of the administrative credentials so you might want to encrypt them in a file and soon you realise you have added more components to your solution than you expected in the first place without even discussing any implications of calling unmanaged API. However, the WSS web part framework comes to the rescue; you can execute code with full rights using this simple code:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// your elevated code here
});
Again, that is as simple as "ABC" to implement and largely reduces the amount of code you need to write and test, not to mention that this is a more secure option with no credentials needed in the immediate code.
These are few of the benefits and weaknesses of the WSS web part framework over ASP.NET web part framework. Clearly, the WSS framework is not here for backwards compatibility only, but also to provide features specific to SharePoint and development around it.
Monday, November 28, 2011
SSP Vs Service Applications
Differences between SSP and Service Application are :
What are :
SSP : A Web application that contain all the services proived by sharepoint, and can be shared by various web applications. Some of the services are Search, Infopath,User Profiles etc.
Service Application : The Services that use to be together in SSP, now run independently as a Service Application.
Build -In :
SSP : Shared Services Provider (SSP) was only a part of Office SharePoint Server 2007.
Service Applications : The service application architecture is however, built into Microsoft SharePoint Foundation 2010 itself.
SSP Administration Site :
SSP : They require a SSP administration site to configure the associations with web applications.
Service Application : They are running independently and can be individually associated with the one or more web applications.
Web application's Burden :
SSP : Any Web application associated with the SSP has to take the burden of all the shared services in that SSP.
Service Application : Each web application now have a "Service application group" where they can just add the Services that they need.
Replication :
SSP : The Services where configured in SSP itself and were not replicated. All web applications will use one set of srevices.
Service Application : If the service is needed to be shared between few web applications, the service is re-configured and added into each web application's custom service connection group.
What are :
SSP : A Web application that contain all the services proived by sharepoint, and can be shared by various web applications. Some of the services are Search, Infopath,User Profiles etc.
Service Application : The Services that use to be together in SSP, now run independently as a Service Application.
Build -In :
SSP : Shared Services Provider (SSP) was only a part of Office SharePoint Server 2007.
Service Applications : The service application architecture is however, built into Microsoft SharePoint Foundation 2010 itself.
SSP Administration Site :
SSP : They require a SSP administration site to configure the associations with web applications.
Service Application : They are running independently and can be individually associated with the one or more web applications.
Web application's Burden :
SSP : Any Web application associated with the SSP has to take the burden of all the shared services in that SSP.
Service Application : Each web application now have a "Service application group" where they can just add the Services that they need.
Replication :
SSP : The Services where configured in SSP itself and were not replicated. All web applications will use one set of srevices.
Service Application : If the service is needed to be shared between few web applications, the service is re-configured and added into each web application's custom service connection group.
BDC Vs BCS
What is Business Connectivity Services in SharePoint ?
SharePoint 2010 provides a new set of technologies known as Business Connectivity Services for retrieving, editing, updating, and deleting data from external systems(for e.g. data from ERP or CRM database). BCS enhances the SharePoint platform’s capabilities with out-of-box features, services and tools that streamline development of solutions with deep integration of external data and services.
How is BCS Different from BDC in SharePoint 2007 ?
Even though the BDC made it relatively easy to create read-only solutions that display data in the Business Data List Web Part, it was not so simple to create a solution that enabled users to make changes and write that data back to the external store.
BCS, on the other hand, provides you with Read-Write capable connectivity from Client and Server to Database, WCF/Web Services and .Net Sources.
A Developer can now use SharePoint Designer 2010 and VS 2010 rapid development tools to access external data. For e.g. you can now create read-write connections to external database from SharePoint designer and then can create webpart\other solutions to surface that data.
The BCS data can further be used in other SharePoint Fetaures such as Business Intelligence,Collaboration and in Enterprise Search.
SharePoint 2010 provides a new set of technologies known as Business Connectivity Services for retrieving, editing, updating, and deleting data from external systems(for e.g. data from ERP or CRM database). BCS enhances the SharePoint platform’s capabilities with out-of-box features, services and tools that streamline development of solutions with deep integration of external data and services.
How is BCS Different from BDC in SharePoint 2007 ?
Even though the BDC made it relatively easy to create read-only solutions that display data in the Business Data List Web Part, it was not so simple to create a solution that enabled users to make changes and write that data back to the external store.
BCS, on the other hand, provides you with Read-Write capable connectivity from Client and Server to Database, WCF/Web Services and .Net Sources.
A Developer can now use SharePoint Designer 2010 and VS 2010 rapid development tools to access external data. For e.g. you can now create read-write connections to external database from SharePoint designer and then can create webpart\other solutions to surface that data.
The BCS data can further be used in other SharePoint Fetaures such as Business Intelligence,Collaboration and in Enterprise Search.
SharePoint 2007 Lookup Column vs SharePoint 2010
Cascade Delete
SharePoint 2007 : The Lookup column in SharePoint 2007 does not support cascade delete. i.e. if If an Item\Value in the the look-up list is deleted, then all those items referencing that value (as look-up value) will not be delete. This will rather present you with various errors and can also cause errors on the Site page if your are using one of them as filters.
SharePoint 2010 : If an Item\Value in the the look-up list is deleted, then all those items referencing that value (as look-up value) in other lists will also be deleted.
Restrict Delete
SharePoint 2007 : Does not have option to restrict deleting of lookup list items\values.
SharePoint 2010 : Choosing this option would restrict the users from deleting an item in the column in the Look-up list, if the value is being used in some other lists.
Number of columns displayed
SharePoint 2007 : This will only display the chosen lookup column in the referencing list.
SharePoint 2010 : You can now display additional columns from the look-up list, along with the chosen lookup field.
SharePoint 2007 : The Lookup column in SharePoint 2007 does not support cascade delete. i.e. if If an Item\Value in the the look-up list is deleted, then all those items referencing that value (as look-up value) will not be delete. This will rather present you with various errors and can also cause errors on the Site page if your are using one of them as filters.
SharePoint 2010 : If an Item\Value in the the look-up list is deleted, then all those items referencing that value (as look-up value) in other lists will also be deleted.
Restrict Delete
SharePoint 2007 : Does not have option to restrict deleting of lookup list items\values.
SharePoint 2010 : Choosing this option would restrict the users from deleting an item in the column in the Look-up list, if the value is being used in some other lists.
Number of columns displayed
SharePoint 2007 : This will only display the chosen lookup column in the referencing list.
SharePoint 2010 : You can now display additional columns from the look-up list, along with the chosen lookup field.
SP 2007 Object Model Vs SP 2010
In Sharepoint Object model there are two Important namespaces.
In SharePoint 2007 - The Microsoft.Office.Server namespace is the root namespace of all Office Server objects and Microsoft.SharePoint is the root namespace for all WSS objects.
Hive :
In SharePoint 2007 - It has "12 hive" structure where all SharePoint resources are deployed.
In SharePoint 2010 - Microsoft has apparently added three new folders to its hive and calling it as "14 Hive"
* UserCode – files used to support sandboxed solutions
* WebClients – used for the client Object Model
* WebServices – New .svc files
Foundation :
SharePoint 2007 : Wss 3.0 was required for accessing all common SharePoint API's
SharePoint 2010 : SharePoint Foundation 2010 is required to provide base API's.
API's :
SharePoint 2007 : No API was available for Code to Interact with SharePoint site through Client side scripts (side Note : You can do it by calling Sharepoint web services using javascript )
SharePoint 2010 : MS has introduced Microsoft.SharePoint.Client namespace that enable you to interact with SharePoint sites through scripts that run in the browser from Microsoft .NET Framework managed code, and inside Microsoft Silverlight applications.
In SharePoint 2007 - The Microsoft.Office.Server namespace is the root namespace of all Office Server objects and Microsoft.SharePoint is the root namespace for all WSS objects.
Hive :
In SharePoint 2007 - It has "12 hive" structure where all SharePoint resources are deployed.
In SharePoint 2010 - Microsoft has apparently added three new folders to its hive and calling it as "14 Hive"
* UserCode – files used to support sandboxed solutions
* WebClients – used for the client Object Model
* WebServices – New .svc files
Foundation :
SharePoint 2007 : Wss 3.0 was required for accessing all common SharePoint API's
SharePoint 2010 : SharePoint Foundation 2010 is required to provide base API's.
API's :
SharePoint 2007 : No API was available for Code to Interact with SharePoint site through Client side scripts (side Note : You can do it by calling Sharepoint web services using javascript )
SharePoint 2010 : MS has introduced Microsoft.SharePoint.Client namespace that enable you to interact with SharePoint sites through scripts that run in the browser from Microsoft .NET Framework managed code, and inside Microsoft Silverlight applications.
SharePoint Foundation 2010 VS SharePoint Server 2010
SharePoint Foundation 2010 : Is is for smaller organizations or departments looking for a low-cost entry-level or pilot solution for secure, Web-based collaboration.
SharePoint Server 2010 : SharePoint Server 2010 builds on the Microsoft SharePoint Foundation 2010 infrastructure to provide a true enterprise portal platform.Any features that are available in SharePoint Foundation 2010 are also available in SharePoint Server 2010.
Features :
SharePoint Foundation 2010 : Coordinate schedules, organize documents, and participate in discussions through team workspaces, blogs, wikis, and document libraries on the platform that is the underlying infrastructure for SharePoint Server.
SharePoint Server 2010 : In addition to all the Features in SharePoint Foundation 2010, the server includes some additional features for every component available in Foundation 2010. Like Along with the BCS, sharePoint 2010 server also includes External data in search, Secure Store service,External Data Web Parts,Profile pages,External data in workflow,Rich client integration and lot more...
SharePoint Server 2010 : SharePoint Server 2010 builds on the Microsoft SharePoint Foundation 2010 infrastructure to provide a true enterprise portal platform.Any features that are available in SharePoint Foundation 2010 are also available in SharePoint Server 2010.
Features :
SharePoint Foundation 2010 : Coordinate schedules, organize documents, and participate in discussions through team workspaces, blogs, wikis, and document libraries on the platform that is the underlying infrastructure for SharePoint Server.
SharePoint Server 2010 : In addition to all the Features in SharePoint Foundation 2010, the server includes some additional features for every component available in Foundation 2010. Like Along with the BCS, sharePoint 2010 server also includes External data in search, Secure Store service,External Data Web Parts,Profile pages,External data in workflow,Rich client integration and lot more...
Stsadm Vs Windows PowerShell
Def :
Stsadm Tool : Microsoft Office SharePoint Server 2007 includes the Stsadm tool for command-line administration of Office SharePoint Server 2007 servers and sites.Stsadm is located at the following path on the drive where SharePoint Products and Technologies is installed: %COMMONPROGRAMFILES%\microsoft shared\web server extensions\12\bin. You must be an administrator on the local computer to use Stsadm.
Windows PowerShell : Windows PowerShell™ command-line interface is a new command-line tool and supporting scripting language from Microsoft that complements Cmd.exe in the Windows administration context. In the SharePoint administration context, Windows PowerShell supersedes the Stsadm.exe administration tool.
Return Parameter :
Windows PowerShell :Unlike most command-line tools, which accept and return text, Windows PowerShell is built on the Microsoft .NET Framework and accepts and returns .NET Framework objects.
Access to File System :
Stsadm : It does not allow you to access file system,registry ans so on..
Windows PowerShell :Like many shells, Windows PowerShell gives you access to the file system on the computer. In addition, Windows PowerShell providers enable you to access other data stores, such as the registry and the digital signature certificate stores etc..
Stsadm Tool : Microsoft Office SharePoint Server 2007 includes the Stsadm tool for command-line administration of Office SharePoint Server 2007 servers and sites.Stsadm is located at the following path on the drive where SharePoint Products and Technologies is installed: %COMMONPROGRAMFILES%\microsoft shared\web server extensions\12\bin. You must be an administrator on the local computer to use Stsadm.
Windows PowerShell : Windows PowerShell™ command-line interface is a new command-line tool and supporting scripting language from Microsoft that complements Cmd.exe in the Windows administration context. In the SharePoint administration context, Windows PowerShell supersedes the Stsadm.exe administration tool.
Return Parameter :
Windows PowerShell :Unlike most command-line tools, which accept and return text, Windows PowerShell is built on the Microsoft .NET Framework and accepts and returns .NET Framework objects.
Access to File System :
Stsadm : It does not allow you to access file system,registry ans so on..
Windows PowerShell :Like many shells, Windows PowerShell gives you access to the file system on the computer. In addition, Windows PowerShell providers enable you to access other data stores, such as the registry and the digital signature certificate stores etc..
Subscribe to:
Posts (Atom)