Enum properties not generated by default T4 template

Feb 19, 2013 at 10:52 AM
Hi,

I'm trying to convert some Int16 lookup values to enums as now supported by EF5.

However, when I use the model/database first Default T4 Template to generate the entity classes, the enum type properties are not transformed, i.e. they don't show up in the resulting class at all. If I change the enum properties back to Int16 they are again correctly transformed as before.

In my endeavours to find out why, I've noticed that there are a number of differences between the default transformation template automatically added when creating the edmx and the one I'm using which is available in the Naked Objects section under Add New Item... Particularly, the NOF one does not seem to cater for enums.

This leads me to think that I'm possibly using a prior version of the template. Currently it is the NuGet installed v5.1.0 of NOF.

So my questions are:
  1. Should the latest version of the NOF Default T4 Template generate the enum properties?
  2. How do I make sure that I have the latest version of the template?
  3. If not the above, what else could be possible causes for the enum properties not being created correctly?
Any help will be appreciated.

Thanks,
Etienne.
Coordinator
Feb 19, 2013 at 11:06 AM
From a quick glance, it looks to me (our) NOF Default T4 Template needs to be updated to cope with EF5 - Enums in particular. I'll raise a ticket for this to be looked at.

In the meantime, you could look at Microsoft's template and find the bit that deals with Enums and see if you can merge it into the NOF one.

(Note: they do need to be different.)

All that said, I infer from this that you are working with .edmx. I would encourage you to switch to using Code First if you can - this is taking over from the .edmx approach. N.B. You can still work in the 'code first' mode starting from an existing database.
Feb 19, 2013 at 11:15 AM
Hi Richard.
Etienne is working on our team.
All that said, I infer from this that you are working with .edmx. I would encourage you to switch to using Code First if you can - this is taking over from the .edmx approach. N.B. You can still work in the 'code first' mode starting from an existing database.
Do you have a feel for what would be involved changing over on a project that already has over a hundred entities? Would there be a lot of manual massaging to fit into code first with our existing project?
Coordinator
Feb 19, 2013 at 11:25 AM
It can be quite a lot of work yes - we have made the same change on multiple projects in Ireland. That said, the amount of effort depends in large part on how much you did in the .edmx file in the first place.

For example if you have class Foo with a property Bar, corresponding to a table Foo (or Foos) and column Bar, then you are not going to need to add fluent mappings for that because the conventions will work fine. But if your .edmx was being used to map class Foo to table 'foo' and column 'bar_string' - then those mappings will need to be mapped in code either using attributes or (my strong preference) the 'fluent api'.

There are tools that can help. Microsoft has an EF powertool that can create both entity classes and fluent mappings from an existing database. The latest NOF Ide has some templates that can be used in conjunction with this (documented in the Developer Manual).

There is also a third party tool that can supposedly transform a .edmx into code first fluent mappings - but I did not get it working successfully.
Feb 19, 2013 at 11:35 AM
Ok thanx.
Our model is pretty clean. We keep it as close to the DB as we can. There are a few entity renames, but mainly the only change is some inheritance on a couple of entities and lots of renames of navigation properties. Eg. User1 to ApprovedByUser, etc.
There are tools that can help. Microsoft has an EF powertool that can create both entity classes and fluent mappings from an existing database. The latest NOF Ide has some templates that can be used in conjunction with this (documented in the Developer Manual).
Our workflow is such that we always script changes to the DB first, adding columns, FK relationships etc. Do the above tools cope with these incremental changes as the current edmx Update Model From Database does?
Coordinator
Feb 19, 2013 at 2:23 PM
Not sure - I recommend you look that up on the Microsoft site(s).
Apr 7, 2013 at 2:59 PM
Hi guys. Back to the original question about enums.
Did an update to the NOF template for EF make it into the latest release 5.4.0?
If not, is it planned?

Thank you much.
Coordinator
Apr 8, 2013 at 8:12 AM
No, it wasn't done, and isn't currently scheduled. You might like to have a go at it yourself and share the fix. Good luck - T4 Templates is one of my least favourite technologies ever :-(
Apr 8, 2013 at 9:00 AM
Thanks for the feedback. I'll share if we get to it.
May 28, 2013 at 9:58 AM
I'm looking into this. I'm wondering whether it won't be easier to start from the default MS EF tt template.
Besides MemberOrder attributes etc. why else was the custom NOF tt file developed?
Coordinator
May 28, 2013 at 10:13 AM
Edited May 28, 2013 at 10:14 AM
Long time ago, so I don't recall exactly. There was the addition of the attributes certainly. Another thing is that all properties have to be virtual (I don't think that was the case on the MS one). Some cosmetic (styling) preferences.

Not much more that I can remember. Note: in much earlier versions of Naked Objects there was a bigger difference - when it first worked with EF you did have to inherit from a base class, and properties all had to call Container.Resolve() and ObjectChanged(). Thank goodness that's all gone.

The thing to do is to try using the standard MS template, in parallel with the NO template, and just compare the two generated classes.
May 28, 2013 at 10:27 AM
Perfect. Will do that.
thank you much.
May 28, 2013 at 2:07 PM
Edited May 28, 2013 at 2:07 PM
Ok. I think I've managed. All my tests pass and UI is functional.

There were a few changes required to the MS version.
1) non-collection navigation properties had to also be made virtual
2) collection properties needed a backing member variable, else initializing them broke because of dynamic proxies.

I did not bother with the MemberOrder attributes, as I always want to customize those anyway.
But now this should support EF Enums.
Model.tt
Coordinator
May 28, 2013 at 2:15 PM
Thanks for sharing the result. I'm not really sure what would be the legal status is of us including a slightly-modified version of the MS template in our own distribution - but I'll make various pointers to your posting, so others can follow suit. Most of our newer users are working Code First now, anyhow.
May 28, 2013 at 2:39 PM
Perfect
May 28, 2013 at 10:52 PM
Just some more feedback.
EF 5 enums support is now working perfectly with the new template.
Finally we can now reference externally defined enums, allowing us to drop our static lookup entities from our model and simplifying our interface associations between models.
Jun 7, 2013 at 10:15 AM
Model.tt
For anybody interested, I have cleaned up the template a bit and also added the generation of StringLength attributes as per the NOF template.