Before I can use msbuild command in command line and pass the profile as a parameter. Is this currently supported in dotnet cli or is there a new way to build projects/solutions in .net core projects?
Under the hood, the dotnet cli is now mostly using msbuild to do the actual work (excluding dotnet new and dotnet run). So if you're doing a dotnet build, it's actually using msbuild internally.
You can still use msbuild parameters when using the dotnet cli, you need to use the following:
dotnet msbuild <options>
One option is /property:n=v which passes in your property name/value pairs directly to msbuild as you used to do with msbuild itself. You can also continue to use semi-colons between pairs, e.g.:
dotnet msbuild /property:WarningLevel=4;Configuration=Release
Related
In Azure Devops for a .Net core application.
I have three steps
dotnet restore
dotnet build
dotnet test
But if I simply run dotnet test that forces a restore and build. Is there any reason to have the first two steps?
You can use them as follows:
dotnet restore
dotnet build --no-restore
dotnet test --no-build
In this way, you will speed up your build as it can use result of the previous command.
This is default behavior so you don't need to always run all commands to run dotent test for instance. It is convinient and still possible to opt-out from thah behavior.
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).
I work with .NET Core SDK version 2.1.302. My solution has two type of projects: libraries and web. All libraries are targeted to .NET Standard 2.0: <TargetFramework>netstandard2.0</TargetFramework> and web projects have multiple targets: <TargetFrameworks>net462;netcoreapp2.0</TargetFrameworks>
I have two CI builds: for Windows which uses net462 and build in docker based on linux with netcoreapp2.0.
In the docker build to build my solution I use the following line of code:
RUN dotnet build ./MySolution.sln --configuration Release --framework netcoreapp2.0
And build fails with the rrors like this:
Assets file '/app/MyLibraryProject/obj/project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.0'. Ensure that restore has run and that you have included 'netcoreapp2.0' in the TargetFrameworks for your project. [/app/MyLibraryProject.csproj]
It happens because as I mentioned before my library projects are targeted only one framework - netstandard2.0
So, my question is how to deal with this situation? How should I specify that projects with only one target framework should ignore --framework param?
In the interests of making sure the answer is noticed, I found that the best way around this was #José Pedro's solution from the above comment stream.
In the csproj file, I put a condition on the TargetFramework element. Now it looks as follows:
<TargetFrameworks Condition="'$(CoreOnly)' != 'True'">net472;netcoreapp2.1</TargetFrameworks>
<TargetFramework Condition="'$(CoreOnly)' == 'True'">netcoreapp2.1</TargetFramework>
It will then by default compile both, but you can pass a CoreOnly parameter to only compile the .NET Core framework.
dotnet build MySolution.sln /p:CoreOnly=True
Another possible solution is to check which framework is available and set the <TargetFramework> dynamically in the build time:
<FrameworkDescription>$([System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription)</FrameworkDescription>
<TargetFramework Condition="$(FrameworkDescription.Contains('NET 5'))">net5</TargetFramework>
<TargetFramework Condition="$(FrameworkDescription.Contains('NET 7'))">net7</TargetFramework>
It will make dotnet build just work without any additional parameters on a system where only net5 or only net7 is installed.
I'm building a MVC application with .Net Core and I need to generate the script of a migration.
With EF6 I did run the command
update-database -script
but when I try to do the same with .net Core is throwing the next exception:
Update-Database : A parameter cannot be found that matches parameter
name 'script'
Do you know if there is an equivalent for EF Core?
As per EF documentation you can use :
Script-Migration
If you want to just script all the migrations you can simply call it from Package Manager console like that. If you want to just script the changes from the last migration you can call it like this:
Script-Migration -From <PreviousMigration> -To <LastMigration>
Be sure to check the docs, there're a few more options to the command.
dotnet ef migrations script --help
Usage: dotnet ef migrations script [arguments] [options]
Arguments:
<FROM> The starting migration. Defaults to '0' (the initial database).
<TO> The ending migration. Defaults to the last migration.
Options:
-o|--output <FILE> The file to write the result to.
-i|--idempotent Generate a script that can be used on a database at any migration.
-c|--context <DBCONTEXT> The DbContext to use.
-p|--project <PROJECT> The project to use.
-s|--startup-project <PROJECT> The startup project to use.
--framework <FRAMEWORK> The target framework.
--configuration <CONFIGURATION> The configuration to use.
--runtime <RUNTIME_IDENTIFIER> The runtime to use.
--msbuildprojectextensionspath <PATH> The MSBuild project extensions path. Defaults to "obj".
--no-build Don't build the project. Only use this when the build is up-to-date.
-h|--help Show help information
-v|--verbose Show verbose output.
--no-color Don't colorize output.
--prefix-output Prefix output with level.
so,you can try
dotnet ef migrations script ver1 ver2
dotnet ef migrations script ver1 ver2 -o ./script.sql
This works in .Net Core 2.1
You can use dotnet core cli to generate script
dotnet ef migrations script
Also you can put this to file with new power shell out-file command.
dotnet ef migrations script | out-file ./script.sql
You can also generate a script to rollback a migration by reversing the parameters to Script-Migration. For example, if you have two migrations, BadLatestMigration and GoodPreviousMigration, you can revert to GoodPreviousMigration by using the following command
Script-Migration BadLatestMigration GoodPreviousMigration
Afterwards be sure to Remove-Migration to remove the bad migration
Remove-Migration
This works in .Net Core 2.2.0
This also generates only the SQL
Update-Database -script -TargetMigration TO -SourceMigration FROM
I am able to "dotnet xunit" when I am in folder where the project is.
How can I do it from command line where I want to pass already compiled dll as a parameter.
dotnet xunit PathToLibrary.dll
I get an error:
No executable found matching command "dotnet-xunit"
I have copied "xunit.execution.desktop.dll" (get from nuget xunit.core.2.3.0) into current folder, but that does not help.
dotnet-xunit is a per-project CLI tool
Consuming these tools requires you to add a <DotNetCliToolReference> element to your project file for each tool you want to use. Inside the <DotNetCliToolReference> element, you reference the package in which the tool resides and specify the version you need. After running dotnet restore, the tool and its dependencies are restored.
So check that your .csproj contains
<ItemGroup>
<DotNetCliToolReference Include="dotnet-xunit" Version="2.3.0" />
</ItemGroup>
then do
dotnet restore
This answer isn't a direct answer to OP, but necessary for users of dotnet xunit
dotnet xunit is removed starting from xunit 2.4 Ref: Release Notes 2.4
Excerpt from the Release Notes:
Unfortunately, this release also removes the dotnet xunit runner, as the stability of the runner was never perfect, and it suffered from many assembly-loading related issues. Users from .NET Core can continue to use VSTest (either inside Visual Studio, or via dotnet test).
So, for xunit framework test use the command
dotnet test