MrDave's (David Yack) Blog!

For a while I have seen where a setup will fail to build in a solution and there will be no errors to explain why it failed (My favorite type of failure!). When you look in the output folder the installer msi file is there.

Today we had that happen on a solution and when we used the setup we were getting an error during the actual install on the target machine.  Turns out to be not related at all, however, it got me digging around trying to figure out what caused the build to fail.  I ran across the following connect bug that has a work around

https://connect.microsoft.com/VisualStudio/feedback/Workaround.aspx?FeedbackID=317870

Turns out,  that adding a  LINQ to SQL dbml file or the L2S designer in use in Visual Studio can cause this error to happen.  Sure enough removing the ItemGroup mentioned in the workaround and restarted VS and the build worked.

The real bummer is I get the same build failed on my machines with SP1 beta on them so that means it probably won't be fixed soon.

Yesterday a new version of the ASP.NET Dynamic Data Futures was posted - I haven't had a chance to kick the tires on it yet, but one item on the change list that caught my eye was "Localized displayname and description attributes".  That's been one of the most common questions that has come up when people see a demo of using the attributes.

This release also appears to include support for plain CLR and Data Services that were in the Dynamic Data Extensions project that was available for download.

Read the full list here http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=14475

You can also find more details on Marcin's blog here

One thing to keep an eye out when using the Entity Framework - Generate From DB option is how tables with no keys are handled.  When one of these tables is encountered the Entity is mapped to a Defining Query instead of the physical table in the store. 

The reason you care is you are not able to update / modify an item mapped to Defining Query.   Currently, the designer doesn't give an indication that it's a read-only entity  - it would be great if in the future it could visually show it in the designer.

There are a few clue's to tell this has occurred, first, you Entity will have every eligible column marked as part of the Entity Key(basically all non nullable / non binary) .   You can also view the markup for the SSDL, and you will see the Defining Query when you look at that table in the store markup.  The most obvious indication this exists if you try to update it you will get the following error "Unable to update the EntitySet 'Events' because it has a DefiningQuery and no <DeleteFunction> element exists in the <ModificationFunctionMapping> element to support the current operation".

When the Generate From DB runs, it also creates an informational message to tell you this has happened.  It says something like " The table/view 'DemoTable' does not have a primary key defined. The key has been inferred and the definition was created as a read-only table/view.  "

On a new DB, this can easily happen during the initial stages if you add the table to the EDM before the real key is added.  To fix, you can add the proper key to the database then update the model from the database again to pickup the change.

After the update, you will have to manually correct the entity key's on the Entity as currently in V1, it only updates the definition in the store, and not the conceptual definition.

As indicated in the error above, you can also map to stored procedures and leave it a Defining Query.  That is typically done when you intended to use a Defining Query and not when it happened just because there's no key.

I think it would be great if the Generate From Db wizard would give you warnings before the generate was completed.  This would be especially important when you are updating an existing model if there was any potential problem that could be avoided. 

Now that Entity Framework V1 is in the final steps towards release as part of the .NET 3.5 SP1 beta the team is turning up the V2 design process.    I've been doing a bunch of training over the last month that has included Entity Framework as part of the events and it has been well received. 

I've also been following more of the community forums and blogs on EF.   People are asking a lot of great questions and sharing a lot of good ideas.  Like all big changes, V1 won't solve everyone's problems or be a good fit for everyone to adopt.  But it does set the stage with a solid foundation to build on.

If you haven't spent time in the forums, the EF team has been busy answering questions as well as starting to collect what features people want in V2.  Today, they took that a step further by setting up a Entity Framework Design blog that they plan to keep updated as they go through the V2 design process sharing as much as they can with the community.  If you read nothing else, read Tim Mallalieu's first post on the blog that outlines the intent of the transparency. 

