Words are amazing….and I get easily distracted. While writing this blog I used an acronym which I felt that I should quantify in case my readership is not aware of its meaning; The acronym in question was POCO and in this context it means ‘Plain Old CLR Object’ or ‘Plain Old C# Object’ ; This usage is used mostly in terms of describing a data object and is used to denote that a plain object with only properties, no logic, is used to directly represent the database data. Whilst providing a link to act as my dictionary for this acronym I was pleased to find that in many European languages the word Poco actually means ‘A little, not much’. This beautifully mirrors the intention and usage behind POCO in programming and also allows me to add a little bit of colour to what would otherwise have been a frightfully dull, and very specific blog. If you require only colour in your life, now is the point at which you can stop reading.
For those who have remained this blog actually originates out of a .NET Course that I was recently teaching; I was taking the client through code first development (using mocking initially) and then how to use the in built .NET Entity Framework migration tools to create your physical database from your POCO’s.
Normally this happens without issue, you goto your package manager console and just type in
add-migration IntialMigrationIt’s really that simple, a little bit of thinking and it starts the process and then after a little flurry of activity your script is created and displayed within Visual Studio. However, as is the curse of every live event nothing ever goes to plan… One of the ‘students’ instead received the following error message:-
The specified deps.json […] does not existAfter resorting to the internet we drew up a big fat blank, lots of reasons why but none of them worked in this situation. We did however manage to solve this issue in the end. For us the issue seemed to be related to how the project had been opened in the first instance; The code resided on a network server and the code had been opened by using a UNC path. In our case the issue was easily remedied by the following steps:-
- Closing Visual Studio
- Removing all obj and bin folders from the project(s)
- Opening the project using a Drive based path instead. So instead of opening “//MyServer/Path/MySolution.sln” we used the path “H:/Path/MySolution.sln”
- Performed a rebuild
- Run the add-migration command as before.
I’m not saying this will work in 100% of cases, however… it may assist someone. This is precisely why I blog, without all of those past bloggers out there, my job day by day over the last 25 years would have been impossibly hard. Its nice to give back.