I have a dotnet core project that I have already compiled:
> dotnet build --configuration Release
If I try to run the test using the resulting dll using the /p option, it fails:
> dotnet test .\bin\Release\netcoreapp3.1\MyProject.dll /p:CollectCoverage=true
Microsoft (R) Test Execution Command Line Tool Version 16.10.0
Copyright (c) Microsoft Corporation. All rights reserved.
The argument /p:CollectCoverage=true is invalid. Please use the /help option to check the list of valid arguments.
Does anybody know how I could pass the /p option when providing a dll?
Note that I know that I could use the --no-build option like this:
> dotnet test --configuration Release --no-build /p:CollectCoverage=true
Unfortunately, for some reasons that would be too long to explain here, I can't use that option. I really have to call dotnet test by providing a path to an already existing dll.
Related
I am trying to automate deployment of an ASP.NET WebAPI on a Linux server using the following command:
dotnet publish --configuration Release
However, when adding a new NuGet package to the solution, and then trying to run the dotnet publish command, I get an error because the compiler does not know the new package. Is there a way to tell the dotnet command to pull all NuGet packages ? (I'm kind of looking for an equivalent for pip install -r requirements.txt in python).
For information, I add the NuGet packages via VisualStudio without compiling the solution.
Edit : it seems like, unless I build the solution in VisualStudio, just adding a NuGet packet will only add the packet name and version in the file projectname.csproj.nuget.dgspec.json, but will not add the PackageReference projectname.csproj file, hince the not pulling new packets issue.
I assume you are using some CI/CD pipeline which could publish your web application somewhere.
Feels like you are missing steps before publish:
# Restore (restores nuget packages)
run: dotnet restore
# Build
run: dotnet build --configuration Release --no-restore
# Test (if you have tests in project)
run: dotnet test --no-restore --verbosity normal
# Publish
run: dotnet publish --no-restore --no-build --framework netcoreapp3.1
May be this link may be helpful: github .net CI/CD
I'm trying the following command for my .NET Core 3.1. Console application in the folder D:\core:
D:\core>dotnet publish -c Release –r ubuntu-x64 --self-contained true
And it gives an error:
MSBUILD : error MSB1008: Only one project can be specified. Switch:
ubuntu-x64
For switch syntax, type "MSBuild -help"
When I use these two commands separately they work perfectly fine, but I need Release for Ubuntu; when I don't try to specify Release for Ubuntu it creates Publish folder in Debug folder:
D:\core>dotnet publish –r ubuntu-x64 --self-contained true
D:\core>dotnet publish -c Release
To summarize, the problem is that I can't currently publish for Release for a specified OS.
You have a –r in your command. That's a em-dash (–) followed by an r. Have you tried using a normal dash/hyphen?
That works for me:
$ dotnet new console
Getting ready...
The template "Console Application" was created successfully.
Processing post-creation actions...
Running 'dotnet restore' on /home/omajid/temp/HelloWorld/HelloWorld.csproj...
Determining projects to restore...
Restored /home/omajid/temp/HelloWorld/HelloWorld.csproj (in 66 ms).
Restore succeeded.
$ dotnet publish -c Release -r ubuntu-x64 --self-contained true
Microsoft (R) Build Engine version 16.7.0-preview-20220-01+80e487bff for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
Restored /home/omajid/temp/HelloWorld/HelloWorld.csproj (in 16.86 sec).
You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
HelloWorld -> /home/omajid/temp/HelloWorld/bin/Release/net5.0/ubuntu-x64/HelloWorld.dll
HelloWorld -> /home/omajid/temp/HelloWorld/bin/Release/net5.0/ubuntu-x64/publish/
Aside: you should use the linux-x64 runtime id rather than ubuntu-x64. linux-x64 is compatible with Ubuntu, but also many other distributions too.
I'm trying to build a Release pipeline that is triggered by a new version of a published dotnet core tool. The trigger works fine, but I'm unable to install and run the tool in my Tasks.
CURRENTLY:
Running a Command Line Task results in a 401:
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json. [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
The tool package could not be restored.
Tool 'myapp' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
This leads me to believe that I'm missing something here, making it more complicated than it needs to be, or thinking about this the wrong way. The tools in the feed can be installed locally, so I believe it's my release approach.
I'm currently looking into Personal Access Tokens (PAT)
PREVIOUSLY:
If I use the .Net Core task and the custom option:
The logs show a malformed command passed to dotnet.exe:
[command]"C:\Program Files\dotnet\dotnet.exe" "dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
or
[command]"C:\Program Files\dotnet\dotnet.exe" "tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
I've tried varying arguments and I tend to always see the same error message:
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET Core program, but dotnet-dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
Your custom dotnet command is quoted and dotnet is repeated : dotnet.exe" "dotnet tool install ..." so the command is misinterpreted.
You can use the Command Line task and set the dotnet command directly :
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
Using the .Net Core task works perfect for us.
Since the dotnet command is quoted, you need to set tool as the command and update into arguments. NuGet credentials can be provided with NuGet Auth task if needed.
Here is my walkaround:
I firstly published my private dotnet tool nupkg file also as an universal package to the same Azure Artifacts feed.
I was able to then use Universal Package task to download the .nupkg file into $(System.DefaultWorkingDirectory)/nupkgs/. This task will handle the authorization to Azure Artifacts feeds.
steps:
- task: UniversalPackages#0
displayName: 'Download mytool.cli.universal'
inputs:
downloadDirectory: '$(System.DefaultWorkingDirectory)/nupkgs/'
vstsFeed: '63d4aa2f-3ae7-4c27-8c18-aa8e3a9ff353'
vstsFeedPackage: '916d9a27-2c07-4071-8631-377f2ac08ed7'
vstsPackageVersion: 0.2.0
I then had the DotNetCoreCLI task to install my nupkg locally in agents.
steps:
- task: DotNetCoreCLI#2
displayName: 'Install mytool as a dotnet tool'
inputs:
command: custom
custom: tool
arguments: 'install --global mytool.CLI --add-source ./nupkgs --version 0.2.0'
You need to add the nuget authenticate task before you try to access the nuget feed
Assuming this folder structure
SampleApp
global.json
Src
Web
project.json
Startup.cs
...
Model
project.json
Startup.cs
...
how does one compile both projects using dotnet? (from command line, not in visual studio)
If you run dotnet build at the root folder level you get
Could not find file .. project.json
I can see there is this outstanding enhancement on the CLI repo but that is from Feb2.
Any script would have to take dependencies into account before just blindly calling dotnet on all src sub-folders.
The dotnet build command accepts glob patterns. So you can do this:
dotnet build Src/**/project.json
There's no such a tool yet. Even KoreBuild, the tool that the ASP.NET team uses, goes blindly in each folder and invokes dotnet build/pack.
The nice thing is that dotnet build is now smart enough to not recompile the dependencies if they haven't changed, so that's not a problem anymore.
For linux I'm using:
for p in $(find . -name *.csproj); do dotnet build $p; done
I had a similar requirement. This is my workaround:
#echo off
for /D %%d in (*) do (
cd %%d
cd
dotnet restore
dotnet build
cd ..
)
exit /b
Use GNU Make. I use it to build my projects. all you have to do create a Makefile in your project root folder. You can nest Makefiles in directories and have a Top Level Makefile that runs the subdirectories. then you set up Makefiles for each of your "Sub Projects" folders and run any comandline tool. with dotnet core is is dotnet .
Wait... GNU - "GNU is not Unix" that's a Unix/Linux application... I run windows. Well the good news is you can do this is in windows. I'm using make.exe through my git-bash installation (git for windows). You will have to go find the cygwin port of make. (google: "make for git-bash") Then install it to your bin directory under the cygwin folder. You could also just install cygwin if you really wanted to.
The nice thing about using Gnu-Make is it is universal. Since dotnet core is platform agnostic, every environment Mac/FreeBSD/Linux have "make" most likely already installed. Adding it to your Windows machine and projects to me makes a lot of sense. Since you project can now be built by everyone the same way.
some of my projects need to build docker containers with dockerfiles, or snap packages, deploy to test, etc... Make (pardon the pun) makes it easy.
Here is a sample of simple projects Makefile. Running 'make' by itself is like saying 'make all' you could set up a command like 'cd ./subdir; make' as one of your .phoney directives. (Google: "Makefile documentation")
project_drive?=/c/prj
nuget_repo_name?=Local_Nuget_Packages
local_nuget_dir?=$(project_drive)/$(nuget_repo_name)
RELEASE_VERSION:= `grep "<Version>" *.csproj | cut -d '>' -f 2 | cut -d '<' -f 1`
.PHONEY: clean release test doc nuget install debug_nuget debug_install
all: doc MSBuild
test:
./test.sh
MSBuild:
dotnet build
clean:
dotnet clean; dotnet restore
release:
dotnet build -c Release
doc:
doxygen ./Doxyfile.config
nuget: release
dotnet pack -c Release
install:
cp ./bin/Release/*.$(RELEASE_VERSION).nupkg $(local_nuget_dir)
debug_nuget: MSBuild
dotnet pack
debug_install:
cp ./bin/debug/*.$(RELEASE_VERSION).nupkg $(local_nuget_dir)
What's missing is that you can also use the commands on project.sln files if you do not have project.json
dotnet build src/**/project.json
-- or --
dotnet build src/project.sln
same goes for dotnet test
I am facing an error while building project in Jenkins and Asp.net. My source code is on TFS. Below is the error message (Console output) for my build.
No history entries were found for the item and version combination specified.
Path To MSBuild.exe: C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
Executing the command cmd.exe /C C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe /t:Rebuild "/p:Configuration=Debug:Platform="Any CPU":CustomBuildPath="C:\\Program Files (x86)\\Jenkins\\jobs\\PerformanceTest\\workspace\\PerformanceTest"" "C:\Program Files (x86)\Jenkins\jobs\PerfomanceTest\workspace\PerformanceTest\PerformanceTest.sln" && exit %%ERRORLEVEL%% from C:\Program Files (x86)\Jenkins\jobs\PerfomanceTest\workspace
[workspace] $ cmd.exe /C C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe /t:Rebuild '/p:Configuration=Debug:Platform="Any CPU":CustomBuildPath="C:\\Program Files (x86)\\Jenkins\\jobs\\PerformanceTest\\workspace\\PerformanceTest"' "C:\Program Files (x86)\Jenkins\jobs\PerfomanceTest\workspace\PerformanceTest\PerformanceTest.sln" && exit %%ERRORLEVEL%%
Microsoft (R) Build Engine version 4.0.30319.17929
[Microsoft .NET Framework, version 4.0.30319.18063]
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1008: Only one project can be specified.
Switch: Files
For switch syntax, type "MSBuild /help"
Build step 'Build a Visual Studio project or solution using MSBuild' marked build as failure
Finished: FAILURE
Please resolve it.
Thanks in advance.
This is probably due to the double-quotes in Platform="Any CPU". Try to remove that and see if it works.
Or try moving the SLN file path to the beginning of the command, before the switches.
In vs2012 just try to create a Build definition "Test Build" using the default TFS template "DefaultTemplate....xaml" (usually a copy of it)
It will fail with the usual self-explaining-error
MSBUILD : error MSB1008: Only one project can be specified.Switch: Activities`
Of course somewhere in the default TFS template some " are missing so msbuild will receive as parameter a non escaped directory containing spaces so will result in multiple projects(?!)
So NEVER use spaces in you TFS Build Definition names, pretty sad and simple at the same time
R.Ballarino