How, When, If you adopt Entity Framework is an individual architecture choice each architect has to make for their company.  I never think you should just blindly adopt a Microsoft or any vendor technology just because it's released.  That said, you do need to evaluate and find ones that give you an advantage or speed up development or meet other goals.  Sometimes that even means not using all the advanced features from day 1.  If you use any Data Access (like who doesn't) you owe it to yourself to get involved and help shape the feature set for V2 - but first you probably need to get your hands around what V1 offers!   Remember, just reading a overview isn't the same as kicking the tires!

ok, so may be it was just a water pressure problem in the building that caused the NSW fire brigade to respond and us to evacuate the building - but it did all start when I pressed F5 to run my Entity Framework demo!

I've had my talks and presentations interrupted by a number of different things including people turning on/off lights and of course the typical joker in the crowd but never had to evacuate the building before!

Jonathan Carter and myself were at the Microsoft office in Sydney last week giving a class on .NET 3.5 SP1 features.  I had just started one of my demo applications to explain some features of Entity Framework when all of a sudden the building alarm went off.  Like most big buildings in the US, the fire brigade had to respond and clear the building before we were able to return.  Rumors are that it really wasn't my demo that caused it but low water pressure in the building! 

This week at TechEd Microsoft announced the SilverLight Beta2.  You can download the latest bits for SL2, Visual Studio and Expression blend here. 

There's lot's of great stuff in the new beta - probably my favorite is the Datagrid now supports sorting and the ability to drag and drop to re-arrange columns.

Tim Heuer has a great post on using the new Tab Control here.  He also has some good posts on Visual State Manager (here)  and Skinning controls here

Scott Guthrie has a good overall post talking about a lot of the new features here.

Ok, so I said my favorite feature was the Datagrid changes, that might be tied with the fact that Data Services client is now built in.  Big thanks to Shawn Wildermuth who helped me get my query working the first time but here's an example calling to Data Services from SilverLight. 

This example is querying against a Data Services I built using the Adventure Works LT database.  If you haven't seen Data Services - it is one of the .NET 3.5 SP1 features and allows you to expose a Data Service from a LINQ to SQL, Entity Framework or a Custom provider model.  If you have SP1 and are looking for a quick walkthrough the .NET 3.5 SP1 Enhancements training kit can be downloaded here and has a hands on lab you can walk through.  Shawn also has a much more detailed post here that you will find interesting with detailed steps.

If you have existing Beta 1 SilverLight applications the first time you open the solution after you install beta 2 you will see the following dialog prompting you to upgrade.

I've been through updating a couple of applications so far and you need to really read the Breaking Changes between Beta 1 and Beta 2.  Like most beta 1 to 2 conversions there are some hand holding you will need to do to update your code to work with the new beta.  For example, a lot of the changes are simple either name space or property name changes like EnableMultiSelect has now changed to just MultiSelect.

When you first start kicking the tires on ADO.NET Data Services you might try hitting the URL in Internet Explorer to see if it works.  In fact it's kind of interesting to try to play with the various syntax of what you can pass to see how they work.

For example, just hitting the URL of the Data Service and you will see something like the following that shows what tables are exposed.

You can drill down further by trying to get data for one of tables (or entities since I'm feeding this from an Entity Framework model). 

By adding "/Address(1)" on the URL, I indicate I want to retrieve the address with a key of 1.

You might get hung up here, because by default IE tries to read the response and thinks it should be a valid Atom or RSS feed and you will see something like the following

After you get done scratching your head trying to figure out why it says "Internet Explorer cannot display this feed"  - let me explain how to get that to work.  If you go to Tools -> Internet Options.  The select the Content tab. Near the bottom click on the Settings next to the Feeds Section

In the advanced section on that dialog, uncheck the "Turn On Feed Reading View"

Once you do that, refresh the page and you should then see the actual output from your get request and it should look like the following

If for some reason you don't want to turn that off you can also do a View Source and you can view the XML response that way as well.

There's a ton of stuff you can do with the URL for Data Services to modify what it returns.  Check out the simple Addressing Scheme here.