There are many people that have asked this question before on SO. For the last 3 hours I have sequentially tried each solution, and I get the same No executable found matching command "dotnet-ef" each time. I'd like to understand how to run the command and have it actually execute.
But first a little background:
I am learning how to use ASP.Net Core 1.1 MVC and Entity Framework Core. It is a Microsoft tutorial that can be found here.
The completed tutorial can be downloaded from git, as instructed. Performing these steps I open the download project and follow the steps in the readme.md file in the project root folder. It states the following:
After downloading the project, create the database by entering dotnet
ef database update at a command-line prompt
Which I attempted. I used visual studio developer command prompt (as admin) and first change directory to the project root, where the appsettings.json and *.csproj file are located. I then typed in the following:
C:\Users\username\Downloads\Docs-master\aspnetcore\data\ef-mvc\intro\samples\cu-final>dotnet ef database update
No executable found matching command "dotnet-ef"
According to the tutorial, this should "work" as-is.
What is strange to me is that if I run the following command I get output, which indicates to me that dotnet.exe is working.
C:\Users\username\Downloads\Docs-master\aspnetcore\data\ef-mvc\intro\samples\cu-final>dotnet
--version
1.0.4
I am using Windows 10 and Visual Studio 2017 CE Version 15.2. I have both the ASP.NET and web development and .Net Core cross-platform development workloads installed.
I am also using .Net Framework Version 4.6.01586.
Make sure you restore first so that the ef tools become available:
Execute dotnet restore and wait for it to restore successfully, then execute dotnet ef database update.
Microsoft.EntityFrameworkCore.Tools.DotNet needs to be added to your project. Right click the project and select Edit *.csproj. Then, add the following:
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.0-preview2-final" />
</ItemGroup>
Note: the version is the latest at the time of this post and will likely change in the future.
These tools can only be added by editing the .proj directly at this time.
The easiest way it run commands is to right click the project and Open Folder in File Explorer. Then, type cmd in the address bar of the File Explorer to open a command prompt in that folder. Now use the following command to create the initial migration:
dotnet ef migrations add InitialCreate
Related
On a Windows machine there is a GitLab-Runner run from a domain user with admin rights. When I log as this user and call dotnet build -c release to build an ASP.NET Core app, the dll has all the information from the AssemblyInfo.cs file. When I do the same as part of a CI job, the produced dll is missing all this information (for example the version number).
The AssemblyInfo.cs file is not part of the repository, instead, it is produced by a prebuild event (using gitWCRev.exe tool). However after running some tests I can see that the AssemblyInfo.cs is actually generated when the job is run by the runner.
Any help as to why the file is ignored and how to overcome this issue would be appreciated.
At first I thought that this might be related to Pre-build task of Visual Studio project fails in GitLab Runner issue, but I don't get any build errors.
On the same machine, I build a .Net Framework app which has the same AssemblyInfo setup, but is compiled using msbuild /property:Configuration=Release by the runner and the produced dll file has all the expected information.
It turns out the problem was partially related to the AssemblyInfo.cs file not being part of the repository.
SDK-style csproj normally don't list the files in the project, but figure them out based on the folder contents. When dotnet build was run, AssemblyInfo.cs wasn't present in the project directory (GitLab-Runner usually clears out files not present in the repository before starting a job/pipeline), so build tools had no idea they needed to load it. It made no difference that the file was being created by the build tools.
The solution proved to be creating an empty AssemblyInfo.cs file before running dotnet build. This way build tools knew they needed to compile it. Actual compilation still happened after prebuild events, so all the needed information was there.
I created the empty AssemblyInfo.cs file using PowerShell:
New-Item -Path "Properties/AssemblyInfo.cs" -ItemType File
Also, checking the build logs helped me finally figure it out. To get the build logs I've called build tools like this:
dotnet build -c release /flp:v=diag
The .Net Framework app didn't have this problem because it wasn't an SDK-style project. All the files needed for compilation were listed in the project file and build tools knew to load them, even if they were created during the prebuild event.
I upgraded Visual Studio Community to the final release, and it stopped working. Specifically, I could generate a new project, but when I try to load it, it gave me an error
Critical Project 'SdkTest' load failed| [MSB4236] The SDK 'Microsoft.NET.Sdk.Web' specified could not be found. ...\SdkTest.csproj
Even though build and run worked fine
I ran "repair" on VS2022, and it seems to be working now from Visual Studio. However, dotnet --info doesn't show any SDKs; only runtime; and dotnet build or dotnet new give an error:
C:\Code>dotnet new console -o myapp
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
* You intended to execute a .NET program:
The application 'new' does not exist.
* You intended to execute a .NET SDK command:
It was not possible to find any installed .NET SDKs.
Install a .NET SDK from:
https://aka.ms/dotnet-download
I even reinstalled .NET 6 and I see it in the list of applications (along with older SDKs). I checked the path, and I see everything that I expect to see:
C:\Program Files (x86)\dotnet\
C:\Program Files\dotnet\
C:\Users\me\.dotnet\tools
I am running Windows 11.
It's known bug in VS2022 installation.
Problem is that dotnet you access is located inside Program Files(x86)/dotnet, but all sdk's are located in Program Files/dotnet. You simply need to edit PATH environment variable so Program Files/dotnet goes before Program Files(x86)/dotnet. If you don't see Program Files(x86)/dotnet in user environment variable (which is likely to happen) then edit system environment variable (located below)
Example with screenshots: https://stackoverflow.com/a/44272417/10339675
I am working on an ASP.NET Web API 2 project with .NET target framework 4.6.1. I am trying to setup github workflow for my repo. When the dotnet restore command is run, it throws an error like below.
I am getting the same error if I run the same command in from command prompt inside my project. Also if I run dotnet build, it shows below error.
The project builds fine from Visual Studio but not working from command line or github workflow yml. Can anyone please point me on what am I missing?
The project builds fine from Visual Studio but not working from command line
Check which sln file Visual Studio is using to build your project.
Since I don't see any sln/csproj in your GitHub repository, it is also possible that you have a .gitignore which would prevent adding those in the first place.
DOTNET Restore does not support pacakges.config https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-restore
So you have to move the nuget package references to csproj file itself
Here is a great comment on how to do that https://stackoverflow.com/a/65701746/8318698
Note: check that if multiple projectGuid is there on csproj at the end of the steps
After that you will be able to use dotnet restore without a hitch.
I want to know the exact dotnet cli commands that Visual Studio uses when I Build/Rebuild and Clean solution in my dotnet core application?
I know that the dotnet core cli was build on top of msbuild so when you run Build/Rebuild or Clean Solution Visual Studio uses
msbuild commands directly and not the ones from dotnet core cli?
Is that correct?
If this is correct I would like to know which msbuild command or commands it uses with the three actions:
Build Solution
Rebuild Solution
Clean Solution
And which dotnet core cli commands would be equivalent to that?
I know from this post(Relationship between the dotnet cli and the new vs2017 msbuild)
that the following commands do the build, rebuild and clean in dotnet and msbuild.
Dotnet cli:
Build: dotnet build
Rebuild: dotnet build --no-incremental
Clean: dotnet clean
Msbuild:
Build: msbuild /t:build
Rebuild: msbuild /t:rebuild
Clean: msbuild /t:clean
I guess this is not all? This is fine but I would like to see what Visual Studio produces for the actions?
And I am wondering if Visual Studio behavior can be changed so it runs dotnet cli commands instead of msbuid?
Research:
I was building a asp.net core web api project in Visual Studio(Visual Studio 2017 Enterprise Version 15.9.11)
I was looking in Visual Studio Output when I Build/Rebuild and Clean the solution but I could not find anything related to
dotnet core cli or msbuild. Then I went to VisualStudio Tools/Option/"Project and Solution"/"Build and Run" and changed the options:
MSBuild project build output verbosity: tried both "Detailed" and "Diagnostics" options
MSBuild project build log file verbosity: tried both "Detailed" and "Diagnostics" options
The outcome was that the log that was produced in the Output window of Visual Studio was huge and it was difficult to find
the exact command which would be used for the actions. I can see msbuild used in many places in the output but it is a little confusing
to find the exact command.
I also saw this question (Does Visual Studio use MSBuild internally, and what is the exact command?)
This answer says that:
Quote:
"It appears that the MSBuild command line options are not specified,
but rather the MSBuild APIs are called within Visual Studio. Unless
you have the Visual Studio source code to reverse engineer, you cannot
get an equivalent command line."
Is that the same case for dotnet core cli msbuild as well?
Any help or clarification on this is appreciated.
I know that the dotnet core cli was build on top of msbuild so when
you run Build/Rebuild or Clean Solution Visual Studio uses msbuild
commands directly and not the ones from dotnet core cli?
For VS2017, I would think the VS IDE calls msbuild.exe directly when Clean, Build and Rebuild.You can easily check this point by Task Manager or Process Monitor.
As for what you mentioned above:It appears that the MSBuild command line options are not specified, but rather the MSBuild APIs are called within Visual Studio.
I think it's right but only for the eariler vs versions(2010,2013). I've tested with VS2010, when doing building-related actions in VS, it doesn't call MSBuild.exe. So the msbuild in VS2010 is not executed as a separate process.
But for VS2017, when I create projects which target .net core, when doing building-related actions(click the build, clean, rebuild button), it obviously calls the msbuild.exe like below:
About what msbuild commands VS actually executes:
Since now the VS2017 calls msbuild.exe to build .net core or .net fx projects.
In my opinion:
For the solution which only contains a project:
Build the Solution=> msbuild xxx.sln /t:build /p:Configuration=xxx;Platform=xxx
Rebuild the Solution=>msbuild xxx.sln /t:rebuild /p:Configuration=xxx;Platform=xxx=>msbuild xxx.sln /t:clean;build /p:Configuration=xxx;Platform=xxx
Clean the Solution=>msbuild xxx.sln /t:clean /p:Configuration=xxx;Platform=xxx=>msbuild xxx.sln /t:clean
I think every time when we click Build button in VS, it will pick the value of Configuration and Platform from this box, because these two parameters are sure to be passed to MSBuild.exe.
Also, one thing we can discover is that IDE has a check process before start build: It will check if the file is out-of-date and then determine if it need to build or not. But this is not what you ask in your issue and it not affects the command you want, so I skip it.
Also, see this page we can find there are some msbuild-related settings here:
So actually I think the command above should add some parameters like:msbuild ... -m:8 -v:M.
In addition: Though I find building-related action in VS will call msbuild.exe directly. I'm not certainly sure that my command above is 100% correct. I'm afraid no one can ensure that except the guys who develop the menu command in VS IDE. So if i misunderstand anything please feel free to correct me:)
And if you just want to get the exactly same thing like what in VS, you can also have a try devenv.exe. This is the only place in official document which confirms the build switch performs the same function as the Build Solution menu command within the integrated development environment (IDE).
We are attempting to install a clean build of the newest version of Kentico (12) on Azure, using Kudu, in DEBUG configuration. We traditionally accomplish this by setting SCM_BUILD_ARGS to -p:Configuration=Debug, and all is well. But for some reason in this newer version, the project fails to compile, and I see that this is the command being run:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Users\User\Documents\GitHub\Project\CMS\CMSApp.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="C:\local\Temp\8d6d315018f5ff9";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="C:\Users\User\Documents\GitHub\Project\.\\" -p:Configuration=Debug
Notice both Configuration=Release and Configuration=Debug. The compilation errors are things like Invalid expression term 'string' on the following line of code:
bool licenseOK = LicenseHelper.CheckLicenseLimitations(FeatureEnum.Ecommerce, out int skuCount, out int maxSKUCount);
This doesn't highlight at all in Visual Studio in Debug or Release mode. I am also able to reproduce locally (as shown in my paths above), and if I change the two configurations to both be the same (regardless of whether I choose Debug or Release), it compiles just fine.
What I know I can do is create my own custom deployment command script file as a work-around, but I guess I don't understand why the above MSBUILD command isn't working in the first place.
Any ideas as to why this would work great for all of my ASP.NET projects prior to this one? One thing I know is that Kentico recently included the Roslyn compiler, which I am unfortunately not that familiar with - could that be part of the issue?
UPDATE #1: It appears all of the compilation errors have to do with code that is only valid in C# 7.0. That could be a clue.
It all came down to the fact that the newer versions of Kentico had code that was only valid in C# 7, and required MSBuild 15 to compile. Here's how I was able to set up Kudu:
Add a file named .deployment in the root of my repo, containing only the contents below. This tells Kudu to use a custom deployment script.
Download the deploy.cmd file from my Azure App Service via FTP to the root of my repo, and update it per https://github.com/projectkudu/kudu/issues/2350#issuecomment-373817740 to use the MSBuild 15 path. Details below.
.deployment file contents
[config]
command = deploy.cmd
deploy.cmd updates
1 - Add -MSBuildPath "%MSBUILD_15_DIR%" to nuget call. Example:
nuget.exe restore "{your .sln file path}" -MSBuildPath "%MSBUILD_15_DIR%"
2 - Replace %MSBUILD_PATH% with %MSBUILD_15_DIR%\MSBuild.exe in both occurrences under step 2. Build to the temporary path
This was all that was needed in order to get the build to complete.
As Keith mentions, it was a compatibility issue with C# 7.0 that Kentico 12 uses. This SO thread mentions that you need to run MSBuild version 15 for C# 7.0 code. I ran a similar debug command for my local Kentico 12 project using MSBuild 15, and it succeeded.