Using a fully updated VS 2019 (Community) and Elements 10.0.0.2485
Create new project using “ASP.NET Core API” template
NOTE: There is no packages.config in the project at this point.
Tools -> Manage NuGet packages for Solution and install Microsoft.EntityFrameworkCore 3.1.3
After accepting the license(s), package installation (eventually) fails with error:
The specified path, file name, or both are too long. The fully qualified
file name must be less than 260 characters, and the directory name
must be less than 248 characters.
This appears to be the result of some strange behaviour during the package installation process whereby as each package is added to satisfy the dependencies of EF Core, a copy is made of packages.config (although there is no original, actual file called packages.config) each of which are added to the project, with the filename extending in each instance presumably to ensure uniqueness:
In an effort to prevent this behaviour before trying again, I deleted all but the latest copy of packages.config (i.e. I kept the one with the longest file name). I then renamed this to simply packages.config and tried to use “Migrate to PackageReference”.
Proceeding with the packages.config from step 3 and again installed EntityFrameworkCore 3.1.3, this was successful, without creating further copies of packages.config, but updating the one that was now present.
However, then trying to install EntityFrameworkCore.SqlServer failed with a different error:
Is it possible to create a ASP.NET Core web Api application that uses EF Core with Oxygene ? What am I doing wrong here ?
Note: following the exact same, basic steps (new project, install packages EFCore and EFCoreSqlServer) “just works” (without creating a packages.config) using both VS2019 and JetBrains Rider (Microsoft C# projects, obviously).
I believe this is a known issue that’s either fixed post 2485 (which is a few weeks old), or about to be fixed; I’ll check with the VS team which it is, but can I recommend you try ./2505? In either case, it is/was an issue specific to VS.
No worries. Unfortunately I’m not getting very far. So far with a new project (as above) the Manage Nuget Packages for Solution menu item is disabled (along with all items on the Tools -> Nuget menu) and Manage Nuget Packages from the References context menu doesn’t do anything.
Supplemental Q: Since this is a .NET Core template, why is .NET Framework version part of the New Project settings and why doesn’t it include .NET Core versions, only Framework ? (this was the case with .2485 as well). Can I safely ignore this as not applicable to this project type ?
That’s not the way to do this. The problem is that with that you bring back Visual Studio’s own managing if NuGet packages, which messes with how we do them. I’ll ask my colleague to explain more, and what the current state of this fix is (it might be just fixed partially and some old UI is still present.enabled that a should no be used).
As it should ben; this is not what you should be using for an Elements project.
You can, yes. As far as I understand , VS just shows this popuop for every project (even, say, a Cocoa or Android one), and we can’t hide that (can we, @viktoriad?). it has no effect.
Update: for now, it’ll be best to use Water if you need to add/manage package references. You can then goo back to VS to work (if you’re missing the pain ;), and the project should build there, fine.
It’s just that we’re in the middle of fixing the NuGet support for VS form old to new, and the current build has that work stuck in an intermediate place where neither works anymore/yet, if that makes sense.
Cool, thanks Mark. I can work like that for the time being.
I understand (I think) your antipathy to VS, but honestly as good an achievement as Fire and Water are, they still have a long way to go before it could realistically replace VS, for me. Just on the basics like being able to use the editor font I prefer at a size and in a color theme that works on my displays for my eyesight.
And it has to be said that Package Management is one of the experiences that is vastly superior in VS. e.g. having to constantly “Obtain all known versions” to get latest versions, even if the version installed is later than the currently latest, ‘known’ version (choosing “*” doesn’t work - that only gets me the latest version known to Water).
Apart from anything else, I am not in the fortunate position of being able to work exclusively in Elements, and VS is a major part of my toolkit, so yes familiarity and consistency is a factor, but those are still important factors in productivity.
And from a marketabilty point of view, whenever I get into conversation with people about Elements, the ability to continue to use familiar tools is a key selling point (in terms of maintaining their interest, not necessarily making an actual sale at that point ).
For these and other reasons I really do hope that VS support continues.
:
