It's been snowing for about 5 hours. The grass is still peeking through the wet & slimy white stuff, but the ground is throughly covered. And I"m sitting here at my computer wearing a brand new pair of back country ski boots trying to determine if they are keeper or not. I'd say winter is here.

There's something about a conference that inadvertantly makes me go dark.

I did 4 sessions and a workshop at DevConnections last week.

In the weeks leading up to to this, I was heads down finalizing my presentations. That includes mucking with the PowerPoint's and fine-tuning demos and stuffing as much into my brain about the various technologies as I can.

While I was at the conference I spent a lot of my time in my room continuing on this path. The speaker room is a bad place for me to work - too many people I want to talk to!  I did get to attend a number of Entity Framework and Astoria sessions on Tuesday, but that's all that I saw in the entire show.

Because I had disparate topics (tablet pc, silverlight, entity framework and LINQ), I needed to really clear my head of the previous topic and wrap my head around the next one.

During this time I did check emails, but I didn't check my office voice mail, I didn't do any client work and I managed to write only one blog post. I even got to go out to dinner one night, but most of the rest were working in my room.

(I'm not complaining, by the way, just sharing what it's like...)

At the end of the week, I went to Colorado for a few days to hang out with my sister & brother in law. I checked email but again, no work, no blogging.

Not only did I not blog, but I wasn't reading blogs. I had missed the DevCOnnex keynotes and no idea that the VS2008 RTM date was finally announced, that live services came out of beta and more was going on.

I got home Monday afternoon, spent two hours at my house then got back in the car for the VTdotNET user group meeting (another blog I need to write). Since it was the birthday of our illustrious speaker, Russ Fustino, we went out and I got home at about 11:00pm.

Tuesday I finally got to do some client work for the first time in about 3 weeks! I have a huge list of things to do, but topping that list were a host of things one of my client's has been patiently waiting for.

It still amazes me the impact that conference speaking has on my routine. I am hoping to get my head above water by the end of this week. I also am bummed that I haven't had any exercise since before I headed to the conference. I had high hopes and brought my swimsuit, sneakers and other related clothes with me, but they never got touched!

So I have LOTS to blog about and so many people awaiting so many things from me. I will just be getting through it all one step at a time...

Mike Flasko presented on Astoria this afternoon as part of the Data Access track at DevConnections. Being the PM on the Astoria team, Mike's not stuck with the prototype bits like the rest of us slackers and was using production bits of what Astoria will really look like.

Here's a few new things:

1. No more code name. Bah - I always hate this part. I like Astoria.

The official name of the product is ADO.NET Data Services. Oh boring, but descriptive. Although when you see #5, you might wonder why "ADO.NET" is in the name.

2. No more POX (Plain old XML) and they didn't go with that Web3S format either. Data will be spit out as JSON or ATOM. ATOM is xml is formatted for blog posts so you'll see elements named feed and more.

3. AJAX Client. When working with the services from the client side usig ajax, there is an ajax client api. It was something like sys.data.services. I will ask Mike and fix that. You can use this to easily point to the data service and do things like call an insert method to easily insert a json object.

4. You can incorporate mime types into your data and when the service is built, those will be pulled in and then (as a example) if you have data that is the binary of a gif and it has image mime type associated with it, then  the data will be served up as the image, not as the string of binary. This is easily demonstrated when using the uri directly in a browser. I haven't seen how this surfaces in a client app. But it's very sweet.

5. Build services against any class that exposes iQueryables. Entity Framework queries return iQueryables of entities. After some discussion of which way to go with this in the Astoria Team blog, they decided to leverage the iQueryable. So you can build a class that has a public method that returns your data as iQueryables, then you can build the service against that just as easily as you can build one against an EDM.

6. Last bu hardly least is. dah dah dah dah...

LINQ to ASTORIA.

Yes, Virginia. You can write a LINQ query that will get interpreted into the URI. Astoria already provides a means of generating classes for clients to use, so LINQ just works against these classes.

