I experience a problem with running my .NET application service built with TopShelf on Mono.
The development setup is: Win 8.1, VS 2015, .NET 4.5.2 as a target framework
The CI setup: Win Server 2012, TeamCity 9.1.6, both server and build agent are running at the same machine
The execution (test server) setup: CentOS 6 x86_64, Mono 4.2.2
So I've implemented an application running as both a console application and background service (with the TopShelf) and successfully debugged and tested it locally.
I've set up the CI server in the way it builds an application on a build agent and produces as a folder with multiple dlls and .exe runner file inside (Release configuration) as a output. Finally CI publishes this folder to the remote CentOS server.
When I connect to the CentOS server via ssh and try to run it with the mono myapp.exe command, I get an error:
# mono myapp.exe
Configuration Result:
[Success] Name myapp
[Success] DisplayName myapp
[Success] Description myapp
[Success] ServiceName myapp
Topshelf v3.3.154.0, .NET Framework v4.0.30319.17020
[DEBUG][2/4/2016 7:42:57 PM][Thread 0001][EventStream] StandardOutLogger started
[INFO][2/4/2016 7:42:57 PM][Thread 0006][[akka://AkkaGrid/system/log1-NLogLogger]] NLogLogger started
[DEBUG][2/4/2016 7:42:57 PM][Thread 0001][EventStream(AkkaGrid)] Logger log1-NLogLogger [NLogLogger] started
[DEBUG][2/4/2016 7:42:57 PM][Thread 0001][EventStream(AkkaGrid)] StandardOutLogger being removed
2016-02-04 22:42:57.4509 DEBUG Start
2016-02-04 22:42:57.4538 DEBUG Logger log1-NLogLogger [NLogLogger] started
2016-02-04 22:42:57.4714 DEBUG StandardOutLogger being removed
2016-02-04 22:42:57.4714 DEBUG Default Loggers started
The myapp service is now running, press Control+C to exit.
2016-02-04 22:42:57.5075 ERROR Error while creating actor instance of type MyApp.Actors.Supervisor with 0 args: ()EXCEPTION OCCURRED:Akka.Actor.ActorInitializationException Exception during creation Void Create(System.Exception)
TypeLoadException Error while creating actor instance of type MyApp.Actors.Supervisor with 0 args: () Akka.Actor.ActorBase NewActor()
TargetInvocationException Exception has been thrown by the target of an invocation. System.Object InternalInvoke(System.Object, System.Object[])
MissingMethodException Method 'Array.Empty' not found.
2016-02-04 22:42:57.5216 INFO Message FetchEntityMessage from NoSender to akka://AkkaGrid/user/$b was not delivered. 1 dead letters encountered.
Ignoring the fact that there are also Akka.net and NLogger inside, the core issue seems to be in this line:
MissingMethodException Method 'Array.Empty' not found.
So, in order to test the compatibility of my code with Mono itself I've manually copied the application folder (Release) from my local machine (right after VS2015/MsBuild) to CentOS server and ran mono myapp.exe command again.
This way the execution succeeded and produced no errors in the output.
To ensure that the issue is not connected to the copying process, I've connected to the Win2012 server (with CI running on it), went to the build agent's working directory and executed myapp.exe as a simple windows console application. It ran successfully. Then I copied the application folder manually to the CentOS server via scp command from git bash and... got the same issue as above.
To provide some extra details, the build log is the following:
Step 2/7: Build .NET subsystem (MSBuild) (6s)
[22:36:32][Step 2/7] Starting: C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe /workdir:C:\TeamCity\buildAgent\work\17605015421235b0 "/msbuildPath:C:\Program Files (x86)\MSBuild\14.0\bin\amd64\MSBuild.exe"
[22:36:32][Step 2/7] in directory: C:\TeamCity\buildAgent\work\17605015421235b0
[22:36:33][Step 2/7] .net\MyApp.sln.teamcity: Build target: TeamCity_Generated_Build (4s)
[22:36:33][.net\MyApp.sln.teamcity] TeamCity_Generated_Build (4s)
[22:36:33][Step 2/7] MSBuild command line parameters contain "/property:" or "/p:". It is recommended to define System Property on Build Parameters instead.
[22:36:38][Step 2/7] Process exited with code 0
So I can see that TeamCity doesn't run the MSBuild directly, but some MsBuildBootstrap application. MSBuild Tools 2015 are set in the build step settings. So... that's all the details, any help appreciated :)
MissingMethodException Method 'Array.Empty' not found.
This method is new in .NET 4.6 as specified in the documentation.
The problem is that Mono 4.2.2 is not compatible with this version of .NET.
I've looked at the sources, and it looks that Mono from the master branch already includes this. However, the commit in which it was introduced is not yet marked as being present in any tag or branch. That means you will have to wait until Mono 4.3 or 4.4 is released, or compile Mono from sources yourself, or maybe try to look for a weekly/nightly build that you could use.
An easier fix may be trying to depend on binaries that are not so bleeding edge (i.e. that were compiled using the framework version 3.5 or 4.0).
Related
I try to build my project in my CI/CD pipeline with a gitlab runner, but I always end in the following error message:
C:\Program Files\dotnet\sdk\6.0.100\Microsoft.Common.CurrentVersion.targets(3264,5): error MSB4216: The GenerateResource task could not be performed because MSBuild could not create a task host or connect to a task host with runtime CLR4 and architecture x86. Make sure that (1) the requested runtime and/or architecture is available on the computer and (2) the required executable file "C:\Program Files\dotnet\sdk\6.0.100\MSBuild.exe" exists and can be executed. [project_path]
C:\Program Files\dotnet\sdk\6.0.100\Microsoft.Common.CurrentVersion.targets(3286,7): error MSB4028: The output of the GenerateResource task could not be retrieved from the FilesWritten parameter. Object does not match target type. [project_path]
I´ve installed .NET6 SDK with version 6.0.100.
It seems like its trying to find the msbuild.exe and it´s not there. I´ve copied the file temporarely but this causes a endless building without result or error message.
Am I missing something? In my Visual Studio 2022 the build process is working and generating my binaries.
Our coded ui tests take several hours to complete, if I launch run functional tests task from the build definition it looks like it is consuming build minutes and using build pipelines so wrote a small powershell script (and a console application in C#). the plan is to launch either ps1 or console app from the build definition and exit. the ps1 or exe takes a build name as a parameter and launches the vstestconsole with that name as one of the parameters. when I test this locally on azure VM test machine it works fine (updates the results) but when I launch the same through build definition with build name as the parameter I get build cannot be found under team project error:
Log:
[command]C:\Users\automation\Desktop\ps1\cmd\ExecuteVSconsole.exe UI_Automation_NoWait_20170621.9
Error: Build "UI_Automation_NoWait_20170621.9" cannot be found under team project "XXX"
arg list :C:\Uiautomationbinaries\UI.dll /logger:Tfspublisher;Collection=https://xxx.visualstudio.com/;BuildName=UI_Automation_NoWait_20170621.9;TeamProject="xxx"
The build task I am using is : Powershell on target machine.
The build number is unique (name of the def + day+rev)
I have tried some of the solutions I have found online.
Since running locally successful, suggest you RDP to the remote machine (the target machine of the task)with your build service account. Then manually run the powershell script to see whether it works.
Also pay attention to the permission of your build service account.
Besides, since you are using azure VM , also follow this tutorial To set up WinRM for Microsoft Azure Virtual Machines for PowerShell on Target Machines task.
Summary:
My company uses TargetProcess (TP) to track progress on open projects and we've created a relatively small bit of code that imports updates to TargetProcess.
Currently upon build submission, we spin up a debian docker image, with Mono pre-installed, and it runs our small .NET(C#) program to connect our updates to TP.
Repro:
It appears TP recently updated their API to only accept TLS1.2 connections, so we had to create a new docker image with Mono 4.8, the Alpha channel, on it (per this article).
The program still doesn't work out of the box with this new Mono installation on a docker image so we took a few steps: (following the prompting from Mono's Security FAQ)
// Made sure that the most current version ca-certificates-mono is installed
// and it seems to have been installed upon installation of mono 4.8
apt-get install ca-certificates-mono
// This should be an unnecessary step from what I read, but ran anyway
cert-sync /etc/ssl/certs/ca-certificates.crt
// lastly btls-cert-sync command, but can't seem to get it to not return
// "command not found" no matter wher I try running it
btls-cert-sync
Testing:
There seems to be a really helpful thread on how to test if your certs are formatted correctly. After running this test command in my docker image, I'm still seeing the failure message below.
MONO_TLS_PROVIDER=btls csharp -e 'Console.WriteLine (new System.Net.WebClient ().DownloadString ("https://www.howsmyssl.com/").IndexOf ("1.2"))'
// error message
System.Net.WebException: Error: TrustFailure (Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED) ---> Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSLroutines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
Any help or advice to get our instance of mono to accept TLS1.2 connections would be awesome.
btls-cert-sync is a shell script for btls-cert-sync.exe
Find btls-cert-sync.exe, normally installed in 4.8.0/lib/mono/4.8 and run it with mono:
mono btls-cert-sync.exe
As of mono 4.8 beta 3, btls-cert-sync seems to have been merged into cert-sync.
Do make sure that you have an up-to-date version of cert-sync as it is possible to get old versions of cert-sync still installed even if you have updated mono because the ca-certificates-mono package has not been updated (Linux).
If you look at the cert-sync output you will see
Mono Certificate Store Sync - version 4.8.0.0
...
Importing into legacy system store:
...
Importing into BTLS system store:
...
I'm trying to run the latest Asp.Net 5 samples (currently 1.0.0-rc1-update1) from powershell on Windows 10. I have the active and default DNX set as the CLR x86. I have run the dnu restore command against each of the 3 projects and this has completed without error.
If I run the command dnx run for the console sample this works fine. However, when I then run the command dnx web from within either of the web project's folders I get the error message;
'Microsoft.AspNet.Server.Kestrel' does not contain a static 'Main' method suitable for an entry point
The samples are pretty basic and so I assume it must be part of my dnx configuration. But why is this happening and how do I fix it?
The cause of the issue is a strange one actually but it looks like the dnu restore command is case-sensitive. I assume this has something to do with it having to run on Linux too but I'm not sure.
In powershell my current path was all lowercase but my folder structure wasn't. Whilst in webhello , if I ran the command cd ..\WebHello and then ran dnu restore, the restore worked fine and the dnx web command also then ran fine.
Interestingly, if I ran cd ..\webhello, the dnx web command still works fine.
I have a .net application built on .net framework 3.5, I am trying to build this application on Jenkins CI server. I've added MSBuild plugin and and have added path to the .exe file of 2.0, 3.5 and 4.0 versions of MSBuild. But my building processes are failing by showing the below error message.
Path To MSBuild.exe: msbuild.exe
Executing command: cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
[Test project] $ cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
'msbuild.exe' is not recognized as an internal or external command,
operable program or batch file.
Build step 'Build a Visual Studio project or solution using MSBuild.' marked uild as failure
Finished: FAILURE
Could anyone plz help me out..??
To make the MSBuild plugin work, you need to configure the plugin in the Jenkins management screen.
NOTE: in the newer Jenkins versions you find the MSBuild configuration in the Global Tool Configuration:
Note the "Name" field, where I've called this particular configuration v4.0.30319. You could call it anything you like, but ideally the name will somehow refer to the version.
You'll need to refer to this name later in the Jenkins PROJECT that's failing.
Note: The yellow warning implies that the Path to MSBuild field should be populated with a directory name rather than a file name. In practice you do need to enter the filename here too (ie. msbuild.exe) or the build step will fail.
In the Jenkins project that's failing, go to the MSBuild build step.
The first field in the build step is "MSBuild Version". If you created the build step before configuring any MSBuild versions, the value here will be (default).
After configuring one or more MSBuild versions, the drop down will be populated with the available configurations. Select the one you require.
You can see here that I've now selected the named configuration that matches the installation above.
Jenkins | Manage Jenkins | Configure System
scroll down to the MSBuild section and click MSBuild installations
define the full path to msbuild.exe, on my system I have 3.5 and v4.0.30319
Note - specify the path to 32-bit tools even on a 64-bit system, otherwise you might get an error message:
Building Windows Phone application using MSBuild 64 bit is not supported.
So in Jenkins - it could be for example:
Name: Version 3.5
Path: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
Name: Version 4.0
Path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSbuild.exe
I think you should set an absolute path for "msbuild.exe" in your Jenkins configuration,
for example:
C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe
You can also add the path where the msbuild.exe is, to the PATH system environment variable of the node (or nodes) that is running that specific job.
You could try executing the
%comspec% /k ""c:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
command, which will temporarily update your environment path variables to reflect the VS2010 build environment. Execute this before you call MSBUILD and see what happens. I use this in my own build scripts with no issues.
Side note; it's very likely counterproductive to have multiple versions of MSBUILD on your PATH. Concentrate on getting one version working and go from there.