SharePoint Deployment
-
Hi, Is it possible to create the following thins using sharepoint features: 1) Create sub site 2) Create Web part pages 3) Deploy the web parts 4) Add web part pages in the corresponding pages 5) Create list. I am thinking to create one solution for above items for deployment purpose. Can someone please guide me that how I can proceed? regards, Vishal
-
Hi, Is it possible to create the following thins using sharepoint features: 1) Create sub site 2) Create Web part pages 3) Deploy the web parts 4) Add web part pages in the corresponding pages 5) Create list. I am thinking to create one solution for above items for deployment purpose. Can someone please guide me that how I can proceed? regards, Vishal
Of course it is. How do you think team sites, or other templates, are provisioned? What part of the five items do you need help with? You have to narrow your question before we can help.
Failure is not an option; it's the default selection.
-
Hi, Is it possible to create the following thins using sharepoint features: 1) Create sub site 2) Create Web part pages 3) Deploy the web parts 4) Add web part pages in the corresponding pages 5) Create list. I am thinking to create one solution for above items for deployment purpose. Can someone please guide me that how I can proceed? regards, Vishal
Hello Vishal, You can almost do anything you want in the FeatureActivated event, same as you would using PowerShell or Central Admin. First you have to determine your feature's scope. This will determine your Feature's parent in the event handle whether it would be of type SPWeb[^] or SPSite[^]. Then you'll use the methods in these classes to do whatever you want to. Now for your list: 1) Create sub site => Here is a nice article[^] 2) Create Web part pages => Perhaps you mean this?[^] 3) Deploy the web parts => You can add this directly to your feature, which by the way can be visual and non-visual 4) Add web part pages in the corresponding pages => Here is a sample article[^] 5) Create list. => You can add this directly to your feature
Regards:rose: --- How to edit any .NET program without having the source code Visit my blog Follow me on twitter
-
Hi, Is it possible to create the following thins using sharepoint features: 1) Create sub site 2) Create Web part pages 3) Deploy the web parts 4) Add web part pages in the corresponding pages 5) Create list. I am thinking to create one solution for above items for deployment purpose. Can someone please guide me that how I can proceed? regards, Vishal
If it is a one time deal I would suggest using powershell. Most of time I actually build out the steps within a feature because you have intellisense and it is just easier. Then when I am sure that the feature is working, I convert it into a Powershell script.
Chris
-
If it is a one time deal I would suggest using powershell. Most of time I actually build out the steps within a feature because you have intellisense and it is just easier. Then when I am sure that the feature is working, I convert it into a Powershell script.
Chris
So you go to all of the effort to create the feature, which can then be deployed via a wsp. Then through it all away and start over just to do it in PowerShell. How horribly inefficient. X| You can deploy and activate the wsp just as easily with PowerShell without having to recreate everything.
Failure is not an option; it's the default selection.
-
So you go to all of the effort to create the feature, which can then be deployed via a wsp. Then through it all away and start over just to do it in PowerShell. How horribly inefficient. X| You can deploy and activate the wsp just as easily with PowerShell without having to recreate everything.
Failure is not an option; it's the default selection.
That is true. But there are limitations to features. 1. You cannot configure a feature. You can only simply turn it on and off. Problem: Well what if you wanted the administrator who deploys the solution and wants change the name of the "sub site" or what if you wanted the administrator to dynamically add and remove the number of "sub sites" that should be created on deployment. You cannot do that with a feature. Sometimes all information is not known when creating functionality. 2. You have maintenance issues. Say a web feature (say FeatureA) that when you turn it on creates a list (say ListA). Sounds great. You even make it so that list can only appear on the root of the site collection. O Ya Problem: That feature is still present in ALL web sites within the farm/web application that you deployed it to. This means that any web administrator (they do not have to be a site collection administrator) can activate that feature on other site collections. Well, you say "so what. Thats not a problem". Well you then leave the company and the company is rearranging their portal. They decide to get rid of ListA because its no longer needed. So they deactivate the feature on the root site collection and remove the solution. O, but wait, what about the feature that some web administrator was playing around with in a different site collection. Now that list may not have a list definition. You are now getting calls from random web administrators say they can no longer get to "View All Site Content". The list definition that was removed was actually being used. Thats just great!!! 3. Feature Nightmare? Say you create 100's of these features over the years that simply create lists. These features are now all within all your site collection features and web site features when they do not need to be. WHY IN THE WORLD IS THERE A FEATURE FOR CREATING A LIST, WHEN IT IS JUST A ONE TIME DEAL WITH POWERSHELL!!!!For example, I am seeing features to create a "Toyota List 1", "Toyota List 2", "Toyota List 3" in my "GMC" site collection. Well what if you had a toyota site collection, GMC site collection, Ford site collection, and 40 other site collection. What a nightmare this could be for maintaining features which could confuse site collection administrators. I would say carefully analyize you business requirements and make a proper decision as to whether or not powershell should be used or a feature should be used. Features are easier but could have drawbacks. I said create the initial solution as
-
That is true. But there are limitations to features. 1. You cannot configure a feature. You can only simply turn it on and off. Problem: Well what if you wanted the administrator who deploys the solution and wants change the name of the "sub site" or what if you wanted the administrator to dynamically add and remove the number of "sub sites" that should be created on deployment. You cannot do that with a feature. Sometimes all information is not known when creating functionality. 2. You have maintenance issues. Say a web feature (say FeatureA) that when you turn it on creates a list (say ListA). Sounds great. You even make it so that list can only appear on the root of the site collection. O Ya Problem: That feature is still present in ALL web sites within the farm/web application that you deployed it to. This means that any web administrator (they do not have to be a site collection administrator) can activate that feature on other site collections. Well, you say "so what. Thats not a problem". Well you then leave the company and the company is rearranging their portal. They decide to get rid of ListA because its no longer needed. So they deactivate the feature on the root site collection and remove the solution. O, but wait, what about the feature that some web administrator was playing around with in a different site collection. Now that list may not have a list definition. You are now getting calls from random web administrators say they can no longer get to "View All Site Content". The list definition that was removed was actually being used. Thats just great!!! 3. Feature Nightmare? Say you create 100's of these features over the years that simply create lists. These features are now all within all your site collection features and web site features when they do not need to be. WHY IN THE WORLD IS THERE A FEATURE FOR CREATING A LIST, WHEN IT IS JUST A ONE TIME DEAL WITH POWERSHELL!!!!For example, I am seeing features to create a "Toyota List 1", "Toyota List 2", "Toyota List 3" in my "GMC" site collection. Well what if you had a toyota site collection, GMC site collection, Ford site collection, and 40 other site collection. What a nightmare this could be for maintaining features which could confuse site collection administrators. I would say carefully analyize you business requirements and make a proper decision as to whether or not powershell should be used or a feature should be used. Features are easier but could have drawbacks. I said create the initial solution as
You can use properties in a feature that can be set via PowerShell. The other scenarios are, IMO, contrived. What you describe are "what if" cases you are using to justify your process and can be controlled and mitigated with proper governance policies and coding of features, such as handle issues in the DeactivateFeature event. One off lists are created via the SharePoint UI or SPD. Features are used for reusable solutions. Features that should not be activated by site admins can be hidden and activated via PowerShell. There is no valid reason to code the feature in VS then recreate it in PowerShell. If you have 100s of features being deployed and activated by Site Admins, just because they see them available, then you have bigger problems that need solved.
Failure is not an option; it's the default selection.
-
You can use properties in a feature that can be set via PowerShell. The other scenarios are, IMO, contrived. What you describe are "what if" cases you are using to justify your process and can be controlled and mitigated with proper governance policies and coding of features, such as handle issues in the DeactivateFeature event. One off lists are created via the SharePoint UI or SPD. Features are used for reusable solutions. Features that should not be activated by site admins can be hidden and activated via PowerShell. There is no valid reason to code the feature in VS then recreate it in PowerShell. If you have 100s of features being deployed and activated by Site Admins, just because they see them available, then you have bigger problems that need solved.
Failure is not an option; it's the default selection.
I didn't know you could set properties on a feature via powershell. That is pretty cool. I think we are going to just have to agree to disagree with the coding it within VS then recreate it in PowerShell. If you are experience with PowerShell, then yes, simply create it only in PowerShell. However, if you are new to PowerShell and dont know the syntax, then do it in VS first, then convert it to PowerShell. An inexperience PowerShell developer could easily learn how to convert simple C# syntax into PowerShell. In my experience, when I was trying to configure search for a SharePoint environment, I wanted to use PowerShell. I started off doing it in PowerShell and I could not figure out how to initially code it without any intellisense. Yes PowerGui does offer some intellisense but not for the deep search configurations. Therefore, I created it in VS first. It was even difficult to do within VS. I finally got it to work inside VS and then moved it to a Powershell script.
Chris