Over the year’s lots of stored procedures, functions, views and many other “Custom” assets have been added to the database, making it way to much of a huge undertaking to model all of this stuff using plain old EFCore. On top of that, there’s a huge number of custom tables, that where not originally part of the Dot Net Nuke install, but where added by the original 3rd party company to DNN’s database to support the extra functionality they added to the system. I’m currently re-writing an old Dot Net Nuke v4 application, from round about 2008 on-wards.Īs part of the system, there is a huge SQL server database, that not only has the Dot Net Nuke tables and data in them, but also shares server space with databases from Great Plains and Microsoft Dynamics. Take for example, the project I’m currently working on. The thing is though, SQL server projects are actually still quite handy for some scenarios, even if they have largely fallen out of favor these days. In fact many newer devs who are only used to dotnet core might never have even seen the project type that I’m on about

In this world of EFCore and migrations support that we have now, it’s hard to remember that at one time the primary means of performing SQL server database builds and changes was to use an “SQL Server” project type in visual studio.

Visual studio 2017 sql server project