I wanted to validate some of my understanding on the amound of memory that a .Net instance occupies on Windows Phone and sent a request to Abhinaba Basu of the .Net Compact Framework team for more information. He promptly responded with a nice explanation of how a .Net object is laid out in memory. Instead of reposting his work I'd like to refer you to his blog and the article he wrote explaining this. I'll be making some references to it in the near future.
The version of the .Net Compact Framework found in Windows Phone 7 is 3.7. One of the new capabilities added to the Compact Framework in this version is code sharing.
Under the 3.5 Compact Framework if there were multiple applications running that used a shared .Net assembly each process would JIT compile it's own copy of that assembly in its process space. With mobile devices often having constrained memory (and Windows Mobile devices only allowing 32 MB per process) this was an area in which improvement could be made. And with the 3.7 CF improvement was made.
In the 3.7 CF shared assemblies are managed by the kernel and their JITed code and type information is in a shared read-only heap. Overall this can lead to faster start time for applications (since some of the code the application needs may have already been JIT compiled) and lower memory demands.
For the time being this is a feature that I imagine would largely be used to host Microsoft assemblies since third party applications won't be allowed to run simultaneously.
You can find more information about these changes in this blog entry.
HttpWebRequest handles redirects automatically. That's usually a nice feature but it can actually get in the way when the web server is setting cookies in the same response in which it is sending a redirect. For some odd reason the HttpWebRequest object will totally discard cookies that are set with a redirect response. I ran into a problem with this when I was working in some code that interfaced to Google Voice and it was driving me crazy since I didn't know where the problem was coming from.
Once I figured out what was happening the solution to the problem was simple. The first step is to disable the class's automatic response to redirect request. When a response is returned from the class it's necessary to check the response to see if it includes a redirect and if so create a new request. Since a redirect could occur more than once it is necessary to do this in a loop. With each new
WebRequest that is created it is necessary to set the
A simplified version of my code looks like the following:
HttpWebRequest GetNewRequest(string targetUrl)
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(targetUrl);
request.CookieContainer = SessionCookieContainer;
request.AllowAutoRedirect = false;
HttpWebRequest request = GetNewRequest(targetUrl);
HttpWebResponse response= (HttpWebResponse)request.GetResponse();
while (response.StatusCode == HttpStatusCode.Found)
request = GetNewRequest(response.Headers["Location"]);
//--At this point the redirected response is ready to be used
Trying to perform this same thing on the .Net Compact Framework is a little more challenging since it doesn't support cookies at all. I'll discuss the solution I used in another post within the next few days.
A new Patterns and Practices book is available for download from the MSDN download center. If you are unfamiliar with the Patterns and Practices publications they contain guidance and solutions for commonly encountered needs or problems. You can find more information about the book here: