Hello all, I am trying to migrate my site from In-proc state management to out-of-proc SQL state management. I am having problems with the serialization of my classes. I have added the [Serializable] attribute to the classes, which works, but some of the classes' objects (XmlDocument is one example), are causing errors: "[SerializationException: The type System.Xml.XmlDocument in Assembly System.Xml, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 is not marked as serializable.]" Is there a quick way around this? Perhaps creating a derived class from XmlDocument that is marked as serializable, or is there another attribute or solution that I am missing? Thanks for your help, - gsk Just because I don't care, doesn't mean I don't understand. - Homer J. Simpson
Geoff Kushnir
Posts
-
Serializng objects for SQL State management -
Problems with WebRequest and ConnectionAn excellent suggestion, and I have saved your code in case of future problems. However, in this case, I have checked with the hosting providor and they have said that no proxy server is used for the connection. Any other ideas would be appreciated. Can anyone tell me what the WebRequest relies on for establishing a connection? I am assuming the local TCP/IP settings, DNS, etc., but is there anything else I may be missing? Just because I don't care, doesn't mean I don't understand. - Homer J. Simpson
-
Problems with WebRequest and ConnectionThis one has me stumped: I am using HttpWebRequest to resolve an external URL (that outputs an XML string). It works fine on my dev machine (W2K), and used to work on my production machine (W2K3). It seems that now, for some reason, the connection cannot be established. The error logged is: The underlying connection was closed: Unable to connect to the remote server." source="System" stack="at System.Net.HttpWebRequest.CheckFinalStatus()..." I can connect to the Internet via the browser on this machine, and all network related services seem to be working. (Terminal services, etc.) I've fiddled with the Timeout on the WebRequest object to no avail. The most frustrating thing is that it recently worked - once - then stopped working again. I'm not sure if it is a network issue, hardware issue, security issue on W2K3, etc.? Any help would be appreciated. Here is the function called: private string readHtmlPage(string url) { string _result; WebResponse objResponse; WebRequest objRequest = System.Net.HttpWebRequest.Create(url); objResponse = objRequest.GetResponse(); using (StreamReader sr = new StreamReader(objResponse.GetResponseStream()) ) { _result = sr.ReadToEnd(); // Close and clean up the StreamReader sr.Close(); } return _result; } Thanks! - gsk. Just because I don't care, doesn't mean I don't understand. - Homer J. Simpson
-
UserConcurrencyHow about creating a dynamic array (ArrayList for instance) of the Session IDs? On Session_Begin, add the ID to the array if it doesn't currently exist, on Session_End, remove the Session_ID. TrimToSize each time and use the Count to get the number of active sessions. I seem to remember a similar solution in traditional ASP using the Dictionary object... Just because I don't care, doesn't mean I don't understand. - Homer J. Simpson
-
Textbox validationHave you looked into using Regular Expressions? Just because I don't care, doesn't mean I don't understand. - Homer J. Simpson
-
Not able to update data in access dbAlso, in Windows Explorer make sure the correct account has write permissions. In traditional ASP, by default it was the IUSR_...acount. With .NET the deafult is the ASPNET account. Just because I don't care, doesn't mean I don't understand. - Homer J. Simpson
-
Registering dll's in asp.netYou can add your DLLs as references. In Solution Explorer, right-click on the References folder and 'Add Reference'. Then browse for the COM or .NET .dll. Just because I don't care, doesn't mean I don't understand. - Homer J. Simpson
-
Server.Transfer VS. Response.RedirectTo add to Heath's reply, the evidence of this is in the address bar. If you use a Server.Transfer you will see the address of the page has not changed, due to the fact that processing has stopped on the original page and transferred to the new page. Conversely, if you use Response.Redirect you will see the address of the new page in the address bar. Not sure if this matters but it may be relevant. Just because I don't care, doesn't mean I don't understand. - Homer J. Simpson