19 hours ago, cbae wrote
If the client application doesn't need these properties, they probably should be private to begin with.
The client applications does need them. But I am not allowed to expose them via OData because they are DateTime columns.
Otherwise, you can make them DateTimeOffset in .NET and map them to datetime in SQL Server. You can manage the data type mapping through the Entity Data Model designer or in code using the fluent API if you're using Code First.
As I said, the only way to do this (and preserve your naming) is to manually edit the Entity Data Model (CSDL) file.
If you're using the Entity Data Model designer having to make manual tweaks is already unavoidable if you're mapping table columns to enums.
Enums? Who said anything about enums?
At some point, just deleting all of the entities and re-adding them to reflect the changes to the database is not a viable solution to synchronizing the entity data model with your database.
Sometimes delete and re-add is the only way to fix problems with Entity Framework data models. Still, I don't delete everything and re-add. I just do this to the affected tables/entities.
Another thing you can do is to create a script that uses the API provided by the System.Data.Entity.Design namespace to automatically change the .NET type of any SQL Server datetime columns to DateTimeOffset in your EDMX file. As far as I can tell, a SQL Server datetime column implicitly converts to .NET DateTimeOffset, and a .NET DateTimeOffset implicitly converts to SQL Server datetime. So there's no need to add any special code like that in the StackOverflow page that you link.
I tried just changing the type (I hoped there was an implicit conversion too). But when I tried to run it, I got a type mismatch error.
Basically, it can't be done without a manual edit to the CSDL or changing your column/property names.