Hello folks – just a quick post!
I finally found the time to publish a workaround I wrote back in May this year. I was hacking a fully automatic irrigation system (garden stuff you know ^^) and because I had to do that really quickly (before leaving for vacation) I decided go the route of a known framework: OWIN, ASP.NET WebAPI 2, NOWIN (as a host), Identity 2.0, EntityFramework, MariaDB, a good HTML5 stack… etc…
Well mostly a known framework; I had to run on a Raspberry and Microsoft wasn’t quite as ready with Windows 10 IoT as I’d needed it… So it was a quick decision to stick with Raspbian and Mono. Which by the way work out great. At the time of writing my little application has over 140 days of uptime! – Yay –
I’ll probably write more about the whole project in the next months!
Anyhow I faced the problem that the MySQL Connector/NET is *still* (I posted the bug on November 7th 2014 – Bug Ticket: #74726 EF migrations fail on long foreign keys) having issues with code first migrations, long entity names and foreign keys… and as I really lost any confidence that ****** is going to fix that any-time soon I decided to do it on my own…
So for those of you facing issues like failing code first migrations when they do anything with entity relations (renaming a foreign key property or dropping a constraint for example). Or if you’ve always wondered how the code generation can come up with stupid foreign key index names like 77963b7a931377ad4ab5ad6a9cd718aa (⇐ random string), well then give this a try:
For more details just have a look at the sources: Pysco68.MySQL.FixedMigrationsGenerator at Github