That's all I remember since I didn't have my computer or a scrap of paper with me in the session.

Danny Simmons and Mike Flasko will be holding a 1/2 hour chalk talk on Architecting Entity Framework apps at 2:30 on Wednesday at DevCONnections.

If you want to see all of the talks in the special Data Access track (Entity Framework and more) check this blog post where I have them all listed.

I finally discovered the UpdateProgress control for an easy way of getting an animated gif to display at the proper times on a page using ASP.NET AJAX. REad more...

[A New DevLife Post]

Over a week ago, I accidentally left a car window partially open overnight. The next day there was lots of evidence of a mouse in the car - shredded kleenex, mouse poop and more. I looked everywhere for the mouse but could not find him (her?) and figured it was gone. I didn't really go anywhere for about a week. On Friday night I rove to a neighbor's house wondering if it was possibly still in the car and was going to jump on my head while I was driving, but it didn't.

But on Sunday I looked in the car again and there was more shredded kleenex and poop. Rich and I spent an hour cleaning, vacuuming and inspecting every nook and cranny but found no mouse.

Rich decided there was only one way to get rid of the mouse if it was still hiding out in the car - a solution that I am not fond of at all, but let him take charge of the situation. So he put a mouse trip (oh boo hoo) with some peanut butter on the floor of the front seat. I'm more of a hava-heart trap kind of girl.

Poor little mousey.

This morning I unwillingly looked into the car when I took the dogs out. Seeing a tail and a butt was enough, I didn't want to see his poor little head or neck under the business end of the trap. Rich is going to go out and deal with it.

I stole the little EF on Rails quip from Roger Jennings who asked on his blog "what the heck happened to Jasper?" (my words, not his)

Here's an overview article on Jasper that I wrote a few months ago.

Andy Conrad, who is a PM on that replied that it's still around and they have an internal revision of the original prototype, but that they need to see more interest in it before really making an investment in it. (Again, my words, not his.)

Check out Roger's post and Andy's comment. It's a shame that the best place to learn things like this is in the comments of 3rd party blogger posts, rather than directly in the team blogs, but iwth the rapid pace that everyone's moving at these days trying to get Orcas out the door, trying to get Entity Framework and Astoria wrapped up, I'll take what I can get!

So if you're interested, let them know. A good place is comments on Andy's blog or in the Jasper forums.

Roger's post are so chock full of information, it's easy to miss things on the first read or two but they are alwasy worth returning to, especially as he updates them to keep them accurate.

In a recent post, he pointed to an "article" - 38 pages is quite long for an article - which is part of the WROX BLOX series that you can download for $3.99 Leveraging LINQ in ASP.NET 3.5 projects. Since I am doing a session next week at DevConnections on ASP.NET Databinding with LINQ, I think I'm going to grab this to help enforce or certainly add to what I already have in my head, my demos and my deck! The session is only 75 minutes long, so I guess I can't just stand up in front of the room and read it out loud.  (just kidding!)

Therefore, back to work!

You can find Roger's mention of it in this post, which itself is probably a good 38 pages as well.

Someone asked a common question in the forums today about being able to update an EDM when the datastore has changed.

Noam Ben-Ami, who is on the team working on the tools, says this:

We are hard at work on this feature right now and hopefully we'll be able to get it into CTP2 of the designer.

Along with support for stored procedures, it is our highest priority.

So three things to get out of this:

1. There will (or will probably be...) a CTP2 of the designer. That indicates to me they still have a lot of ideas that they want to implement and are still working out which is why that doesn't say "Beta".
2. There is going to be one (or more?) ways to support db updates in the desiger. I am really curious if we'll be able to add just "drop" new tables in without actually updating.
3. Designer support for sprocs is coming. Noam and I talked about this a while back and he described what I thought was a great idea for implementing this. I'm looking to see how that idea evolves.

In the meantime, I wrote a blog post this morning about how to apply db updates using the current version of the designer.

