I am trying to create a Pipeline on Jenkins, to automate my build, test and deploy process.
pipeline {
agent any
environment {
myVersion = '0.9'
}
tools {
msbuild '.NET Core 2.0.0'
}
stages {
stage('checkout') {
steps {
checkout([$class: 'GitSCM', ...])
}
}
stage('restore') {
steps {
bat 'dotnet restore --configfile NuGet.Config'
}
}
stage('build') {
steps {
bat 'dotnet build'
}
}
stage('publish') {
steps {
...
}
}
}
}
When trying to run the build, I get this error message from Jenkins:
'dotnet' is not recognized as an internal or external command,
operable program or batch file.
What do I have to change to make this environment work?
I added my .NET CORE path etc. to the Jenkins Settings for MSBuild.
What am I missing?
Solved it like this:
environment {
myVersion = '0.9'
dotnet = 'path\to\dotnet.exe'
}
and than replaced my command with the %dotnet% variable.
Related
I have some server app. This app run, read some files, create C# classes, build this and load assembly. This app can work in two modes - one mode is window desktop application, and other mode - as windows service but core in dll is common.
Sometimes when this app work long time as service, and machine server has long timeup, they can't build anything. I attach to debugger, and debug. I debug .NET source (CompileAssemblyFromSource), and I see, that .NET classes just run csc.exe process with some params (CSharpCodeProvider class), but csc.exe run, return no errors or exceptions, output is blank and nothing is happend. No assembly is build.
I wrote some dump test service to compile code:
namespace CompilerService
{
public class Compiler
{
private Task _compilerTask;
public Compiler()
{
_compilerTask = Task.Run(() => CompileHalloWorld());
}
private const string _workingDir = #"C:\tmp";
private void CompileHalloWorld()
{
System.Threading.Thread.Sleep((30000));
if (!Directory.Exists(_workingDir))
{
Directory.CreateDirectory(_workingDir);
}
Directory.SetCurrentDirectory(_workingDir);
var csc = new CSharpCodeProvider(new Dictionary<string, string>() { { "CompilerVersion", "v4.0" } });
var parameters = new CompilerParameters(new[] { "mscorlib.dll", "System.Core.dll" }, "foo.exe", true);
parameters.GenerateExecutable = true;
CompilerResults results = null;
try
{
results = csc.CompileAssemblyFromSource(parameters,
#"using System;
class Program {
public static void Main(string[] args) {
Console.WriteLine(""Hallo World!"");
}
}");
}
catch (Exception e)
{
int a = 2;
}
results.Errors.Cast<CompilerError>().ToList().ForEach(error => Console.WriteLine(error.ErrorText));
}
}
}
This dump service is fail too with build hallo world in this state of machine.
After restart machine, all work again ok, compile and load assembly all the time. After few weeks, problem come back, and we must reset server. This problem is on only one machine. On otger machines this service and csc.exe work perfect from years.
If machine is in this wird state, csc.exe dont build in windows service app, but when We run this app as Windows Desktop App all work fine, and csc.exe build normal...
Can you tell me, this is some known issue, oraz is some solution of don't compile csc.exe without machine restart?
I am using C#, coverlet.msbuild and the Jenkins Cobertura adapter.
I have roughly this in my Jenkinsfile:
stage ('Run unit tests') {
steps {
powershell "dotnet test -c:Release /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura --no-build --no-restore --logger trx"
}
post {
always {
step([$class: 'MSTestPublisher'])
publishCoverage failUnhealthy: true,
globalThresholds: [[thresholdTarget: 'Package', unhealthyThreshold: 50.0]],
adapters: [coberturaAdapter(
mergeToOneReport: true,
path: '**/*.cobertura.xml')]
}
}
}
This makes my Jenkins build fail if coverage is below 50% at package level. So far so good.
But when a build fails due to this, it is user-hostile and hard to see why. The 'Run unit tests' stage is green in Blue Ocean.
Can I make this stage turn red when it fails the build, so it is easier to see what the error is?
You can set currentBuild.result to FAILURE if publishCoverage is true. currentBuild.displayName and currentBuild.description optional:
post {
always {
script {
def failed = publishCoverage (failUnhealthy: true,
globalThresholds: [[thresholdTarget: 'Package', unhealthyThreshold: 50.0]],
adapters: [coberturaAdapter(
mergeToOneReport: true,
path: '**/*.cobertura.xml')])
if (failed) {
currentBuild.result = 'FAILURE'
currentBuild.displayName = "${currentBuild.displayName} Coverage"
currentBuild.description = "Coverage lower than 50%"
}
}
}
}
Inspired by the answer from Sers and some other Jenkinsfile code I read through, I arrived at this solution, which does what I want:
stage ('Run unit tests') {
steps {
powershell "dotnet test -c:Release /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura --no-build --no-restore --logger trx"
}
post {
always {
step([$class: 'MSTestPublisher'])
publishCoverage failUnhealthy: true,
globalThresholds: [[thresholdTarget: 'Package', unhealthyThreshold: 50.0]],
adapters: [coberturaAdapter(
mergeToOneReport: true,
path: '**/*.cobertura.xml')]
script {
if (currentBuild.result == 'FAILURE') {
error("Test coverage is too low.")
}
}
}
}
}
Maybe simple question however I'm stuck. I try to configure cake script. I'm using the following script
Task("Build")
.Description("Builds the Solution")
.Does(() =>
{
MSBuild(SOLUTION_FILE, CreateSettings());
});
MSBuildSettings CreateSettings()
{
var settings = new MSBuildSettings { Verbosity = Verbosity.Minimal, Configuration = "Debug" };
settings.WithProperty("DebugType", "pdbonly");
settings.ToolVersion = MSBuildToolVersion.VS2017;
return settings;
}
When I execute it. I have the following issue:
========================================
Build
========================================
An error occurred when executing task 'Build'.
I have added MsBuild path to PATH environment but still not working.
How can i set custom MsBuild path ?
Thanks
After installing VS 2015, running csc.exe from command line causes this message to be displayed to console:
This compiler is provided as part of the Microsoft (R) .NET Framework,
but only supports language versions up to C# 5, which is no longer the
latest version. For compilers that support newer versions of the C#
programming language, see
http://go.microsoft.com/fwlink/?LinkID=533240
The link redirects to Roslyn's repository at GitHub.
So, is the a way to run "compilers that support newer versions" (Roslyn) from command line?
It sounds like your path is inappropriate, basically. If you open the "Developer Command Prompt for VS2015" you should have $ProgramFiles(x86)$\MSBuild\14.0\bin early in your path - and the csc.exe in there is Roslyn.
I suspect you're running the version in c:\Windows\Microsoft.NET\Framework\4.0.30319 or similar - which is the legacy one, basically.
Roslyn from command line('cmd'), Windows 10 scenario example:
( Note: No need Visual Studio installed, but only the .NET core )
Open 'cmd' and create folder "dotnet-csharp-tools":
D:>mkdir "dotnet-csharp-tools"
Navigate to folder "dotnet-csharp-tools":
D:>cd "dotnet-csharp-tools"
In folder "dotnet-csharp-tools" download 'nuget.exe' latest version from:
https://www.nuget.org/downloads
Check name of the last version of 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform' from:
https://www.nuget.org/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform/
For example: 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform -Version 3.6.0'
From 'cmd'(opened folder "dotnet-csharp-tools"), run command:
D:\dotnet-csharp-tools>nuget install Microsoft.CodeDom.Providers.DotNetCompilerPlatform -Version 3.6.0
From 'cmd' navigate to 'D:\dotnet-csharp-tools\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0\tools\Roslyn472'(warning : folder name 'Roslyn472' may be different, if is other version)
D:\dotnet-csharp-tools>cd Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0\tools\Roslyn472
From 'File explorer' find 'csc.exe'(in the current folder 'Roslyn472').
Make copy of 'csc.exe' with name 'csc-roslyn.exe'(name can be whatever).
For 'Windows 10', open:
'Edit system environment variables' -> 'System variables' ->
'path' -> 'Edit' -> 'New' ->
D:\dotnet-csharp-tools\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.3.6.0\tools\Roslyn472
Close and open again 'cmd'(the command prompt).
This 'cmd' restart needed, because 'system environment variables' are edited.
Check if 'csc-roslyn' is recognized by 'cmd' by run command:
csc-roslyn
Create folder 'D:\csharp-projects'(folder name can be whatever)
and create in 'D:\csharp-projects' C# source files, for example:
Vehicle.cs
class Vehicle
{
private string name = "unknown";
private int producedYear = -1;
public Vehicle(string name, int producedYear)
{
this.Name = name;
this.ProducedYear = producedYear;
}
public string Name
{
get { return this.name; }
set { this.name = value; }
}
public int ProducedYear
{
get { return this.producedYear; }
set { this.producedYear = value; }
}
}
Car.cs
class Car : Vehicle
{
private string maker = "unknown";
public Car(string name, int age, string maker)
: base(name, age)
{
this.Maker = maker;
}
public string Maker
{
get { return this.maker; }
set { this.maker = value; }
}
public override string ToString()
{
return $"{this.Name}, {this.ProducedYear}, {this.Maker}";
}
}
Autoservice.cs
using System;
class Autoservice
{
public static void Main()
{
Car car1 = new Car("Ford Taunus", 1971, "Ford");
Car car2 = new Car("Opel Ascona", 1978, "Opel");
Car car3 = new Car("Saab 900", 1984, "Saab");
Console.WriteLine(car1);
Console.WriteLine(car2);
Console.WriteLine(car3);
}
}
Open 'D:\csharp-projects' from 'cmd'(the command prompt) and run command:
csc-roslyn /target:exe /out:Autoservice.exe Vehicle.cs Car.cs Autoservice.cs
Run from 'cmd':
Autoservice.exe
Result should be:
Ford Taunus, 1971, Ford
Opel Ascona, 1978, Opel
Saab 900, 1984, Saab
I suspect the location of the Roslyn compiler moves around a lot based on the Visual Studio you're running.
I was able to find mine by performing a search like this:
cd "\Program Files (x86)"
dir /s csc*.* | findstr Roslyn
My particular csc.exe was located in:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn\csc.exe
I have some unit tests that use Azure Storage. When running these locally, I want them to use the Azure Storage emulator which is part of the Azure SDK v1.5. If the emulator isn't running, I want it to be started.
To start the emulator from the command line, I can use this:
"C:\Program Files\Windows Azure SDK\v1.5\bin\csrun" /devstore
This works fine.
When I try to start it using this C# code, it crashes:
using System.IO;
using System.Diagnostics;
...
ProcessStartInfo processToStart = new ProcessStartInfo()
{
FileName = Path.Combine(SDKDirectory, "csrun"),
Arguments = "/devstore"
};
Process.Start(processToStart);
I've tried fiddling with a number of ProcessStartInfo settings, but nothing seems to work. Is anybody else having this problem?
I've checked the Application Event Log and found the following two entries:
Event ID: 1023
.NET Runtime version 2.0.50727.5446 - Fatal Execution Engine Error (000007FEF46B40D2) (80131506)
Event ID: 1000
Faulting application name: DSService.exe, version: 6.0.6002.18312, time stamp: 0x4e5d8cf3
Faulting module name: mscorwks.dll, version: 2.0.50727.5446, time stamp: 0x4d8cdb54
Exception code: 0xc0000005
Fault offset: 0x00000000001de8d4
Faulting process id: 0x%9
Faulting application start time: 0x%10
Faulting application path: %11
Faulting module path: %12
Report Id: %13
Updated 7/12/2022:
If you are running Visual Studio 2022, azurite.exe is the replacement for the now-deprecated AzureStorageEmulator.exe which can be found here:
C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\Extensions\Microsoft\Azure Storage Emulator\azurite.exe
NB: if you are running Professional (or another) Edition, you'll need to replace Community with Professional (or the appropriate edition name) in the path.
Updated 1/19/2015:
After doing more testing (i.e., running several builds), I've discovered that WAStorageEmulator.exe's status API is actually broken in a couple of significant ways (which may or may not have impact on how you use it).
The status reports False even when an existing process is running if the user differs between the existing running process and the user used to launch the status process. This incorrect status report will lead to a failure to launch the process that looks like this:
C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator>WAStorageEmulator.exe status
Windows Azure Storage Emulator 3.4.0.0 command line tool
IsRunning: False
BlobEndpoint: http://127.0.0.1:10000/
QueueEndpoint: http://127.0.0.1:10001/
TableEndpoint: http://127.0.0.1:10002/
C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator>WAStorageEmulator.exe start
Windows Azure Storage Emulator 3.4.0.0 command line tool
Error: Port conflict with existing application.
Additionally, the status command appears only to report the endpoints specified in WAStorageEmulator.exe.config, not those of the existing running process. I.e., if you start the emulator, then make a change to the config file, and then call status, it will report the endpoints listed in the config.
Given all of these caveats, it may, in fact, simply be better to use the original implementation as it appears to be more reliable.
I will leave both so others can choose whichever solution works for them.
Updated 1/18/2015:
I have fully rewritten this code to properly leverage WAStorageEmulator.exe's status API per #RobertKoritnik's request.
public static class AzureStorageEmulatorManager
{
public static bool IsProcessRunning()
{
bool status;
using (Process process = Process.Start(StorageEmulatorProcessFactory.Create(ProcessCommand.Status)))
{
if (process == null)
{
throw new InvalidOperationException("Unable to start process.");
}
status = GetStatus(process);
process.WaitForExit();
}
return status;
}
public static void StartStorageEmulator()
{
if (!IsProcessRunning())
{
ExecuteProcess(ProcessCommand.Start);
}
}
public static void StopStorageEmulator()
{
if (IsProcessRunning())
{
ExecuteProcess(ProcessCommand.Stop);
}
}
private static void ExecuteProcess(ProcessCommand command)
{
string error;
using (Process process = Process.Start(StorageEmulatorProcessFactory.Create(command)))
{
if (process == null)
{
throw new InvalidOperationException("Unable to start process.");
}
error = GetError(process);
process.WaitForExit();
}
if (!String.IsNullOrEmpty(error))
{
throw new InvalidOperationException(error);
}
}
private static class StorageEmulatorProcessFactory
{
public static ProcessStartInfo Create(ProcessCommand command)
{
return new ProcessStartInfo
{
FileName = #"C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator\WAStorageEmulator.exe",
Arguments = command.ToString().ToLower(),
RedirectStandardOutput = true,
RedirectStandardError = true,
UseShellExecute = false,
CreateNoWindow = true
};
}
}
private enum ProcessCommand
{
Start,
Stop,
Status
}
private static bool GetStatus(Process process)
{
string output = process.StandardOutput.ReadToEnd();
string isRunningLine = output.Split(new[] { Environment.NewLine }, StringSplitOptions.RemoveEmptyEntries).SingleOrDefault(line => line.StartsWith("IsRunning"));
if (isRunningLine == null)
{
return false;
}
return Boolean.Parse(isRunningLine.Split(':').Select(part => part.Trim()).Last());
}
private static string GetError(Process process)
{
string output = process.StandardError.ReadToEnd();
return output.Split(':').Select(part => part.Trim()).Last();
}
}
And the corresponding tests:
[TestFixture]
public class When_starting_process
{
[Test]
public void Should_return_started_status()
{
if (AzureStorageEmulatorManager.IsProcessRunning())
{
AzureStorageEmulatorManager.StopStorageEmulator();
Assert.That(AzureStorageEmulatorManager.IsProcessRunning(), Is.False);
}
AzureStorageEmulatorManager.StartStorageEmulator();
Assert.That(AzureStorageEmulatorManager.IsProcessRunning(), Is.True);
}
}
[TestFixture]
public class When_stopping_process
{
[Test]
public void Should_return_stopped_status()
{
if (!AzureStorageEmulatorManager.IsProcessRunning())
{
AzureStorageEmulatorManager.StartStorageEmulator();
Assert.That(AzureStorageEmulatorManager.IsProcessRunning(), Is.True);
}
AzureStorageEmulatorManager.StopStorageEmulator();
Assert.That(AzureStorageEmulatorManager.IsProcessRunning(), Is.False);
}
}
Original post:
I took Doug Clutter's and Smarx's code one step further and created a utility class:
The code below has been updated to work on both Windows 7 and 8 and now points at the new storage emulator path as of SDK 2.4.**
public static class AzureStorageEmulatorManager
{
private const string _windowsAzureStorageEmulatorPath = #"C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator\WAStorageEmulator.exe";
private const string _win7ProcessName = "WAStorageEmulator";
private const string _win8ProcessName = "WASTOR~1";
private static readonly ProcessStartInfo startStorageEmulator = new ProcessStartInfo
{
FileName = _windowsAzureStorageEmulatorPath,
Arguments = "start",
};
private static readonly ProcessStartInfo stopStorageEmulator = new ProcessStartInfo
{
FileName = _windowsAzureStorageEmulatorPath,
Arguments = "stop",
};
private static Process GetProcess()
{
return Process.GetProcessesByName(_win7ProcessName).FirstOrDefault() ?? Process.GetProcessesByName(_win8ProcessName).FirstOrDefault();
}
public static bool IsProcessStarted()
{
return GetProcess() != null;
}
public static void StartStorageEmulator()
{
if (!IsProcessStarted())
{
using (Process process = Process.Start(startStorageEmulator))
{
process.WaitForExit();
}
}
}
public static void StopStorageEmulator()
{
using (Process process = Process.Start(stopStorageEmulator))
{
process.WaitForExit();
}
}
}
This program worked fine for me. Give it a try, and if it works for you too, work backwards from there. (What about your app is different from this?)
using System.Diagnostics;
public class Program
{
public static void Main() {
Process.Start(#"c:\program files\windows azure sdk\v1.5\bin\csrun", "/devstore").WaitForExit();
}
}
The file name in v4.6 is "AzureStorageEmulator.exe". The full path is: "C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator\AzureStorageEmulator.exe"
For Windows Azure Storage Emulator v5.2, the following helper class can be used to start the emulator:
using System.Diagnostics;
public static class StorageEmulatorHelper {
/* Usage:
* ======
AzureStorageEmulator.exe init : Initialize the emulator database and configuration.
AzureStorageEmulator.exe start : Start the emulator.
AzureStorageEmulator.exe stop : Stop the emulator.
AzureStorageEmulator.exe status : Get current emulator status.
AzureStorageEmulator.exe clear : Delete all data in the emulator.
AzureStorageEmulator.exe help [command] : Show general or command-specific help.
*/
public enum StorageEmulatorCommand {
Init,
Start,
Stop,
Status,
Clear
}
public static int StartStorageEmulator() {
return ExecuteStorageEmulatorCommand(StorageEmulatorCommand.Start);
}
public static int StopStorageEmulator() {
return ExecuteStorageEmulatorCommand(StorageEmulatorCommand.Stop);
}
public static int ExecuteStorageEmulatorCommand(StorageEmulatorCommand command) {
var start = new ProcessStartInfo {
Arguments = command.ToString(),
FileName = #"C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator\AzureStorageEmulator.exe"
};
var exitCode = executeProcess(start);
return exitCode;
}
private static int executeProcess(ProcessStartInfo startInfo) {
int exitCode = -1;
try {
using (var proc = new Process {StartInfo = startInfo}) {
proc.Start();
proc.WaitForExit();
exitCode = proc.ExitCode;
}
}
catch {
//
}
return exitCode;
}
}
[Thanks to huha for the boilerplate code to execute a shell command.]
FYI - The 1.6 default location is C:\Program Files\Windows Azure Emulator\emulator as stated on the MSDN docs.
We are running into the same issue. We have the concept of a "smoke test" which runs between groups of tests, and which ensure the environment is in a good state before the next group starts. We have a .cmd file that kicks off the smoke tests, and it works just fine starting the devfabric emulator, but the devstore emulator only runs as long as the .cmd process runs.
Apparently the implementation of the DSServiceSQL.exe is different than DFService.exe. DFService seems to run like a windows service - kick it off, and it keeps running. DSServiceSQL dies as soon as the process that started it dies.
I uninstalled all of the Windows Azure bits:
WA SDK v1.5.20830.1814
WA Tools for Visual Studio: v1.5.40909.1602
WA AppFabric: v1.5.37
WA AppFabric: v2.0.224
Then, I downloaded and installed everything using the unified installer. Everything came back except the AppFabric v2. All the version numbers are the same. Reran my tests and still having a problem.
And then...(this is weird)...it would work every now and then. Rebooted the machine and now it works. Have shutdown and rebooted a number of times now...and it just works. (sigh)
Thanks to everyone who provided feedback and/or ideas!
The final code is:
static void StartAzureStorageEmulator()
{
ProcessStartInfo processStartInfo = new ProcessStartInfo()
{
FileName = Path.Combine(SDKDirectory, "csrun.exe"),
Arguments = "/devstore",
};
using (Process process = Process.Start(processStartInfo))
{
process.WaitForExit();
}
}
maybe caused by file not found?
try this
FileName = Path.Combine(SDKDirectory, "csrun.exe")
Here we go: Pass the string "start" to the method ExecuteWAStorageEmulator().
The NUnit.Framework is used for the Assert only.
using System.Diagnostics;
using NUnit.Framework;
private static void ExecuteWAStorageEmulator(string argument)
{
var start = new ProcessStartInfo
{
Arguments = argument,
FileName = #"c:\Program Files (x86)\Microsoft SDKs\Windows Azure\Storage Emulator\WAStorageEmulator.exe"
};
var exitCode = ExecuteProcess(start);
Assert.AreEqual(exitCode, 0, "Error {0} executing {1} {2}", exitCode, start.FileName, start.Arguments);
}
private static int ExecuteProcess(ProcessStartInfo start)
{
int exitCode;
using (var proc = new Process { StartInfo = start })
{
proc.Start();
proc.WaitForExit();
exitCode = proc.ExitCode;
}
return exitCode;
}
See also my new self-answered question
There's now a neat little NuGet package to assist with starting/stopping the Azure Storage Emulator programmatically: RimDev.Automation.StorageEmulator.
The source code is available in this GitHub repository, but you can essentially do things like this:
if(!AzureStorageEmulatorAutomation.IsEmulatorRunning())
{
AzureStorageEmulatorAutomation emulator = new AzureStorageEmulatorAutomation();
emulator.Start();
// Even clear some things
emulator.ClearBlobs();
emulator.ClearTables();
emulator.ClearQueues();
emulator.Stop();
}
It feels like the cleanest option to me.