Tell me more ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 1 down vote favorite

I have noticed that the custom properties of a webpart I developed return to their default values when I reboot my machine.

Is that a normal behavior? are the properties saved as far as the server is up, or there is some parameters I am missing.

Thank you.

EDIT: code:

namespace TestWebpart
{
    [ToolboxItemAttribute(false)]
    [XmlRoot(Namespace = "TestWebpart")]
    public class GraphWebpart : Microsoft.SharePoint.WebPartPages.WebPart
    {
        // Visual Studio might automatically update this path when you change the Visual Web Part project item.
        private const string _ascxPath = @"~/_CONTROLTEMPLATES/Test_Graph/TestWebpart/GraphWebpartUserControl.ascx";

        protected override void CreateChildControls()
        {
            ReloadElements();
        }

        protected void ReloadElements()
        {
            Controls.Clear();
            GraphWebpartUserControl control = (GraphWebpartUserControl)Page.LoadControl(_ascxPath);

            control.xmlDataUrl = XMLFileUrl;

            Controls.Add(control);
        }

        private static string _xmlFileUrl;
        [WebBrowsable(true),
        Personalizable(PersonalizationScope.Shared),
        DefaultValue(""),
        Description("xml"),
        DisplayName("xml"),
        WebDisplayName("xml")]
        public string XMLFileUrl
        {
            get { return _xmlFileUrl; }
            set { 
                _xmlFileUrl = value;
                ReloadElements();
            }
        }
}
}

EDIT2: Deleting static from the fields throws the flowing exception: 

Web Part Error: An error occurred while setting the value of this property: TestWebpart:XMLFileUrl - Exception has been thrown by the target of an invocation.
Hide Error Details

[WebPartPageUserException: An error occurred while setting the value of this property: Blue_Graph.GraphWebpart.GraphWebpart:XMLFileUrl - Exception has been thrown by the target of an invocation.]
  at Microsoft.SharePoint.WebPartPages.BinaryWebPartDeserializer.ApplyPropertyState(Control control) 
  at Microsoft.SharePoint.WebPartPages.BinaryWebPartDeserializer.Deserialize() 
  at Microsoft.SharePoint.WebPartPages.SPWebPartManager.CreateWebPartsFromRowSetData(Boolean onlyInitializeClosedWebParts)
share|improve this question
That is not normal behavior as the properties are persisted in the database. Some sample code always helps... – Floyd Pink Sep 13 '10 at 1:36
Well, there is nothing special about my code, see update. – 0xFF Sep 13 '10 at 8:14
One thing that jumps out on me is the class you're inheriting from. Check out the remarks here - msdn.microsoft.com/en-us/library/… – Floyd Pink Sep 13 '10 at 11:03

1 Answer

up vote 2 down vote accepted

First of all you should not have

private static string _xmlFileUrl;

it should be 

private string _xmlFileUrl;

This static variable will be lost on IISRESET - won't work in a farm and has the potential to cause all sort of 'thread safe' issues if used multi-threaded environment (like a web server) so only use them if they are really needed.

When SharePoint loads a web part (or after you click Save/Apply in the toolpart) it uses reflection to find your properties (the [Browsable... attribute) and then serialization to load/save the value of the property to the database. One of these two is failing.

I would suspect that is some problem with the attribute - try this one and work backwards until it stops working ;)

[Browsable(true),
 Category("Miscellaneous"),
 DefaultValue(defaultText),
 WebPartStorage(Storage.Personal),
 FriendlyName("Text"),
 Description("Text Property")]
share|improve this answer
deleting static gives an exception now, please see the edit – 0xFF Sep 13 '10 at 15:55
Do you understand what static is doing (its hiding the fact that something is wrong in the attributes and the serialization of the properties is not working) - have you tried changing the attributes? – Ryan Sep 14 '10 at 12:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.