I have a piece of data, a simple string containing the server name that the SharePoint solution is deployed to, that I retrieve from a configuration store in a helper method in a common DLL used throughout my solution. This helper method is used throughout my custom pages and web parts, to build a number of URLs, etc.
I would like to persist this string, and prevent it being repeatedly retrieved from the configuration store. My Sharepoint installation is currently on a single server, but will be migrated to a SharePoint server farm in the near future, so simply determining the server name of the current request, etc isn't an option. I have looked at caching as described in the best practices for SharePoint, but unless I use a coherent cache like NCache or Velocity/AppFrabric, I will again have issues when the move to server farm occurs. Given that this is a single string, adding a full caching solution such as Velocity seems like overkill.
Does anyone have any suggestions on the best way to persist this data? Am I missing something obvious here?
Thanks, MagicAndi
Look into using the Property bag that is exposed by all major SharePoint objects to persist information. i.e.
SPFarm.Properties
SPWebApplication.Properties
SPSite.Properties
You could:
Store the string in web.config. You can programatically change the web.config on all the farm's webservers using a SPWebConfigModification
Store the string in a SharePoint list and read from it. I usually use this solution because I have more to store than a single string. The list is 'available' on all web servers and I cache its values in an ASP.NET cache object. Someone made this concept into a solution you can download and install: SPConfigStore
This article may be of use to those looking at storing configuration data in SharePoint:
Six ways to store settings in SharePoint
You can use SPPersisted to do such kind of operations.
Related
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 don't know about SharePoint that much, so hope that someone can give me some good explanations for me.
For SharePoint application, we don't need to consider SharePoint DB design? Everything is done through List and SharePoint will take care of the Database? Don't need to consider it at all unless we are connecting to the external Database?
For Parent Child relationship, I have to use lookup field?
If we are developing using Web parts, we need to deploy it using Features. So eventually, there can be so many features in the production? Is it recommended in this way?
1)
For SharePoint application, we don't need to consider SharePoint DB
design ? Everything is done through List and SharePoint will take care
of the Database ? Don't need to consider it at all unless we are
connecting to the external Database ?
You do need to consider the database... In term of administration. back ups, restore, size and so on.
however you never directly read or write to it. You don't need to pay attention to the schema because you won't ever be directly using it. If you want to update something in SharePoint you do it pragmatically with c# / vb.net using the SharePoint API's. You have 2 API's one that works on the server called the SharePoint object model and one that works on a remote machine called the client side object model.
From a users perspective, you are correct lists contain data in SharePoint and are somewhat smiler to DB tables in some ways.
2)
For Parent Child relationship, I have to use lookup field ?
Yip
3)
If we are developing using Web parts, we need to deploy it using
Features. So eventually, there can be so many features in the
production ? Is it recommended in this way?
This can happen if you create a new solution for every web part but you can bundle multiple web parts in the same solution in the same project in the same feature
Right click on your project --> add new item. select a web part. By default the web parts will all be part of the same feature but you can separate them out and have multiple features in the same solution if you want to
I am currently writing a Sharepoint Workflow that is activated when a user saves an Excel file to a Library. Now I need to process this file and store certain information to a certain list.
Whats the best way to store configuration settings like the name of the output list, names of the Excel columns that the Workflow needs to process, etc?
I understand that there seem to be a lot of different possible solutions like web config, Properties, etc. But since I am totally new to Sharepoint, I cannot properly assess these methods. Which one is the easiest for me to use?
Thank you.
Edit: A Visual Studio Workflow, written in C#
This article is a good starting point Six Ways to to store settings in SharePoint but personally I would be following the MSDN SharePoint Guidance Library which uses the Property Bag storage for their implementation of a hierarchical Configuration Manager which allows you to do things like a farm wide setting but overridden for certain site collections/sites/lists etc.
Or at least could anybody point me to docs about its crazy proprietary url parameters and html field name obfuscation? I can only suppose this is caused by SharePoint...
The main problem is, given a start page built with SharePoint, I can't recreate a form post with a programmative client because:
field names vary, they are appended with a some sort of id, hash, whatever (I think session.wise? Not sure)
tracing HTTP traffic on my side, I see the HTTP request is packed with strange parameters like __REQUESTDIGEST, __VIEWSTATE, and many others
Is this an intentional protection device put up by SharePoint? Which is the underlying architecture and which objects are involved (script callbacks, ... )?
(BTW, I'm not doing anything evil, just trying to extract public government data from a website).
Thanks.
SharePoint is nothing more than an ASP.NET Application, SharePoint completely Built on top of ASP.NET 2.0.
Being said that __VIEWSTATE is nothing but a Hidden Field that has the View State Information
Coming to __REQUESTDIGEST this is an Intentional Protection, this carries some sort of
securito validation which is called FormDigest
And finally to answer your Question, You will not be able to guess field and stuffs unless you have control to change the sourcecode of the application. Reason why the Name of the fields looks like obfuscated is because those controls are not handwritten but generated by the Code of ASP.NET Engine and parser, Reason field having such a name called Naming Container
One suggestion I would say is that, rather than trying to scraping the screen data, you can try alternate approaches, like each of the List in the SharePoint has the XML Feed inbuilt,try to consume it, if you have access to the site, try to retrieve the information using export to excel etc.
In addition to RSS, SharePoint also has a Web Services interface that you can use to get at and interact with data stored in SharePoint in a programatic way.
Does anyone know if it is possible to display a prompt to a user/administrator when activating or installing a sharepoint feature?
I am writing a custom webpart and it is connecting to a separate database, I would like to allow the administrator to select or type in a connection string when installing the .wsp file or activating the feature.
I am looking inside the FeatureActivated event and thinking of using the SPWebConfigModification class to actually write the connection string to the web.config files in the farm.
I do not want to hand edit the web.configs or hard code the string into the DLL.
If you have other methods for handling connection strings inside sharepoint I would be interested in them as well.
Unfortunately there is no way to swap to a screen where you can get user via the feature activation process. Couple of comments for you:
I'm assuming the connection string is going to be different for every installation, so there is no way you can include it directly in the Solution.
I'm assuming that you couldn't programmatically construct this during installation.
Therefore, you need some way to get user input. Here are a couple of options:
It could be a web part property, though this would mean setting it each and every time the web part was added, and you would need to then maitain those settings individually.
You could build out your own _layouts settings screen (good post: http://community.zevenseas.com/Blogs/Robin/archive/2008/03/17/lcm-creating-custom-application-page-and-using-the-propertybag-more-detailed.aspx), and from there users can maintain the property, storing it in either the Web Property bag, or inside the Web.Config. I try to avoid using the Web.Config where I can, but if you do wish to go this route then MAKE SURE you use the SPWebConfigModification class (Read this great blog: http://www.crsw.com/mark/Lists/Posts/Post.aspx?ID=32)
Finally, a technique I often use is storing configuration information in a SharePoint List. Chris O'Brien has a great framework for that here: http://www.codeplex.com/SPConfigStore
Hope that helps,
Daniel
Sounds good. I will look at these possible solutions.
I do not think #1 will work since I am deploying multiple webparts inside a single solution which all use the same connectionString.
#3 sounds like a very clean solution. I see the config items are cached so it looks like if I need to store a connection string, I will not be hit with a SP lookup each time I need that string.
While searching for a solution I did stumble across another method.
If you dig around their code, I looks like they have created an installer that accepts application specific values, adds the values into a FeatureTemplate.xml file and passes them to the SPFeatureReceiverProperties object in the Reciever.
I was about to start tackling this method, but I think #3 would be better.
Thank you,
Keith