Want to build your own IDE?

No problem. [MS] announced Visual Studio Shell product. Just use the pieces and parts of Visual Studio, put them together and voila, there is your IDE. At least theoretically.

Anyway, this is an interesting and I would say very welcome move even for "normal" applications that support scripting or something like that (if you've ever supported scripting in your app you would know how hard is to include a proper IDE). I wonder what will be the licensing like.

And in the same post there is a notice that Orcas will be officially called Visual Studio 2008:

"That doesn't say anything about the release of VS 2008 - only that it will be released in the FY08 financial year (as the naming convention is normally managed). "

I don't know why but I have a slight suspect that it actually might happen in real, not financial, year 2008. I hope I am wrong though.

Microsoft ORM saga revealed

Matt Warren talks about what happened to ObjectSpaces, WinFS and why [MS] is going with LINQ to SQL as sole ORM product in Orcas wave. Very interesting read I have to say and kudos to Matt for such a revealing post. It actually reveals many (odd looking) decisions. They remain odd but at least one can understand the reasoning behind them.

Anyway, one piece of the puzzle is missing. He doesn't mention Entity Framework with a single word. Perhaps in next post we'll read about EF's story (hint for Matt).

My ORM presentations at NT Konferenca 2007 (Slovene event)

A year passed like nothing and NT Konferenca, biggest national [MS] event, is here again. This year I'll be all ORM oriented, in fact, I'll give two presentations on topic: LINQ to SQL and ADO.NET Entity Framework (which was recently postponed to 2008  - won't make it into Orcas).

Nedless to say that I am an ORM convert and really excited about ORM products in general. Even more now, that [MS] is LINQing the ORM products. I have deliberately written ORM products because LINQ wave will hit all ORM products, not just [MS]' ones, like Tsunami and this is soooo good - I really can't imagine an ORM product ignoring LINQ for more than three months. IOW writting ORM queries using LINQ will be much more clear, readable and concise - this is huge huge benefit for ORM community (note that using LINQ for ORM queries is just a part of where LINQ shines).

There are two things I have to figure out though:

  • why the heck is [MS] going with two very overlapped ORM products instead of focusing on one and make it great.
  • how to explain to DBAs that ORM product is not a public enemy and a threat to them, at least not when used properly

So, see you there!

Inserting records containing timestamp columns in ADO.NET Entity Framework

In case you are playing with ADO.NET Entity Framework you might have seen that, by default, when you have timestamp columns in a new entity they are being inserted into the database when inserting and saving new entity. This behavior isn't a correct one, since timestamps are server generated, and one gets a clear exception from SQL Server saying:

Cannot insert an explicit value into a timestamp column. Use INSERT with a column list to exclude the timestamp column, or insert a DEFAULT into the timestamp column.

This isn't a bug in Entity Framework or something. It is rather a bug in EDW that doesn't create correct definitions. The fix is rather simple:

  • open [yourefdefinition].ssdl file (formal description of the database)
  • find your timestamp columns, i.e.
  • <Property Name="COLUMNNAME" Type="timestamp" Nullable="false" />
  • add the attribute StoreGeneratedPattern="computed" to each such column, i.e:
  • <Property Name="COLUMNNAME" Type="timestamp" Nullable="false" StoreGeneratedPattern="computed" />

That's it. Make sure you rebuild your code, otherwise updated ssdl file won't be copied to target folder* and application will load the old one.

More on the subject in this thread.

* Note: if you only change non compilable files (such as .ssdl and .msl ones but not .csdl - the later will invoke EntityModelCodeGenerator custom tool that will regenerate entity types and ObjectContext derived class that represents your database and thus force a rebuild) and re-run the application, IDE will know that your application files (compilable ones) weren't modified and it won't re-build the application - it will just run the application. As a collateral effect the modified files won't be copied to target folder and your application will use the older ones.

Say bye to ADO.NET Entity Framework in Orcas/.NET 3.5 RTM

As many reported (including me), ADO.NET team decided to postpone the EDM designer after Orcas/.NET 3.5 RTM. With this move they basically frozen the use of EF in real applications (wizard is very limited, typing all that XML is not really an option) until EDM sees the light of the day.

Now it is getting even worse. They decided to postpone entire EF for the time being mentioning H1/2008 as a tentative release date. It is amazing to see a huge company, full of money, full of very talented people, like [MS] that can't create an ORM in years (remember ObjectSpaces?). Whether this is politics or misjudgment or something other is hard to know for sure, however, they certainly aren't lacking the resources, are they.

So, what do you do in the meantime? Either start playing with LINQ to SQL or go with LLBLGenPro a proven, reliable, powerful, excellent ORM solution that is ready to use right now.

Starting with ADO.NET Entity Framework in Orcas beta 1

Orcas is bringing two similar but different LINQed ORM approaches: LINQ to SQL and Entity Framework/LINQ to Entities. I thought that it is about time to try out the later, so I created a new project and fired up Entity Data Model (EDM) Wizard (the only way to avoid typing all that XML definitions for now*). The result was a bunch of empty xml and code files. Oops. Fortunately I was aware that a EDM wizard hot fix is out. Once the fix is installed, I re-run the wizard, picked a couple of tables from a Northwind database and finished the process. This time the definition and code files were generated just fine. At least I thought so. Next step is to create an instance of strong typed ObjectContext, like this:

NorthwindEntities db = new NorthwindEntities();

Yet, I got a "At least one of the input paths does not exist." exception each time I've tried to run that simple piece of code that is supposed to run without problems. Hm. My first thoughts were that strong typed NorthwindEntities ObjectContext class is passing wrong arguments to supertype ObjectContext constructor. After a couple of tests I saw that the arguments were correct. So, what is wrong. The answer is, of course, in exception message. I think it is saying that some types are missing or something like that. I correlated this fact to the selection of only a couple of tables in wizard instead of selecting all of them. So I re-run the wizard once more, this time selecting all tables. This time it worked smoothly - seems like the third iteration is the good one.

The bottom line is that if you want to play with Entity Framework you have to:

  • Install EDM Wizard hot fix
  • Always include all tables (or modify entity model definitions, mappings, etc by hand)
  • or type XML like mad

* ADO.NET team has a video of an EDM designer prototype which looks really cool. But, what really sucks is the sentence "that we can expect to see released after the upcoming Orcas release". Yes, you've read it right. No EDM designer for Orcas release. This is like having to assembly a (fast sports) personally car before driving it. On the bright side though: your XML and typewriting skills will have opportunity to shine.