It seems the latest dotnet ef tools (v3.1.3) documentation on Microsoft's site list having the following parameters for dbcontext scaffolding:
-n or --namespace to specify the default namespace of all generated classes
--context-namespace to specify the namespace of the generated DbContext file
However, when I attempt to add those commands to my dotnet-ef command, it says they are not known commands. And I am using Oracle EFF which only works with Core 2.1 so I'm wondering if that is the issue as well?
Here is the version I'm using:
We like to keep the DbContext file separate from the generated PODO classes so the only work around we have is to generate all the classes in the project namespace where the PODO's will reside, then move the generated DbContext class file to a different project and change the namespace.
It's very strange that Microsoft's documents point out the two options exist, but when I check on my machine running the latest .NET Core 3.1 SDK and have the 3.1.3 Command Line tools installed, it's not there.
Is this something that works with possibly EFF6 only? We're trying to build any new apps using .NET Core as we are moving towards container services such as Docker and Kubernetes at my work.
Thanks!
It looks like you need to use 5.0.0 of the dotnet-ef tool to use these options, which is currently in preview. I ran this command to update to a pre-release version and I'm now able to use them.
dotnet tool update --global dotnet-ef --version 5.0.0-preview.4.20220.10
You'll also need to use version 5.0.0 of the EF packages in your project.
You can see all versions of the donet-ef tool here:
https://www.nuget.org/packages/dotnet-ef/
The commit that added support for these flags:
https://github.com/dotnet/efcore/commit/922a7709c4d5d5cf1b9a9b258623c8ef57baebfe#diff-b63a8c6540910fa14bd75aaf248e900d
Related
Is there a Linux equivalent of LightIngest.exe? The page of the utility does not mention that, search brings no luck either. In case it is not available, what is the preferred way to post ingestion items through CLI in Linux?
There is a .NET Core Kusto.Tools package - it is currently built for Core 2.1 and we will be working on updating it in the coming weeks.
https://www.nuget.org/packages/Microsoft.Azure.Kusto.Tools.NETCore/
Thanks to Vladik's answer I was able to download the package and use the included LightIngest.dll to execute an ingest through my Mac. Here are the steps:
Use nuget to download the Microsoft.Azure.Kusto.Tools.NETCore package installed:
nuget install Microsoft.Azure.Kusto.Tools.NETCore -Source nuget.org -OutputDirectory SPECIFY_OUTPUT_DIRECTORY
Navigate to the directory, and go to the tools subfolder. There you should find LightIngest.dll
Assuming you have dotnet installed (CLI) and SDK (v2.1) you should be able to execute an ingestion:
dotnet ./LightIngest.dll ...
Replace the ... with the Windows equivalent command that Azure Data Explorer Ingestion wizard suggested, and it should start ingesting!
I have this situation:
I have a Class library with a target framework set to net6.0-windows
<TargetFramework>net6.0-windows</TargetFramework>
And then I have added a new CLI application which I want to build, pack and install as a global CLI app, which has:
<TargetFramework>net6.0</TargetFramework>
Normally I would change the class library to net6.0, but when I do it - the build says that -windows parameter is mandatory for this kind of project. On top of that, there are other projects in net6.0-windows that need to be set as they are.
I have tried to switch CLI to net6.0-windows, but 'dotnet pack' says - that -windows is not supported.
I also tried to use multi-platform target:
<TargetFrameworks>net6.0;net6.0-windows</TargetFrameworks>
But then dotnet pack says:
C:\Program Files\dotnet\sdk\6.0.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.PackTool.targets(95,5): error NETSDK1146: PackAsTool does not support TargetPlatformIdentifier being set. For example, TargetFramework cannot be net5.0-windows, only net5.0. PackAsTool also does not support UseWPF or UseWindowsForms when targeting .NET 5 and higher.
Any solution how to access classes from DLL - within my CLI? Is this even the correct approach?
I use scss in my project and want to use bootstrap.scss so I can define a single class inheriting multiple bootstrap classes e.g.
.myButtonClass { #col-xs-12; #col-sm-6 }
So I can replace class="col-xs-12 col-sm-6" with class="myButtonClass" as I have many buttons that need to be the same. I have installed the yarn extension in VS2017 and can see the Restore Packages (yarn) in my GUI, but yarn is not found in the VS command prompt. So I cannot install the bootstrap scss package.
This is a .Net Framework WebAPI project, not node.js project. There seems to be no examples of how to use js packages in a vanilla .Net Framework WebAPI project.
Or is it simply that I cannot use these style of JS packages?
If you want to use npm on Windows, this is what you need:
Download and install Node (you might need a restart).
Make sure that node is installed by opening a command prompt and running node -v (should print a version number).
Run npm -v and see if it's installed (should be).
Now in the context of an ASP.NET MVC project. The newer versions of Visual Studio (I believe 2017) support npm - you can just open the package.json and add dependencies (it will download them behind the scenes).
In case you're using an old version, you can simply open a command prompt, navigate to your project and use npm install from there.
Simply run npm install bootstrap-scss#4.3.1
I am trying to run a simple GRPC client-server code in raspberri Pi running Raspbian os.
Language that i am using -C# dotnet core (2.1)
I downloaded a sample project from here.
This is a dotnet core project . I am able to run it in Windows environment, i am also able to modify .proto file in this code and run successfully.
I published the solution as it is with command
{ dotnet publish -r linux-arm }
When tried running same on Rpi, i am getting exception. Attached screenshot has the details of it.
Any help to get through this would be of great use
tl;dr The problem is the libgrpc_csharp_ext native library which currently does not get compiled and built for the arm7 processor. I've compiled it (on a pi) for arm7 and released a nuget package to bridge the gap until they support it all the way: https://www.nuget.org/packages/libgrpc_csharp_ext.arm7/
I'll update with a link to a blog post when I finish getting the rest of the tooling and template finished I'm working on.
fuller explanation: the Grpc.Core nuget package contains the native libgrpc_csharp_ext library that the dotnet implementation of grpc loads in NativeExtensions.cs then maps with PInvoke in NativeMethods.Generated.cs. Inspecting that package, you'll see a version of that library in each /runtimes/[win, osx, linux]/native folder. Unfortunately, no linux-arm version of the library is included. However, in the code, if the platform is linux, it will try to load the static library using the name as formatted here. Dissect that a little and you'll see that as of right now, any 'linux' platform that isn't '64bit' (which despite the proc on the pi being 64 bit, the distro of linux you're using on there, including raspbian, likely isn't) will look for libgrpc_csharp_ext.x86.so. When you dotnet publish -r linux-arm, you'll see that library there in the build output, but unfortunately, it's the wrong one (I think publish just grabs 'the closest one' when it can't find a specific library in the runtimes folder).
The nuget package I created above is compiled for arm7 - I actually cloned the grpc repo onto a pi and peeled away enough of the /csharp build to just cmake the libgrpc_csharp_ext. The 'trick' the package uses is to put the library in runtimes/linux-arm/native folder within the package, which dotnet core recognizes when publishing and pulls into the build output - but the library is still named libgrpc_csharp_ext.x86.so because of the way NativeMethods.cs formats the library name.
Recently, I created an asp.net core project using Visual Studio Code on Windows and pushed it to GitHub. When I cloned the repo from GitHub and attempted to do a dotnet restore on the project on Ubuntu, an error message stating there was no project.json file was returned. Can anyone point me to a resource that will show me how to properly restore a .net core project from a Linux machine? Thanks!
So it seems like on each of your machines you are running different versions of the .net core SDK.
A big caveat with what you are trying to do. Are you trying to use Project Rider from Jetbrains on Linux? This only works with project.json (As of the time of this post) so be wary of that.
Now there are two ways to do this. If you are wanting the very latest on Linux and don't care about using Rider, then you can go here : https://github.com/dotnet/core/blob/master/release-notes/download-archive.md and download the latest release for both Linux and Windows, install on both and you should be good to go.
If you do care about using Rider or you aren't ready to be strapped in for the wild ride of the latest release. Then you can do the following.
Find what version of the SDK you have on linux by typing into a terminal the following :
dotnet --version
This will spit out what version you have on linux. Go here and download the same version for windows and install it on your windows machine (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md).
Now BEFORE you create a project, create a solution folder and create a file in it called global.json. Inside that put the following :
"sdk": {
"version": "1.0.0-preview2-003131"
}
Where the SDK version matches what you got from your linux terminal. Now create a folder for your project inside the solution folder. Run "dotnet new -t web" or a similar command to create your project. It will inspect the SDK version of the global.json and create a project with the tooling that matches. You should then be able to shift this project around any machine that has the same SDK installed, even if it also has the latest SDK's also.
If you do not create the global.json, it defaults to the latest version (Atleast on Windows).
Read a bit more about it here : http://dotnetcoretutorials.com/2017/02/17/developing-two-versions-net-core-sdk-side-side/