Using the SharePoint API, how can I modify an extended webapp web.config file?
I have to do some changes in this file to specify the connection string, membershipprovider, etc... for using Forms Authentication.
Currently, I can change the "master" webapplication web.config file, but not the extended one.
Edited
I'm using Sp 2007. I'm already using SPWebConfigModification class to modify the parent webapp. Thoses modifications are propagated to the extended webapp. I have to change ONLY the extended one. But I don't find the way to do it.
What I'm trying to achieve, is to program a little wizard that:
Shows a WebApp list so the user can select one
Extend that selected webapp to a different zone
Configure that extended zone to use Forms Authentication
Thanks
I got an answer form a blog.
In your case , you need to write a Web Application scoped feature which after you provision your site using your C# app, it is deployed to the newly-provisioned site and in the receiver of the feature you inject the required web.config settings because in that context configuration API is obtainable , but again bear the following in mind:
If you don’t use SPWebConfigModification class and either use ASP.NET 2.0 configuration API or your own mechanism , propagating changes across the farm is YOUR RESPONSIBILITY. If this happens on an standalone installation then you don;t need to be worried about this.
So it cannot be done externally. We have to do a feature in order to acheve this.
Thanks
Quick answer: look into the SPWebConfigModification class. I am assuming you're using SharePoint 2007. The best way to learn about this is to dig into open source projects:
Google code search: http://www.google.com/codesearch?q=spwebconfigmodification&hl=en&btnG=Search+Code
This project on CodePlex looks like it's one big SPWebConfigModification: http://www.codeplex.com/ajaxifymoss/Release/ProjectReleases.aspx?ReleaseId=13360
Related
I have been using Liferay for work for 2 weeks. I noticed that it's a bit difficult to find good documentation and tutorials.
Until now I created pages from the web portal. After I create them, I drag and drop portlets. I don't really like this approach, I would prefer to use a coding approach. Is there a way to create a website or page programmatically by defining a project as I do to create portlets?
Moreover, I am using Liferay with WebLogic 10.3.6. I want to know where liferay puts pages I created via web-portal on the file system. I suppose that a file, or something similar, is created when I declare a new site on the Liferay web-portal.
Thank you all,
Marco
Yes Liferay has it's Database, all data of any Liferay object is stored in the database and / or on the file system depending on your configuration.
However, one of the functionality of Liferay is to let you create pages / sites through the UI. As documented in the Java Portal Specification and Liferay Server Documents your approach to create pages in an alternative way is possible but it is part of Liferay's Portal Services. You can use Liferay's Service (HTTP REST) API to call the related service. To access those APIs you need to configure your Liferay Server.
In case you want to do programmatically you still need to configure, enable and call those external HTTP services from your code. You should not create Liferay Objects from your own code hosted as an extension inside your Liferay Instance as that will result inconsistency in your Liferay Database / filesystem. (As in case of page creation Liferay creates a set of other related objects in it's database / filesystem.)
In your liferay bundle you will find two plugins of interest.
First is resources-importer-web for which description says
The Resources Importer app allows front-end developers to package web
content, portlet configurations, and layouts together in a theme
without saving it as a compiled .LAR file thereby allowing for greater
flexibility in its usage between Liferay Portal versions.This app will automatically create associated content when other
plugins are deployed that are configured to make use of the Resource
Importer app.This app installs as a Liferay service.
Second is welcome-theme which declares resources to be created by resources-importer-web. This on should be example how to create your own. Take a look at
welcome-theme\WEB-INF\src\resources-importer\*
welcome-theme\WEB-INF\liferay-plugin-package.properties
This feature is described at importing-resources-with-themes
As mentioned by gabor_the_kid, Liferay stores all objects in its tables. For example, User related objects would be in user table. Liferay exposed services or API's to change the default/to add new behaviors by program but not easier than achieving it through UI. Also maintenance should be considered for going program way of creating pages or layouts etc.
You can describe your changes using xml and use the Liferay Portal DB Setup core to create the changes in DB.
The library defines the list of available xml configurations.
I am making a Sharepoint 2010 WebPart with functionality from another Main Web Application.
To develop the Webpart quickly I have imported the business logic assemblies used in the Main Web Application. The Webpart works and pulls application specific configuration information from the Sharepoint web.config file.
Is this the best place to store this information?
If not..
Where/How should the application specific configuration data be stored in Sharepoint?
The config data contains items like locations of web services etc. The data will only need to be edited by system administrators.
Thanks
Web.Config is, IMHO, a terrible place to store this sort of config information - its hard to deploy and hard to change, especially if you're using multiple web front ends.
The recommended way to do this is to use PropertyBag (key/value pairs) through the .Properties of SPFarm, SPWeb.RootWeb (for site collections), SPWeb, SPList etc (depending upon the scope that you need).
MSDN - Managing Custom Configuration Options for a SharePoint Application
There is a production ready code available as part of the
MSDN - The SharePoint Guidance Library
See Hierarchical configuration manager
This gives you programmatic access to read/write these values. If you want to do this without using the guidance library then you would use something like the following code.
SPWeb web = SPContext.Current.Web;
if (web.Properties.ContainsKey("MyProperty"))
string myProperty = web.Properties["MyProperty"];
If you want a UI to allow admins to easily set the values then use something like SharePoint Property Bag Settings
The easiest way to do it is to create sharepoint list visible only to administrator. It can have 3 columns description, title, value. It will store all config values. Also you can add a link to this list to site settings page.
The web config is always a good place. However if you want to change that data you will have to enforce some sort of site recompile which is a pain for end users.
Theres a nice little app/solution on codeplex to do with the property bag value
http://pbs.codeplex.com/
This is a brilliant little app/solution that ties in with your central administration.
It should be inbuilt i think.
Hope this helps.
I want to change the trust level of a Sharepoint Web Application without having to change the web.config manually (i.e. WSS_Minimum, WSS_Custom, etc). Making manual changes to the web.config tag is highly undesirable in anything other than a one-server farm. Is there any way via stsadm or Central Admin to change this?
Third party tools or a Powershell script would be acceptable in that they would make clear that there's no native way to accomplish this.
Thanks in advance
See my answer here. There's an object model call to propagate web config modifications to every server in a farm as well as a freely available Central Admin plugin that wraps the OM in an easier to use interface.
There is a class designed for this called SPWebConfigModification that will propagate your changes to all member servers of the farm.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx
-Oisin
SPWebConfigModifications are a pain.. but this stsadm extension will make it a lot easier.
Create a CAS policy?
I am developing publishing site and it will have complex tree structure.
Is there any way to deploy site structure (multiple sub sites - SPWeb) using SharePoint solution?
I know I can create site tree programmatically.
I have been on a project with the same needs, but we didn't find the answer with the OOTB functionality of the feature framework. We also had to go through the object model and do the creation programmatically.
But instead of hard-coding the site structure, we took a different approach. Our solution was to implement a generic SiteCreation feature that takes an xml file as input. The xml defines the site structure and is read by the feature receiver which parses it and creates the specified sites.
I know that there is some coding involved in this solution, but I think the extra work is well spent, since the site structure will likely change numerous times before it reaches production.
The default publishing portal (and collaboration portal) site definitions use a portal provisioning class to build the site structure based on an xml file (this is all out of the box for a MOSS installation).
You can see how the provisioning class is referenced in the webtemp file for the portal site definitions (12\TEMPLATE\1033\XML\webtempsps.xml). An example of the actual xml documents that are used can be found in 12\TEMPLATES\SiteTemplates\WebManifest - it's a fairly straight forward schema.
If you are creating a custom site definition based on publishing portal then you can re-use the provisioning class and provide your own xml document to build your custom site structure.
We have a SharePoint farm with multiple WFEs. A new application requires us to write some custom code to the web.config during deployment. What is the best way modify the the web.config file during deployment, ensuring that each WFE in the farm get updated?
I'm assuming you'll be deploying your code via a WSP; if not, using a tool like WSPBuilder is a great starting place that allows you to get rolling without forcing you to learn all of the intricate details of solution package construction.
You should leverage the SPWebConfigModification type from within a custom SPFeatureReceiver. Normally, the FeatureActivated method of the SPFeatureReceiver would be coded to write the changes out to the web.config files impacted by your activation. Those same changes would then be retracted in the FeatureDeactivating method.
The nice thing about the SPWebConfigModification type is that SharePoint takes care of determining which web.config files should be modified -- across servers and across extended web apps.
I hope this helps!
As part of your deployment, use the SPWebConfigModification class to add/remove entries from web.config. SharePoint will manage updating the WFEs for you if you use this.
A blog post entitled, Modify the web.config file in SharePoint using SPWebConfigModification, is a great summation of the gotchas involved and contains links to other helpful resources.