March 2008 - Mike Taulty's Blog

Julie points to Danny and Danny points to the next CTP of Entity Framework - if you're interested in serializing the entities that Entity Framework returns back to you then you'll be interested in this; http://www.thedatafarm.com/blog/2008/03/28/HallelujahEntityGraphsWillBeXMLSerializable.aspx

This really falls into the category of "just because it's there" because it's something I was thinking about earlier today and wanted to experiment with. Silverlight 2 applications can make web service calls across domain boundaries if the domain that they are calling to allows that. So, I was thinking about a scenario where perhaps I've got a local application installed such as a WPF application or perhaps a Vista Sidebar gadget and I go and visit a Silverlight website and the Silverlight client can notify the installed application and cause it to maybe "light up" in some fashion. That is, a Silverlight 2 application communicating with another application that's installed and running on the local machine. Before Silverlight will allow a cross-domain call it requests one of two files from the root of the site that it's calling to. I chose to use clientaccesspolicy.xml. So, I wrote a quick "WCF Service" using the System.ServiceModel.Web stuff from .NET Framework V3.5. Service looks like this; [ServiceContract]...

Corrina has posted 4 skins so far for some of the standard Silverlight controls; Bubbly View Download Red View Download Flat View Download and the 4th one is hanging off this post here; A New Control Skin Set

I was talking to Ian and another chap at the UK Launch yesterday about LINQ to SQL and my use of the DataContext in some demo code where I always tend to write something like; using (DataContext ctx = new DataContext()) { } and whether I actually needed to do that dispose or not? Now...I was pretty confident that I do need to do this for two reasons; DataContext is disposable so I figure I should probably Dispose() of it - generally been my approach to anything IDisposable. Someone had recently asked me whether DataContext.Dispose() actually did close the SQL connection and I'd done a little bit of reflecting on it and spotted that; DataContext.Dispose() -> SqlProvider.Dispose() -> SqlConnectionManager.DisposeConnection() -> SqlConnection.Close() although the code paths are more complex than that and I haven't attempted to figure out under what conditions the various calls happen. So, I'd kind of reasoned that; If you don't dispose of the DataContext then you won't get the connection closed and back in...

I was bored in my hotel room so I thought I'd have a bit of a play with Silverlight 2 and sockets - you can ( in beta 1 ) open sockets back to the site of origin within a restricted port range ( 4502 to 4532 ). I wrote a little Silverlight UI ( it's a bit much to call it a UI as it only has one TextBlock on it :-) ); < Grid x:Name ="LayoutRoot" Background ="Gray" > < TextBlock x:Name ="theText" FontSize ="24" Text ="Not set" HorizontalAlignment ="Center" VerticalAlignment ="Center" /> </ Grid > and then I wrote some code behind this to update the textblock based on a time that I receive from the server. I wrote a little class to try and help me with that ( no doubt riddled with bugs :-) ); public class DateTimeEventArgs : EventArgs { public DateTime NewDateTime { get; set; } } public class SocketDateTimeReader { public string Host { get; set; } public int Port { get; set; } public SocketDateTimeReader () { socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); ...

Path and File resolution in Silverlight 2 is confusing so, fortunately, Pete Brown has a good post on it here .

I had a discussion at DevWeek about when SqlDataReader.Read () gets called for resultsets coming back from stored procedures accessed with LINQ to SQL. I've got this stored proc; create procedure dbo.GetCustomersByCountry @country nvarchar( max ) as set nocount on select * from dbo.customers where country = @country and I've brought it into LINQ to SQL using the designer and that means that I can write code such as; using (NorthwindModelDataContext ctx = new NorthwindModelDataContext()) { var query = ctx.GetCustomersByCountry( "UK" ); foreach (Customer c in query) { Console.WriteLine(c.CustomerID); } } Question is - when does SqlDataReader.Read() get called here? Do we read all of the data up front and then just provide access to an in-memory collection or is the data read from the wire as the loop iterates over it? I wanted to check so I went ahead and set some breakpoints in a few places; Inside the constructor of my Customer class. Inside SqlDataReader.Read() and what I see there is an interleaved set of calls...