How does the ADO.NET Entity Designer generate code?

Entity Framework Links...

Mike Taulty's Blog — Fri, 25 Jan 2008 12:36:24 GMT

Entity Framework Toolkits & Extras How Does The Entity Designer Generate Code? How To Extract CSDL...

ADO.NET Entity Designer & developer productivity

Marcelo's WebLog — Fri, 25 Jan 2008 22:05:06 GMT

I admit it - sometimes I fall in love very hard with some of my tools. Tools that make me productive.

Customizing Code Generation in the ADO.NET Entity Designer

ADO.NET team blog — Sat, 26 Jan 2008 00:22:24 GMT

In previous posts, I’ve described CSDL annotations , how to extract CSDL from EDMX and introduced you

re: How does the ADO.NET Entity Designer generate code?

BjartN — Thu, 14 Feb 2008 15:17:01 GMT

When can we expect full oracle support in the entity designer like creating entities directly from the oracle database the way we can with mssql databases.

re: How does the ADO.NET Entity Designer generate code?

dcazzulino — Mon, 12 May 2008 18:57:24 GMT

Using SingleFileGenerators is bad for continuous integration and automated build processes.

WPF and XML (i.e. Linq to XSD) teams are moving away from them and switching to custom compile actions and MSBuild tasks, which integrates much better with a build process.

How would you integrate this with the build process?

קימפול קוד 3.0 #C תכנותית באמצעות CSharpCodeProvider

Ido Flatow — Fri, 20 Jun 2008 14:11:06 GMT

כפי שאתם יודעים, אחד מהחידושים של C# 3.0 הוא Partial Method שמאפשר לנו לכתוב מתודות Partial ולממשן (או

re: How does the ADO.NET Entity Designer generate code?

Mihai — Fri, 27 Feb 2009 17:12:19 GMT

@dcazzulino: I suppose you don't. The promise of the generator is that it automates certain tasks upstream of the build system.

It's reasonable to assume that the team members are smart enough to build the solution (if not run a unit test, or integration test, in the case of EDMX) before pushing any changes into the source control system. In other words, before the integration build takes a look at it.

That said, I do see the value of having the integration build as a last line of defense.

Custom build actions are a terrible choice, and although we're far from seeing .NET fulfill the promise of write once, run anywhere, it should be clear that the presence of any Windows-specific post-build action indicates a procedural smell. Custom build actions tie you right back into Windows crap.

As far as MSBuild tasks, if Visual Studio makes it easy to work with such custom tasks, then it sounds like a good idea. Otherwise... well, I'll take the SingleFileGenerator.