In a recent ADO.NET forum post, someone asked how to do read-only views of data. There were two responses - use a QueryView and use a Defining Query.

What's the difference?

A Query view is an Entity SQL Query that exists right in your mapping layer. It allows you to solve two problems. THe first is creating complex queries that you don't want your coders to have to worry about building. You can just build the query in the mapping layer, expose the resulting entity in the conceptual layer and the classes that the developers code & query against will just be there for them to use.

The second benefit is that you can use this to limit access to particular data from the database. For example, if you have a table which has GUIDs or hashed passwords in it, you may not want those to ever be surfaced in the application. You can "filter those out", by creating a QueryView. FWIW, you could also do this by just deleting the columns in the store layer definition.

The QueryVIew then queries against the storage schema, not directly against your database, and then the results are output to an entity in your conceptual layer. So in effect, it is a different way of mapping between your store layer and your conceptual layer.

The QueryView is part of the EntitySet mapping and looks like this:

  <EntitySetMapping Name="Categories">
      <QueryView>
        SELECT VALUE Microsoft.CDP.Samples.Northwind.Category(C.CategoryID, C.CategoryName, C.Description)
          FROM dbo.Categories as C
      </QueryView>
    </EntitySetMapping>

This simple query (note the syntax; it's an Entity SQL query) is replacing the mapping for Categories. It gets 3 columns from the Category entity in the store model (dbo) and maps the results to the conceptual entity, Category. Remember that I have created a read-only view, so you might not want to use this to just filter out columns if you still need to do updates and want to do them using the mappings (vs. using sprocs to do the updates).

You can also invent new queries and new entities to go along with them.

Defining Query

I love that MIke Pizzo refers to Defining Query as "the ultimate escape hatch".

Defining Queries are defined in the storage layer. They are really nothing more than database views - directly against the database. So you have a really complicated query that you can't describe with LINQ or with Entity SQL but you can describe it in TSQL, but and the dba is not around, unable or unwilling (for a variety fo very good reasons) to add a new view into the database for you, you can just create it in the storage layer. In fact, when you run the EDM Wizard against a database and it finds views, the wizard represents these views in the store layer as Defining Queries.

There are two parts to a Defining Query.

The query itself which is an EntitySet in the store model and an Entity in the store model that describes/defines the result set.

The rest of the model then treats the query as it would any other table. You have entities in your conceptual layer and they map to the entity that describes the result set of the Defining Query.

Here's what one looks like.

<EntitySet Name="custview" EntityType="AdventureWorksLTModel.Store.custview">
  <DefiningQuery>SELECT [custview].[CustomerID] AS [CustomerID],
   [custview].[FirstName] AS [FirstName],
   [custview].[LastName] AS [LastName],
   [custview].[CompanyName] AS [CompanyName]
   FROM [dbo].[custview] AS [custview]
  </DefiningQuery>
</EntitySet>

And the entity that you will map to

<EntityType Name="custview">
  <Key>
   <PropertyRef Name="CustomerID" />
   <PropertyRef Name="FirstName" />
   <PropertyRef Name="LastName" />
  </Key>
  <Property Name="CustomerID" Type="int" Nullable="false" StoreGeneratedPattern="identity" />
  <Property Name="FirstName" Type="nvarchar" Nullable="false" MaxLength="50" />
  <Property Name="LastName" Type="nvarchar" Nullable="false" MaxLength="50" />
  <Property Name="CompanyName" Type="nvarchar" MaxLength="128" />
</EntityType>

As I said above, you can then have an entity in your conceptual layer that just maps to this entity and nobody will ever know the difference. Which beg the reminder that this is read-only!

Damn damn damn!

I was writing a really technical post. I wanted to use the code formatter which pops up in a separate window. IE7 said - popup? Is that okay? I said yes. It REFRESHED THE PAGE and I lost all of that which I had written.

RUns away screaming....

With the current CTP of the ENtity Data Model Tools, there is no way to automatically update or refresh the EDM when a change is made to the data store.

One of the beauties of the EDM is that fixing up the EDM in these cases is not only easy, but it doesn't need to have any impact on your application, because you can leave the conceptual layer which you program against in tact.

Here's an example of a minor change (inspired by a question in the forums) in the database and what you need to do today (I keep saying that because I don't know what the next increments of the tools will bring) to fix up your model.

