I use TeamCity 9 for continious integration. Machine running under Windows Server 2008 R2 - Russian. There are russian language PowerShell installed etc. In TeamCity build log, all russian symbols are in wrong encoding.
How to change encoding in build log?
UPD: Also I use Intellij IDEA for creating Maven project and I have 2 sql files with UTF-8 chars.
Please see the following post regarding encoding in TeamCity buildlog :::
Teamcity build log
This sounds like the very same q...
Kind regards
Related
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.
I try to convert docx to pdf using documents4j. At first, I try it on my local pc and it works perfectly. But when I upload it in weblogic, it says this error
com.documents4j.conversion.msoffice.MicrosoftWordBridge : Unable to run script: /tmp/1485771859333-0/word_start103185801.vbs java.io.IOException: Could not execute [cmd, /S, /C, ""/tmp/1485771859333-0/word_start103185801.vbs""] in /tmp/1485771859333-0.
This can mean different things:
The .NET runtime is not installed on the Weblogic server.
You do not have rights to execute scripts via .NET on this server.
documents4j is a Java library but binds .NET commands and needs an MS Word installation. Also, make sure that you completed any MS Word Wizard that can appear right after installation of a new copy.
I am trying to add a file with unicode name to my installer , when I copy and paste or insert the filename , it gives ??????.pdf as characters, so in compilation it couldn't recognise the file and failed to open it .
File: failed opening file "..\???? ????????.pdf"
Any idea will be appreciated
With NSIS 2 all filenames have to be encoded in the active codepage (CP_ACP) and it will generate an ANSI API installer so the codepage on the end-users machine comes into play as well.
The NSIS 3 compiler is Unicode but to generate a Unicode installer you need to add Unicode true to your .nsi script.
Do you use the standard NSIS version (2.46)?
Maybe you can try the Unicode NSIS or the new (alpha!) Version NSIS 3.0a2.
Trying to configure NUnit 2.5.8.10295 in Cruise Control.NET on Windows Server 2008 R2, .NET 4.0, my NUnit task times out, and nunit-agent.exe seems stuck running. It works fine from the command line.
The only solution I've found is to define the environment variable COMPLUS_Version.
Is there a better solution to this problem?
C:\builds\nunit\bin\net-2.0\nunit-console-x86.exe
C:\builds\testLogs
C:\builds\build\NUnit.Tests\bin\Debug\NUnit.Tests.dll /nologo /framework=4.0.30319
10
0,1,3,5
COMPLUS_Version
v4.0.30319
I tried various edits to nunit-console-x86.config, but nothing worked but this awkward looking "solution".
Thanks
You are most likely running into the known bug reported here https://bugs.launchpad.net/nunitv2/+bug/602761 Your setup is identical to our setup as posted (comment 1). Your fix is the one suggested by the project maintainer. The other option is to not use the nunit-agent and force nunit console to run as .NET 4.0
My buildbot has been running for 3 years using devenv.com to compile the projects on Windows.
Now devenv.com has troubles to build for 64 bits versions: passing the configuration as "Debug|x64" generates command line errors because of the pipe character. Escaping and enclosing between quotes result into other errors, some because of the spaces in the directory names, some because of strangely understood command line.
I tried both vcbuild.exe, and MSBuild.exe. vcbuild.exe works perfectly: I'd like to stick to it. MSBuild.exe, on the other side, has a completely strange and complicated output that my coworkers feel terrible. But it is touted everywhere as THE way to build.
The question is: which of devenv.com, vcbuild.exe, and MSBuild.exe is the method that is most likely to last in time?
MSBuild (before Visual Studio 2010/.NET 4) doesn't itself build C++ projects. It calls out to vcbuild.exe. So if you are happy not using MSBuild then I would stick to that for the C++ projects. For managed projects (and for C++ using VS 2010) use MSBuild.
MSBuild is the method "most likely to last". VCBuild.exe is dead; it's last release was 2008. MSBuild 4.0 will still use it, if it needs to build a VC project from VS2008 or earlier. As for devenv.exe -- of course, it's just headless Visual Studio. Functionally it is the same as hitting build in VS. That means that these days, it's essentially just handing off to MSBuild, but sometimes with less parallelism than msbuild.exe will get. The main reason you might still have to use devenv.exe is .vdproj (Deployment) projects. These legacy things have a build process hard coded into VS. I recommend an alternative like WiX or Installshield which are MSBuild based. Not long now until everything build in VS is MSBuild.
In short -- MSBuild is the future, use it unless you have deployment projects or other special circumstances.
Dan
I ran into the same problem, and solved it by Windows-shell-escaping the pipe character:
"Debug^|Win32"
msbuild.exe does not (did not?) know how to build setup projects. devenv.exe does.