I have a project built with SBT 0.13, and I publish it using the publishSigned task. How do I force this task to depend on the integration test task, so that integration tests will automatically run before publishing?
Related
We've have a number of .Net Framework 4.x solutions, some of which were recently migrated to .Net 6. As part of this work I created build pipelines for the new solutions, however these are extremely slow when compared to the builds of the .Net Framework solutions.
The slow build task is ".Net Core" ("DotNetCoreCLI#2"), and is used in three places: "restore" command to restore the solution's NuGet packages, "build" command to build the solution, and "test" command to run the solution's unit test projects.
Taking one solution as an example (around 50 projects), these are the approx timings:
restore: 1m20s
build: 3m
unit tests: 3m
And here are the approx. timings from builds of the .Net Framework solution, which you can see were substantially faster:
restore: 9s - using the "NuGet" ("NuGetCommand#2") task
build: 1m13s - using the "Visual Studio Build" ("VSBuild#1") task
unit tests: 40s - using the "Visual Studio Test" ("VSTest#2") task
I believe the latter two tasks utilise VS2019 (installed on our on-prem Azure DevOps server), and I recently found this 3rd-party marketplace build task, which is a VS2022 equivalent of these tasks. I have updated the .Net6 build pipeline to use these instead of the "DotNetCoreCLI#2" build and test tasks (and I reverted to using "NuGetCommand#2" for the restore). The timings are now on a par with the .Net Framework build pipeline:
restore: 10s ("NuGetCommand#2")
build: 50s (marketplace task)
unit tests: 32s (marketplace task)
I would prefer to use built-in tasks over marketplace tasks, but why is the "DotNetCoreCLI" task so slow? Am I missing something with regards to configuration, or is it just a case of newer technology not always equating to improved performance?!
Visual Studio tasks are pretty heavy and largely there for legacy support.
When making the jump to modern .NET, rule #1 is forget everything about the old way you build projects. When using .NET 6, you get a much better experience doing everything with the dotnet CLI from NuGet package restoration (dotnet restore) to testing (dotnet test) and publishing an artifact (dotnet publish <ARGS>). Use those in your build pipeline with the UseDotNet#2 and DotNetCoreCLI#2 pipeline tasks.
Very important to note, in Azure DevOps you can cache your NuGet dependencies so you don't have to download them unless they change.
I have created a release pipeline in azure for my .Net core test project. I am using runsettings file to store test inputs for my selenium automation project.
While running the pipeline it's getting failed with error - Assembly Initialization method Tests_MSTestAssemblyHooks.AssemblyInitialize threw an exception. System.Exception: System.Exception: Unit test Provider already set. Aborting test execution.
This is the same error in Visual studio when we don't select runsettings file from Test> Configure Run Settings. From this I guess, it is not able to find runsettings file.
I have mentioned runsettings file in VsTest task. As it didn't work, then I also added Copy file task in the release pipeline.
Here are some more screenshots from VsTest task log - 1, 2, 3 as I am not able to attach the file here.
I am using MS Test as a test framework and a self-hosted agent pool if that matters.
I had one unloaded unit test project in my solution which is using NUnit adapter. Nuget restore in my build pipeline was installing it. When release pipeline was dropping all assemblies in single folder, where MSTest and NUnit adapters were present. Test started executing its getting conflict between these adapters, as a result tests were not able to find runsettingsfile.
I removed that unit test project and it started working.
I saw a couple of similar questions but so far I found no single answer to the problem of integrating the publishing step with my build process. Unfortunately the dotnet publish command rebuilds the project again meaning that if I put the "dotnet publish" command in the project's Post-Build steps I get an infinite loop of building retries.
What I want to achieve is to get an exe built for my .NET Core 2.2 Console App for a few selected environments eg. osx and windows-10, possibly linux too, each in its own folder. Obvious condition is that it has to be integrated with the build, so no extra manuals steps (commands) are required. This has to work from within VS2019 Pro as well in CI (like AzureDevOps).
Is this basic step achievable or .Net core was a major step-back in the progress of software development?
I hope I just miss something and I am just grossly exaggerating. :)
Thanks, Radek
How do I integrate exe publishing with the VS2019 build of the console
.net core 2.2 application?
Actually, I think you do not need to worry about this.
dotnet publish already contains the build process. Publish process will first execute Build and then run publish. In a word, Build is a part of Publish process.
So when you input dotnet publish under Build, you will get an infinite loop of building retries.
Solution
----- Just delete post-build event in xxx.csproj file and just dotnet publish directly and it will run the build process first.
You can test in the local VS and when you right-click on your project-->Publish, it will show the step in the output windwow.
In addition, as far as I know, Azure DevOps has a task called dotnet publish which contains Build.
And if you want to do some msbuild custom target only for publish step, you can add a condition like Condition="'$(DeployOnBuild)'=='true'", it will execute for Publish process rather than the normal build step(right-click on your project-->Build).
<Target Name="testone" Condition="'$(DeployOnBuild)'=='true'" AfterTargets="Build">
xxxxxxxxxxxxxx
</Target>
---------------Update 1----------------
First question
Actually, the build of the publish is the pure process and then publish will copy the content of the build output into publish folder. So the execute program is just from the build output folder.
See the publish log:
So you should not specify a publish target under the build process. This is superfluous.
Second question
To generate this program for Window-10, linux or osx, you can try these command line to publish your project:(Release is the standard release build configuration)
For Win-10:
dotnet publish -r win10-x64 -c Release --self-contained
Linux:
dotnet publish -r linux-x64 -c Release --self-contained
For osx:
dotnet publish -r osx.10.12-x64 -c Release --self-contained
In this way, the project is first built according to the specified runtime and then published.
More info about .NET Core RID Catalog, you can refer to this document.
Update 2
I think you should change the configuration in this package UI:
Then click Save.
Also, when you publish this web project, please try to delete bin and obj folder and then publish it.
Debug: bin\Debug\netcoreapp2.1\publish
Release: bin\Release\netcoreapp2.1\publish
Or you should use dotnet command as I described to publish the project. The path is under Debug or Release folder.
What I want to achieve is to get an exe built for my .NET Core 2.2
Console App for a few selected environments eg. osx and windows-10,
possibly linux too, each in its own folder. Obvious condition is that
it has to be integrated with the build, so no extra manuals steps
(commands) are required. This has to work from within VS2019 Pro as
well in CI (like AzureDevOps).
Is this basic step achievable or .Net core was a major step-back in
the progress of software development?
It's a good idea but as I know what you want is not 100% supported for now.
It seems that your expected scenario is:
Click the Build(F5) button=>Project will be built in different platforms win-x64,win-x86,linux-x64...,also will be published in different platforms automatically with self-contained mode.
But the fact is:
1.Click the Build button(Build(F5) equals to the Build button in project context) will run the Build Target (A default built-in target for each project for build). => dotnet build in command-line.
2.Click the Publish button will run the Publish Target (A default built-in target for each project for publish). => dotnet publish in command-line.
3.If you have any build/publish command in post-build event, it will result in an expected loop. So it's hard to combine publish with build perfectly since they're two actions in VS with different button/behavior/corresponding command. (Only dotnet publish command can recognize --self-contained)
4.To build/publish the projects in parallel, the batch file or msbuild targets file is a good choice.
#1.Build different platforms using one build command see this. #2.Publish different platforms using one command see this. (They both use custom .targets to do the job)
Suggestions:
According to your scenario, I think you can consider using #2. It's not necessary for you to build with different platforms during your normal development.
1.In local VS when you're developing and debugging:
The default build button/option is enough for you to debug.
2.In local VS when you want to publish the project in different platforms:
Use #2 above so that you can publish them using cmd.exe or PS.exe. (Via command dotnet msbuild -restore -t:PublishAllRids)
3.When you're automating the CI pipeline in AzDeops(Also use #2):
A CMD/PS task with dotnet msbuild -restore -t:PublishAllRids command is enough. Dotnet publish will build automatically if we don't pass --no-build argument.
4.Azure Devops Service suggests separate the jobs in different tasks, it's not recommend to Integrate Publish with Build heavily, especially for .net core projects. (Here's official sample about CI for .net core projects.)
I have developed some End to End tests using Selenium, and Nunit.
I need to run the test cases cross-platform so I created a .net core class library project and developed the tests.
Now I am struggling with figuring how to run the tests outside visual studio.
The first step I did is publishing the project using:
dotnet publish project
Then I found out that I can run Nunit tests using nunit-console.exe, but I'm not sure that it supports cross-platform.
Is what I am trying to accomplish doable? or shall I replace Nunit with other option?
To run .Net Core tests, including NUnit tests, use the dotnet test command. It is cross-platform.
What I did to achieve running Nunit Test Cases cross platform:
1- Running dotnet publish project with specifying target runtime.
3- Running dotnet vstest with specifying file containing tests.
I have codedUI and unit tests in my solution. Solution and the unit tests are successfully building in TFS 2017. CodedUI tests fail. I get an error.
Failed to initialize the unit test extension 'urn:CodedUITest': A unit test extension is not registered for the following attribute: Microsoft.VisualStudio.TestTools.UITesting.CodedUITestAttribute.
All the tests successfully pass in my local machine. What configuration am I missing in my build process?
kindly, help!.
According to the error info, seems the issue should more related to build agent Environment setting. Make sure you have Visual Studio and Coded UI features installed on the build agent. You could double check this by remote to the build agent and manually run Code UI in the agent machine instead of through TFS build.
If you are using Nuget Visual Studio Test Platform Installer , this is not support for now, take a look at the similar issue: VSTS build release agent unable to run Coded UI tests when using the Nuget VsTest platform
Currently Coded UI and UWP tests not support with VSTest platform
nuget package. /cc #PBoraMSFT for blog/doc and timeline for support.