Scenario: DBA changed fname and lname columns in the Customer table to firstname and lastname.

In a non-EDM application this could be dealt with in a few places, depending on how your db and app are architected:

• Modify any stored procs and views that spit out those fields so that they now know how to grab firstname and lastname but continue to surface them as fname and lname.
• Modify the data layer of your application (and redeploy it) so that it now is aware of firstname and lastname. Modify your business layer so that it knows that the properties have to look for firstname and lastname.
• If your app doesn't use these layers (hopefully that's a big "if"), then you need to make those changes even closer to the UI.

In an EDM here's how you would solve the problem.

1. Change the column name in the storage schema.
2. Change the column name in the mapping schema for the two mappings that link those fields.

Step by step

Open up the EDMX in the XML Editor. (Right click on EDMX in the solution explorer, choose open with, then XML Editor).

You can do all of this in the raw xml, which to me is easy. THe current designer does let you change the mappings. SO I will show how to do #1 in the raw xml then #2 using the designer.

Locate the node for the Storage Model. You can find that quickly by searching for it's comment "SSDL Content" or it's name "StorageModels".

IN there, locate the entity that represents the table with the change.

Edit the name of the entity.

Close the EDMX and re-open it in the designer.

Another part of what makes EDM so great is that when I first created this model, I didn't like "fname" and "lname" and changed them in my conceptual layer to FIrstName and LastName. At that point, they were properly mapped to the fname and lname columns and all was well.  This is what the mapping looked like before I started making the changes. YOu can see that my db column was called "fname" and my property in my conceptual layer was "FirstName".

Now that the dba decided to change the column names in the database as well, I just need to remap my FirstName and LastName properties to the newly named database columns.

