Having configured NUnit step using a bundled NUnit tool like that:
I am having difficulties with following message appearing at the beginning of the log once step is executed:
The TeamCity NUnit runner requires the following NUnit extensions to be installed: NUnit.Engine.Listeners.TeamCityEventListener, NUnit.Engine.Services.ProjectLoaders.NUnitProjectLoader. Please follow our instructions at: https://confluence.jetbrains.com/display/TCDL/NUnit#NUnit-NUnit3Extensions
The tests are running fine, as well as dotCover coverage. But, the process itself ends with a -100 exitcode, causing whole step to be failed. I checked if the extensions on TeamCity agent are installed along with the bundle and it looks like they're - dlls are in the addins folder. Running nunit3-console with --list-extensions also displays that extensions are installed.
I also tried to install NUnit.Console bundle NuGet package (and making sure that extensions are installed as well) and run it with specified nunit console executable path, but no luck - the error message was the same. As before, running nunit3-console from command line results in installed extesions.
Unfortunately, I don't know what's the logic behind that check and I don't know how to reproduce it. I assume that there's some mismatch, because the plugins are clearly running as TeamCity recognizes the results and put them on the interface.
TeamCity version: 2018.1.2 Enterprise (build 58537)
NUnit Version: 3.9.0 (bundled)
This was a bug, which is fixed in TeamCity 2018.1.3. See https://github.com/nunit/nunit-console/issues/468
Summary: TeamCity was reading the console output of --list-extensions to determine which extensions were installed. The format of this output changed in the NUnit 3.9 Console, which broke the TeamCity parsing.
Afraid I'm not sure if there's a workaround - I'm not a TeamCity user myself.
Related
I have an ADO build that keeps failing with,
Error APPX3217: SDK folder containing 'UAP.props' for 'UAP 10.0.20348.0' cannot be located.
That helped me locate the missing 2104 SDK. Earlier in the build, I attempt to remedy this with chocolatey by installing a 2104 SDK, which as far as I can tell is the only 2104 option available with choco:
- task: CmdLine#2
inputs:
script: 'choco install windows-sdk-10-version-2104-all -y'
It installs fine. The build breaks at the same point on multiple re-runs across multiple build nodes. All the similar questions I've run across with the same kind of error seems to automatically resolve after installing the correct SDK.
I wasn't sure if it would help, but I also installed the Microsoft.Windows.SDK.BuildTools NuGet package for the faulting project, and it also did not resolve the issue.
I've also tried both the MSBuild and VSBuild tasks. Any idea why it may not be detecting the installation at build-time?
Context:
I am following the guide for the open source project OpenSC https://github.com/OpenSC/OpenSC to compile the solution on Windows and get the opensc-pkcs11.dll module to use it for communications (such as OpenSSH) with HSM's via PKCS#11 standard. Currently I am using the latest stable release 0.21.0 (msi installer) and it works perfectly. However when I use https://github.com/OpenSC/OpenSC/wiki/Compiling-on-Windows guide to compile the solution using Visual Studio Developer Command Prompt I can successfully build the libraries however the opensc-pkcs11.dll always returns pkcs11: 0x5: CKR_GENERAL_ERROR when I try to use it and I am not sure what am I missing here.
Setup:
git clone https://github.com/OpenSC/OpenSC.git
git checkout 30180986a08cf71fe4af4b50251a8bb5b1ab95af (0.21.0 commit for the right version)
Manually Creating Built Source Files
nmake /f Makefile.mak
Building it for x64, with x64 Native Tools Command Prompt for VS 2019.
That should be it according to the guidelines as I do not need openpace/openssl/zlib to compile the opensc-pkcs11 as far as I understand.
Problem summary:
If I download from releases https://github.com/OpenSC/OpenSC/releases version OpenSC-0.21.0 the compiled opensc-pkcs11.dll works as expected
If I compile it from source code based on v0.21.0 commit I get 0x5: CKR_GENERAL_ERROR when trying to use the library for e.g. OpenSSH, tested that this happens for other/previous commits as well, there for I suspect that I am missing something here.
Has anyone experienced the same issue? Maybe there is some build config anyone could share so I can understand what am I missing here?
I attempted in building the .NET Standard Library Project using .NET Framework 4.6.1 from Command prompt using MSBuild Commmand. I manage to succeed building the project from command prompt.
I tried the same MSBuild command to build the project from Teamcity Command line build step, but ended up getting the following error:
C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets(140,5): error : The package Microsoft.NETCore.Portable.Compatibility
with version 1.0.1 could not be found in C:\Windows\system32\config\systemprofile\.nuget\packages\. Run a NuGet package restore to download the package.
I tried Restoring nuget.exe restore mysolution.sln but noting works.
Please help me to compile the solution from Teamcity command line step. Its strange to get compiled from command prompt but not from teamcity command line.
Looks like there is a known issue in NuGet when restoring packages using the LocalSystem account wherein the packages cannot be accessed under the C:\Windows\system32\config\systemprofile\.nuget\packages folder, even though account permissions should allow it (see this GH issue). The current recommended workaround is to use the NUGET_PACKAGES environment variable to specify another location for the packages (e.g. C:\NuGet\packages).
I have installed, via Composer, the latest versions of PHPUnit and the Skeleton Generator, 4.1.3 and 2.0.1, respectively. I have installed it to my project directory and confirmed that I can test all files. I cannot, however, run the skeleton generator to create new tests. I am using Netbeans and its PHPUnit integration to create the tests. When I attempt to generate the tests, I get the following:
"C:\xampp\php\php.exe" "C:\Users\Bob\Projects\[myProject]\website\vendor\phpunit\phpunit-skeleton-generator\phpunit-skelgen" "--test" "--" "Security\SecureAPI" "C:\Users\Bob\Projects\[myProject]\website\src\Security\SecureAPI.php" "Security\SecureAPITest" "C:\Users\Bob\Projects\[myProject]\website\test\phpunit\src\Security\SecureAPITest.php"
phpunit-skelgen 2.0.1 by Sebastian Bergmann.
[InvalidArgumentException]
Command "Security\SecureAPI" is not defined.
Done.
I had the Netbeans 'Use Bootstrap for Creating New Unit Tests' option selected prior to this, and got this error:
"C:\xampp\php\php.exe" "C:\Users\Bob\Projects\[myProject]\website\vendor\phpunit\phpunit-skeleton-generator\phpunit-skelgen" "--bootstrap" "C:\Users\Bob\Projects\[myProject]\website\test\phpunit\bootstrap.php" "--test" ...
[InvalidArgumentException]
There are no commands defined in the "C" namespace.
Generating tests with version 1.2.1 worked fine on my old development machine. I'm wondering if the issues are specific to version 2.0.1 of the skelgen. It seems to be viewing the C: as a namespace, whereas 1.2.1 did not. I've confirmed that Netbeans produced identical command line instructions for 1.2.1 and 2.0.1, so it appears that the way they are being interpreted has changed.
Has anyone else seen this? Any ideas? I'm running a Win7 machine with Netbeans 8.0. Thanks in advance.
Try to download Dev build of NetBeans from here, the issue with changes in Skeleton Generator 2.x was fixed few days ago
I was trying to use Nuget as a software deployment system (repository, versioning and delivery) - idea from Octopus. Previously I was packaging ASP.NET sites into a self-extracting RAR archives with a .CMD startup scripts embeded. Now I'm trying to use Nuget creating puckages during automated build. The issue is that the package installation scripts (tools\Install.ps1 or tools\Init.ps1) do not execute if the package is being installed using command line:
nuget.exe install <package_id> -OutputDirectory <install_folder> -source <local_repo>
Same scripts are able to execute when package installed from Visual Studio Package Manager or Console.
I do not see why this shouldn't be possible given omnipresence of PowerShell.
Am I missing something or this is behaviour by design? Will appreciate you help.
Yes, we did consider MSDeploy but we already have install scripts that do the same thing and give more control and we need some strong package management and repository for build artifacts (something that Java folks do with Maven).
As of today, the powershell scripts are not invoked from doing installations from command line.
One reason for this is that, in general, most of the install/init actions are tied to dte and the visual studio project and doesn't add much value to be able to run it from outside VS.
We have a backlog item for enabling support for exe based scripts too in addition to powershell.