We have Jenkins running on an Ubuntu OS 18.04.01 LTS and an older project written in C# / .NET 4.5
The application was always build manually in the past and I would like to use Jenkins to introduce CI so nobody needs to build the project manually anymore. The application does not have to run on Linux or anything like that, we just need the buildfiles (executables and DLL files). Is it possible to build this C# solution with Jenkins on Ubuntu?
I know about MONO and XBUILD but actually I can't manage to build the project under ubuntu because of different issues which do not happen under Windows, e.g. see here:
UserControls/ExpandablePanel.cs(33,35): error CS1043: Invalid accessor body `=>', expecting `;' or `{'
UserControls/ExpandablePanel.cs(33,66): error CS1043: Invalid accessor body `=>', expecting `;' or `{'
UserControls/ExpandablePanel.cs(35,41): error CS1043: Invalid accessor body `=>', expecting `;' or `{'
UserControls/ExpandablePanel.cs(37,40): error CS1043: Invalid accessor body `=>', expecting `;' or `{'
UserControls/ExpandablePanel.cs(133,22): error CS1644: Feature `pattern matching' cannot be used because it is not part of the C# 6.0 language specification
UserControls/PagedDataGridView.cs(441,68): error CS1043: Invalid accessor body `=>', expecting `;' or `{'
1 Warning(s)
6 Error(s)
Is it even possible or do I definitely need to run Jenkins on a Windows machine?
It is possible. You can build C# project on Linux/Ubuntu. Try building using mono. When you will install mono package, one of the binaries that you will get will be xbuild. To build just invoke the following command:
xbuild <path to csproj/solution file>
Try building this manually first and then integrate with jenkins.
Related
I have two aspnet core 3.1 applications and have set up two azure piplines:
One pipeline is working fine building and testing my project, the other one (similar structure and referencing same projects) is failing with following error:
C:\hostedtoolcache\windows\dotnet\sdk\3.1.101\Sdks\Microsoft.NET.Sdk.Razor\build\netstandard2.0\Sdk.Razor.CurrentVersion.targets(404,5): warning RAZORSDK1006: Detected Razor language version downgrade. This is typically caused by a reference to the Microsoft.AspNetCore.Razor.Design package. Consider removing this package reference. [d:\a\1\s\Sources\Web\Web.csproj]
CSC : warning CS8034: Unable to load Analyzer assembly C:\Users\VssAdministrator\.nuget\packages\microsoft.aspnetcore.mvc.analyzers\2.2.0\analyzers\dotnet\cs\Microsoft.AspNetCore.Mvc.Analyzers.dll : Assembly with same name is already loaded [d:\a\1\s\Sources\Web\Web.csproj]
C:\Users\VssAdministrator\.nuget\packages\microsoft.aspnetcore.razor.design\2.2.0\build\netstandard2.0\Microsoft.AspNetCore.Razor.Design.CodeGeneration.targets(79,5): error : rzc discover exited with code -2147450730. [d:\a\1\s\Sources\Web\Web.csproj]
54 Warning(s)
1 Error(s)
Time Elapsed 00:02:41.66
##[error]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
Info: Azure Pipelines hosted agents have been updated to contain .Net Core 3.x SDK/Runtime along with 2.2 & 2.1. Unless you have locked down a SDK version for your project(s), 3.x SDK might be picked up which might have breaking behavior as compared to previous versions.
Some commonly encountered changes are:
If you're using `Publish` command with -o or --Output argument, you will see that the output folder is now being created at root directory rather than Project File's directory. To learn about more such changes and troubleshoot, refer here: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[error]Dotnet command failed with non-zero exit code on the following projects : d:\a\1\s\Sources\Web\Web.csproj
Does someone have an idea what I can check?
Kind regards
I'm trying to get a Xamarin Forms solution to build from the command line as part of a build script using the command dotnet build <solution.sln>. Most of the projects in the solution build; however, two projects fail with this error message: error MSB6006: "csc.exe" exited with code 1.(on Ubuntu) and error MSB6006: "csc.exe" exited with code 8. (on Mac).
I have running Ubuntu 18.04 (using Windows subsystem for Linux) and MacOS 10.13.6 on separate machines.
I have also tried to run dotnet build <solution.sln> from the windows command line which prints out this error message instead:
error MSB4062: The "XamarinLive.Build.XamarinLiveTask" task could not be loaded from the assembly C:\Users\Jason.nuget\packages\livexaml\2.1.22\build\XamarinLive.Build.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
However, the solution works and builds fine from within VS2017 (Version 15.9.7). I've tried scouring the binary log that is generated but I can't make much sense of it and there doesn't seem to be any obvious errors (on Ubuntu & Mac). Could the windows error message be related in some way?
The projects that are failing target netstandard 2.0 (The same as the projects that do build). The version returned by dotnet --version on all 3 environments is 2.1.504.
Any help would be greatly appreciated.
You need to use msbuild.exe instead of dotnet
build
for this situation.
msbuild.exe runs on full framework while dotnet buildruns on .NET Core, and most of the build tasks don't support that.
When you build them in VS,it actually calls the msbuild.exe to build the solution.So you can build it well by developer command prompt since it also calls the msbuild.exe.
For vs2017, you can find it in C:\Program Files (x86)\Microsoft Visual Studio\2017\Edition\MSBuild\15.0\Bin.
More details see Martin's answer from this similar issue. Thanks to his detailed description!
I've got a .Net application being built by Jenkins Pipelines and jenkinsfile. My Jenkins installation (up to date on the LTS versions) is unable to build my .Net application the first time within a workspace. Any new branch creates a new workspace then fails to build:
"<JENKINS_WORKSPACE_FOR_BRANCH\src\MY_SOLUTION.sln" (default target) (1) ->
"<JENKINS_WORKSPACE_FOR_BRANCH\src\Core\MySln.Core.csproj" (default target) (2) ->
(CoreCompile target) ->
Configuration\DefaultConfiguration.cs(143,51): error CS1002: ; expected [<JENKINS_WORKSPACE_FOR_BRANCH\src\Core\MySln.Core.csproj]
Configuration\DefaultConfiguration.cs(143,54): error CS1520: Method must have a return type [<JENKINS_WORKSPACE_FOR_BRANCH\src\Core\MySln.Core.csproj]
Configuration\DefaultConfiguration.cs(143,66): error CS1031: Type expected [<JENKINS_WORKSPACE_FOR_BRANCH\src\Core\MySln.Core.csproj]
Model\User.cs(48,24): error CS1056: Unexpected character '$' [<JENKINS_WORKSPACE_FOR_BRANCH\src\Core\MySln.Core.csproj]
Model\User.cs(75,20): error CS1056: Unexpected character '$' [<JENKINS_WORKSPACE_FOR_BRANCH\src\Core\MySln.Core.csproj]
Line 143 is
public string MyProperty=> ConfigValue("MyProperty");
Using the new C# 6 Expression Bodied Function Members syntax. The unexpected Character '$' is the c# 6 string formatting syntax:
var mystring = $"This is where I'll put {thisProperty} in my string";
My build call is:
bat "\"${tool 'MSBuildPipeline'}\" src\\MY_SOLUTION.sln /p:Configuration=Release /p:PlatformTarget=x64 /p:ProductVersion=1.3.5.${env.BUILD_NUMBER} /p:VisualStudioVersion=12.0 /p:TargetFrameworkVersion=v4.5 /ToolsVersion:12.0 /p:FrameworkOverride=\"C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.5\""
Which used to be much simpler but I've been trying to specify more and more to get to the bottom of this. I'm using MSBuild 12. I attempted to use MSBuild 14 but there's a problem with building on MSBuild 14 where you need to install a Windows 10 SDK to enable license generation and the SDKs only exist for .Net versions 4.6.x. I've got the Microsoft.Net.Compilers 1.3.2 NuGet packages installed to help enable the c# 6 syntax. The new 2.0.1 version only supports MSBuild 14.0+.
Again, it will only error out for the first build in this workspace. If I hit build again it will succeed without issue, despite no code changes. I'm assuming it's pulling some sort of .dll or asset the first time which fixes the issue for subsequent builds but I don't know what.
I've a C# project: https://github.com/Pro/dkim-exchange
It uses Travis CI: https://travis-ci.org/Pro/dkim-exchange
Travis successfully builds my project.
I wanted to set up Coverity to do automatic code quality measurements. For this I configured my .travis.yml as follows:
language: objective-c
env:
global:
- EnableNuGetPackageRestore=true
# The next declaration is the encrypted COVERITY_SCAN_TOKEN, created
# via the "travis encrypt" command using the project repo's public key
- secure: "kC7O0CWm9h4g+tzCwhIZEGwcdiLrb1/1PijeOKGbIWGuWS7cIksAkj2tRNMgtxxcE9CFQr8W7xDv2YzflCIlqN1nGkFjbyD4CrNg6+V1j0fZjPOQ6ssdBBVPrfrvecsAUJ0/48Tqa9VTkEpZSlwOF/VS1sO2ob36FVyWjtxvG9s="
matrix:
- MONO_VERSION="3.10.0"
install:
# Fetch Mono
- wget "http://download.mono-project.com/archive/${MONO_VERSION}/macos-10-x86/MonoFramework-MDK-${MONO_VERSION}.macos10.xamarin.x86.pkg"
- sudo installer -pkg "MonoFramework-MDK-${MONO_VERSION}.macos10.xamarin.x86.pkg" -target /
script:
- xbuild travis.proj
addons:
coverity_scan:
project:
name: "Pro/dkim-exchange"
description: "Build submitted via Travis CI"
notification_email: mail#example.com
build_command_prepend: "xbuild /t:CleanAll travis.proj"
build_command: "xbuild /t:Build travis.proj"
branch_pattern: coverity_scan
If I execute the coverity build commands as indicated here (using msbuild): https://scan.coverity.com/download?tab=csharp the uploaded archive is analyzed correctly, but in combination with travis, the coverity analysis fails (see e.g. this build log: https://travis-ci.org/Pro/dkim-exchange/builds/42295611).
There's this warning:
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
I think this may be related to xbuild from Mono. Unfortunately Dr. Google didn't find anythin about Coverity+xbuild. Does Coverity support xbuild? If yes, how can I correctly setup the project?
When it comes to C#, Coverity actually only supports msbuild.
You can find some more official information about this in the following
http://www.coverity.com/library/pdf/CoverityStaticAnalysis.pdf
https://communities.coverity.com/message/6251#6251
The last link explicitly states
Our C# analysis only supports the Visual Studio C# compilers
So, no xbuild support as of now.
Update:
When you download the Coverity build tool, the doc/en/help/cov-build.txt explicitly states the following:
C# build capture is only supported on Windows.
I am having to building mono from sources, since the Ubuntu package from badgerports is outdated (does not support .Net 4.0)
This is what I have done so far (mostly following instructions here):
cloned mono git repository
switched to branch tagged 2.6 (git checkout mono-2-6)
installed minimal mono on my machine so mono and mcs are available on machine
run ./autogen.sh --prefix=/usr/local
run make
After a few modules compile correctly, I get this error:
make[4]: Entering directory `/home/oompah/work/dev/mono/mono/mini'
CC mini.lo
CC liveness.lo
liveness.c: In function ‘mono_liveness_handle_exception_clauses’:
liveness.c:137: error: ‘MonoCompile’ has no member named ‘header’
make[4]: *** [liveness.lo] Error 1
make[4]: Leaving directory `/home/oompah/work/dev/mono/mono/mini'
make[3]: *** [all] Error 2
I have looked at the offending code, and indeed a header member is being accessed ...
void
mono_liveness_handle_exception_clauses (MonoCompile *cfg)
{
MonoBasicBlock *bb;
GSList *visited = NULL;
MonoMethodHeader *header = cfg->header;
...
}
Has anyone managed to build mono-2.6 (or later) on Ubuntu?
I've used the scripts provided at integratedwebsystems successfully to compile a recent version of mono on my system and run .net 4.0 applications.
an improved version of the script can be found on firegrass' github account
Joe Shields is packaging Mono 2.10 and is patching everything to default to .NET 4.0 for Ubuntu, you might want to poke him on twitter #directhex.