Select the Customer Entity and then open the Entity Mapping Details. (If you don't see that page, right click on the model (in the white space) and select SHow Entity Mapping Details.)

The mapping details shows  you the columns from the storage entity first (e.g. the database table) and then on the right which property in your conceptual entity that column is mapped to.

You'll see that the columns fname and lname are gone from the mapping and it is now showing you the FirstName and LastName from the store schema, but they aren't mapped to any properties in your conceptual entity.

Just drop down the value/property list and it you will see all of the properties in the entity that this is mapped to.

That's it. And the impact with respect to deployment is that the new versions of the xml files that describe the schema need to be deployed to whatever tier the data layer that needs to know how to do the mappings. The client apps most likely just have the classes that were derived from the conceptual layer and since we didn't change that part, they don't need to know anything and can go on their merry way.

I've found that the best resource for learning about ENtity Framework is in the forums. Today I finally saw a public statement about something I"ve been waiting for for a long time.

Brian Dawson says:

We've been working on making the WCF experience, especially with relationships, a much better experience no matter which serialization scheme you choose. Binary serialization has been working already, but in the cases where we are doing other types of serialization, dealing with relationships was tricky and we purposely don't deal with deep serialization, at least in this release. What we did do was add the EntityKey as a serializational property on the relationship reference. This way, if you serialize Product, you'll get the EntityKey for Category. You can treat the CategoryReference.EntityKey  similar to a foreign key. Basically, this allows you to fetch entities with the key, and also do updates and deletes without having to rebuild all the dependant ends.  We are targeting Beta3 for some additional information in this specific area.

What he's talking about is this: when you do binary serliaziont of an object graph (i.e. and entity and anything that is attached to it) you get the whole thing, but if you do xml serialization, you only get the entity. That makes doing web services a nightmare. I have written a few posts about dealing with this using the current Beta 2 bits of Entity Framework. Here's the critical one : XML Serializing Entity Framework Entities With Their Children For SOA.

Another critical problem is that you lose all of your statemanagement. Here's a post I wrote about how to recreate state so tha tyou can do updates, etc. More on Disconnected Entity Framework

If you watch the forums you may have noticed that there have been a lot of people hammering on the team. On one thread about this topic which I would not let go, Danny SImmons finally responded:

This thread is getting way out of hand, and clearly we need to get some better guidance together on all of this (a few good blog posts at least).  

So, instead of writing blog posts and guidance (unless you count mine) they went to work on the bits! Happily they are going to make it a lot easier in Beta 3 enabling us to not only rebuild full graphs, but reconstituting the state.

In the past month (plus a few days), I have flown across the country twice (one was an overnight trip to San Diego for an INETA talk, the other was for a few days for some training in Redmond at Microsoft) and driven to Boston twice (4 hours each way, once for COde Camp, and then again for REMIX) and Montreal once for a user group meeting.

STill ahead of me in the next month (plus a few days) are three more cross country trips. Las Vegas for DevConnections, Vancouver for DevTeach and then back to Seattle for another quickie trip.

(And before you ask, no, I am not interviewing. You should know me better than that by now. I'm just trying to learn a thing or two and rack up those miles.)

A few days ago I got an email from the Sr. Editor of ComputerWorld who was interested to learn what had become of the group of Vermont software companies that had banded together a few years ago. He was referring to the Vermont Software Developer Alliance an organization who's board I have served on since it began over three years ago.

I passed him on to our new Executive Director, Patrick Martell and only days later, this story appeared in Computerworld. Cool!

Green thinking vs. great access: A tale of two high-tech contenders
Ambitious Vermont needs what Westchester County, N. Y., has: broadband

I had to figure this out, so here are a billion screenshots so anyone who wants to do this will have an easier time of it!

One of the niceties about being able to customize your conceptual models is not having to bother the dba while they are doing important things like indexing tables and optimizing the database. If you find you have some tables that came into your entity data model that have primary/foreign key relationships that were never defined in the database, then the wizard won't have built associations for you.

Imagine I have two entities, client and title. A client has many titles (kinda like a publisher but I used a different db for my example, so just live with "client".) The title entity has a property called clientid. I want to build an association between the two

Right click in the model (white area, not on an entity) and you will get a context menu. Select Add, then Association.

This little window will pop up. It will default the two ends populated with the first two alphabetical entities.

Use the dropdowns in End Entity to change the two end points. I made mine CLient and Title.

The multiplicity options are 1, Zero or One and Many. My relationship is that is one to many, but I can have titles that don't have a client, so I'm choosing 0..1 for the client and * for the title.

I changed the names of the navigation properties. They started out as Title and Client1. When I'm working with a client, I want to see a property called Titles. (Client.TItles) and title only has one client, so these are the names I want, Titles and Client.

Next is a step that may not make sense but you need to delete the "clientid" property in the title entity. Because of this association, the clientid has a job now and doesn't belong as a property. (This is debatable and there have been requests to modify this rule for EDMs, but right now, that's the way it works. You can read more about why in this blog post.)

Now to the mappings. We have told the entities that they are related but they don't know the basis for their relationship. This happens in the mappings where we wire things up to the representation of the database that is part of the EDMX file created by the wizard.

Right click in the model again and choose Show Entity Mapping Details.

You'll see an almost empty view, that has only Association and under it <Add a Table or View>. Click on Add a Table or View. Choose one of the entities. This is a little confusing here and I have actually made a suggestion in the forums to simplify it, but just go with the flow.

You'll get a default that shows the end points you identified in the association and most likely you'll see id's on the left and id's on the right. The "id" on the left refers to the property of the end point. The one on the right refers to the column in the database table (literally the store entity, but db table is easier to grok in this case) that you are mapping to. SO that's why you see that I have changed my mapping so that client's id property will map to the client id field in "the other end of the association", e.g. the Title. Then the title end point (End2) will map over to the id of the other endpoint (client).

Now here's a small bug with the designer, even if I choose clientid from the drop down list under column, it doesn't stick (remember, the tool is just a preview right now). I originally had gone into the raw xml to fix this, but thanks to a pointer by Philip in the comments, I see how to get around it more easily.

In the drop down, first choose <Delete>. Then there will be no column mapping for the client end point. Now drop down the list again and choosed clientid. This way it stays.

---------------------------------------
I'm going to leave the by-hand notes in here just for educational purposes.

So I had to doctor this up in the raw xml.

Luckily this was at the bottom of the whole xml file.

<AssociationSetMapping Name="ClientTitle" TypeName="EFSampleDatabaseModel.ClientTitle" StoreEntitySet="Titles" >
  <EndProperty Name="Title" >
    <ScalarProperty Name="id" ColumnName="id" />
  </EndProperty>
  <EndProperty Name="Client" >
    <ScalarProperty Name="id" ColumnName="clientid" />
  </EndProperty>
  <Condition ColumnName="clientid" IsNull="false" />
</AssociationSetMapping>

I've bolded the two changes I made. These were originally "id" because of the mapper problem.
---------------------------------------

The condition exists because it makes no sense to map titles that have null clientids.

Now I can write code like this and see the associations working

Dim oc As New EFSampleDatabaseModel.Entities
Dim q = From c In oc.Clients Select c, c.Titles

For Each c In q
  Console.WriteLine(c.Titles.Count)
Next

I pilfered this from my parent's website, www.BlueHeavenNewfoundlands.com. They are newfie breeders (mostly Landseers, like Rollo). Rollo is one of their puppies, now 8 years old, who is owned by a really neat lady who dances with her dogs competitively. Yes dances. She and Rollo were even on Nick at Nite and they compete in various "Freestyle" events. YOu can read more about that here. She dresses up her dogs for the dancing and also for pics like these - for Halloween, New Years and more. There's a page filled with them on my parent's site.

A slew of Silverlight books, a better way to handle Silverlight installs from your website and moving to Silverlight 1.1.

[A New DevLife Post] 

I spent a lot of time coding in javascript for silverlight 1.0 and am having fun now getting back to managed code with 1.1. I'm even doing it all in C#, but the main reason is because I  have a lot of nearly reusable javascript code and it's just easier to port that to C#.

However, as usual, I am just diving head first and not doing too much advance research. Two things I learned the hard way:

Silverlight does not yet support LINQ
A few months ago, I spent bunch of time buliding a beatiful LINQ to XML method to build up some XAML by hand only to discovere when I tried to run it, that it failed. I looked around and discovered that LINQ support was not there yet. Oops! But it was my first time using LINQ to XML to build an XML document, so what I learned in the process was not a waste by any means.

Silverlight does not yet support WCF
I built a very nice WCF service, with composite types and everything only to learn (when I went to add service reference to my SL client) that it's not supported yet. There are a few workarounds, [here on the sliverlight forums] and [here in Luis Abreu's blog], but since this particular code will be for a conference demo and I don't want to add any extra layers of complexity, I will just go back to ASMX for this one.

I spent a lot of time coding in javascript for silverlight 1.0 and am having fun now getting back to managed code with 1.1. I'm even doing it all in C#, but the main reason is because I  have a lot of nearly reusable javascript code and it's just easier to port that to C#.

However, as usual, I am just diving head first and not doing too much advance research. Two things I learned the hard way:

Silverlight does not yet support LINQ
I spent bunch of time buliding a beatiful LINQ to XML method to build up some XAML by hand. But it was my first time using LINQ to XML to build and XML document, so what I learned in doing that was not a waste by any means.

Silverlight does not yet support WCF
I built a very nice WCF service, with composite types and everything only to learn (when I went to add service reference to my SL client) that it's not supported yet. There are a few workarounds, [here on the sliverlight forums] and [here in Luis Abreu's blog], but since this particular code will be for a conference demo and I don't want to add any extra layers of complexity, I will just go back to ASMX for this one.