At the moment I have a visual studio project and I use the docfx.console nuget package to build the documentation, and everything works fine and as expected... on windows. The point is now I want to make a docker image based on mcr.microsoft.com/dotnet/core/sdk:3.1 which is based on a linux image. And compiling in this docker image running the command:
dotnet publish -c Release -o out
Gives the following error
> [build 9/9] RUN dotnet publish -c Release -o out:
#22 1.080 Microsoft (R) Build Engine version 16.0.450+ga8dc7f1d34 for .NET Core
#22 1.080 Copyright (C) Microsoft Corporation. All rights reserved.
#22 1.080
#22 2.852 Restore completed in 215.94 ms for /app/Documentation/Documentation.csproj.
#22 6.299 Documentation -> /app/Documentation/bin/Release/netcoreapp2.1/Documentation.dll
#22 6.402 /bin/sh: 2: /tmp/tmpbd72ebbe5e6b49c1b3244f1f50c8b57a.exec.cmd: /root/.nuget/packages/docfx.console/2.48.1/build/../tools/docfx.exe: Exec format error
#22 6.407 /root/.nuget/packages/docfx.console/2.48.1/build/docfx.console.targets(57,5): error MSB3073: The command ""/root/.nuget/packages/docfx.console/2.48.1/build/../tools/docfx.exe" "/app/Documentation/docfx.json" -o "" -l "log.txt" --logLevel "Verbose"" exited with code 2. [/app/Documentation/Documentation.csproj]
I already did some prodding around and I believe I have the issue mostly solved. Running file on console.exe shows that this is a PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows. And these kind of files should not be executed on linux using sh but with mono. And indeed running:
mono docfx.exe "/app/Documentation/docfx.json" -o "" -l "log.txt" --logLevel "Verbose"
builds the documentation just fine as expected. At this point of course I have a bunch of workarounds to get the documentation building correctly, just remove docfx.console form the csproj and build it manualy from the command line using a docker command.
But the question is, can I also use the nuget package on linux by changing how the docfx.exe command is run by the nuget package? Or is this only possible by actually fixing this in docfx.console?
p.s. in case it matters, the version of docfx.console that I am using is the most recent one available at the time of writing, namely 2.48.1
But the question is, can I also use the nuget package on linux by changing how the docfx.exe command is run by the nuget package? Or is this only possible by actually fixing this in docfx.console?
Create script docfx that runs docfx.exe using Mono, e.g., like this (assuming docfx.exe is located in /opt/docfx/docfx.exe):
echo '#!/bin/bash\nmono /opt/docfx/docfx.exe $#' > /usr/bin/docfx && chmod +x /usr/bin/docfx
Then, pass MSBuild parameter BuildDocToolPath with path to that script, e.g., like this:
dotnet publish -c Release -o out -p:BuildDocToolPath=/usr/bin/docfx
docfx.console will than use this path to execute DocFX. I think the property BuildDocToolPath isn't documented anywhere, but you can see it in source code.
Related
I am unable to publish my .net function app. I am using the below configuration and settings:
.net 5 SDK Version: 5.0.300
Microsoft.Azure.Functions.Worker 1.2.0
Microsoft.Azure.Functions.Worker.Core 1.1.0
Getting below error:
Metadata generation failed. Exit code: '-532462766' Error: 'Error generating extension metadata: System.IO.DirectoryNotFoundException: The path PATH\bin\Release\net5.0\publish\bin does not exist. Unable to generate Azure Functions extensions metadata file.
The problem lies with the .targets file of Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator, it sets the _FunctionsExtensionsDir to the publish target directory + 'bin'
So if you publish to project-path\bin\release\net5.0\publish, it's looking for published output in project-path\bin\release\net5.0\publish\bin - you can prove this by doing a replace all in the .targets file replacing ')bin' with ')' and watching it run as expected.
A quick and dirty solution is to build with the -o flag set to where the metadata generator will expect the output to be, e.g.
dotnet build yourproject.csproj --framework net5.0 -c release -o c:/temp/output/bin -v d
dotnet publish yourproject.csproj --framework net5.0 -c release -o c:/temp/output -v d
I'm currently looking into a less hacky way of achieving this, and will post if/when I figure it out.
This looks like a bug in Visual Studio 2019.
Suggestion:
Record your current version, you can raise a support ticket to confirm with the official.
Upgrade your vs2019 to the latest version and try to publish again.
I've been searching for quite some time now, and can't seem to find an answer to this problem. Found only two questions/answers on SO and they still don't answer this question (https://stackoverflow.com/search?q=netcore+publish+mac+app).
I'm working with DotNetCore on Mac, using Visual Studio as the IDE. The app is a Console App, not an ASP.Net app, simple "Hello World" app in C#:
...
Console.Writeline("Hello World");
...
So here's the question... To run the app, I know I can use the "dotnet" command to run it. I'm trying to build/publish the app, as you normally would do in Windows by creating an .exe file, but now on Mac by creating a native binary file.
I have found zero documentation on how to do this, and deploy the application as a self contained app that can run independently without having to call the program using the "dotnet" command. Maybe I'm looking in the wrong places but haven't even found anything on Microsoft's documentation, they all point to documentation for building ASP.Net apps on .NetCore.
Any suggestions?
Found the answer by looking at the "dotnet publish" options:
dotnet publish -c Release --self-contained -r osx.10.13-x64
Where --self-contained includes all required libraries, and -r specifies the runtime target.
$ dotnet publish -c Release --self-contained -a x64
Determining projects to restore...
Restored /Users/walshca/code/temp/MutexThrow/MutexThrow.csproj (in 155 ms).
MutexThrow -> /Users/walshca/code/temp/MutexThrow/bin/Release/net6.0/osx-x64/MutexThrow.dll
MutexThrow -> /Users/walshca/code/temp/MutexThrow/bin/Release/net6.0/osx-x64/publish/
dotnet publish docs
Then I run ./bin/Release/net6.0/osx-x64/publish/MutexThrow
This didn't specify the --output cli arg, so you can see in the build output it defaulted to [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/
(In dotnet 6.0 instead of -r runtime target, you can specify --arch x86 and it uses the default RID for your system.)
If your project props sets a different build output, can you find the executable by enumerating files by unix file permissions:
$ gci -r -file | ? UnixMode -match 'x$' | % FullName
/Users/walshca/code/temp/MutexThrow/obj/Release/net6.0/osx-x64/apphost
/Users/walshca/code/temp/MutexThrow/bin/Release/net6.0/osx-x64/MutexThrow
/Users/walshca/code/temp/MutexThrow/bin/Release/net6.0/osx-x64/publish/MutexThrow
I've been working on a C# application and wanted to try the GitLab CI out. All I can see is Ruby and can't find any information on how to build a C# application using it.
When I run the test settings, I make the commit, but I don't have my build.
How should I make a simple build? Which command could I use for that? I don't mind if I get a failed build (but a build).
I just wanted to share my .gitlab-ci.yml complete with unit testing. You will have to adjust your nuget and possibly other paths. This is for a single project in a solution of the same name.
variables:
PROJECT_NAME: "ProjectNameGoesHere"
before_script:
- echo "starting build for %PROJECT_NAME%"
- echo "Restoring NuGet Packages..."
- d:\tools\nuget restore "%PROJECT_NAME%.sln"
stages:
- build
- test
build:
stage: build
script:
- echo "Release build..."
- '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "%PROJECT_NAME%.sln"'
artifacts:
untracked: true
test:
stage: test
script:
- echo "starting tests"
- cd %PROJECT_NAME%Tests/bin/Release
- '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe" /testcontainer:%PROJECT_NAME%Tests.dll'
dependencies:
- build
In order to build a C# application you should have a Windows runner (with shell executor) configured for a project in GitLab CI.
Your .gitlab-ci.yml file should look something like that:
stages:
- build
job:
stage: build
script:
- echo "Restoring NuGet Packages..."
- '"c:\nuget\nuget.exe" restore "MySolution.sln"'
- ''
- echo "Release build..."
- C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "MySolution.sln"
tags:
except:
- tags
On a Windows machine you need the following tools:
Runner installed
Git, added to PATH
Latest nuget.exe at C:\nuget (or somewhere else. Just make sure you got the path right in the .gitlab-ci.yml file)
The other answers are good. But I'd like to explain how to install a runner in addition. I use my own local system (Windows), so I chose to run shell. But you could use a Docker image if you'd like.
cd C:\Multi-Runner
gitlab-ci-multi-runner register
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
Please enter the gitlab-ci token for this runner
xxx
Please enter the gitlab-ci description for this runner
my-runner
INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh?
shell
INFO[0037] Runner registered successfully. Feel free to start it, but if it's
running already the config should be automatically reloaded!
Source: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/windows.md
Afterwards, you can use a YAML file a like this:
stages:
- build
job:
stage: build
script: '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" "something.sln"'
Installing the build runner on a Windows machine helps a lot, and #prasanth-louis has a great example on how to do that.
As for the .gitlab-ci.yml file, you can simplify it even more by using Cake Build:
stages:
- build
build:
stage: build
script:
- .\build.ps1 -Target Build
tags:
- windows
And your build.cake file can look like this (based of the example repository):
#tool nuget:?package=NUnit.ConsoleRunner&version=3.4.0
var target = Argument("target", "Default");
var configuration = Argument("configuration", "Release");
var solution = "./example-project.sln";
var buildDir = Directory("./example-project/bin");
Task("Default")
.IsDependentOn("Unit-Tests")
.Does(() =>
{
Information("Running Default task!");
});
Task("Clean")
.Does(() =>
{
CleanDirectory(buildDir);
});
Task("PackageRestore")
.IsDependentOn("Clean")
.Does(() =>
{
Information("Restoring NuGet packages for {0}", solution);
NuGetRestore(solution);
});
Task("Build")
.IsDependentOn("PackageRestore")
.Does(() =>
{
Information("Restoring NuGet packages for {0}", solution);
MSBuild(solution, settings => settings.SetConfiguration(configuration));
});
Task("Unit-Tests")
.IsDependentOn("Build")
.Does(() =>
{
NUnit3("./example-project.Tests/**/bin/" + configuration + "/*.Tests.dll");
});
Task("Publish")
.Does(() =>
{
});
RunTarget(target);
Here my working .gitlab-ci.yml file for c# application with NUnit as unit test framework and mono as basic image.
Not very fancy but working:
image: mono:latest
stages:
- build
- test
variables:
solution: "Project.sln"
test: "Project.Test"
before_script:
- nuget restore
build:
stage: build
script:
- msbuild /p:Configuration=Release $solution
test:
stage: test
script:
- msbuild /p:Configuration=Release $solution
- mono ./packages/NUnit.ConsoleRunner.3.10.0/tools/nunit3-console.exe ./$test/bin/Release/$test.dll
The other answers, while informative, miss a few crucial bits of info:
If you are targetting .net core 3.1, .net 5, .net 6 or any newer version then you can build and run your app on linux
If you are targetting .net framework (4.8 or below) then you have to build and run your code on a windows machine.
Now Gitlab runs build jobs using runners (aka build agents), that in turn use executors to specifiy the environment in which the build process happens. Runners can run on the Gitlab infrastructure (Saas runners), or can be installed on premise. There are several types of executors: docker, shell, custom, ...
Most of the gitlab build scripts that can be found around the internet assume a saas runner with a docker executor running on linux, which is based on a specific docker image. This won't work if you want to build your app on windows. For this, either install your own executor, as several other answers instruct to do, or use a windows saas runner which, although in beta, works fine even for production (we have been doing this for months without trouble). While installing your own runner can be useful, e.g. for debugging purposes, I find this defeats the whole purpose of building your software on a hosted cicd platform (github actions, gitlab ci, ...). For debugging, I prefer to base my build script on shell commands which can be run on your local dev box, which minimizes trial and error and makes installing your own runner superfluous.
To get started with a windows runner, see this exemple script. One or two gotchas that I went through:
You cannot choose the VM image of the build machine, it is managed by Gitlab and its content is not documented. This leaves you vulnerable to breaking changes if they decide to change their image.
Strangely, at the time of writing, the .net framework 4.8 developer pack is not installed on the windows executor image, but luckily chocolatey is, so if you target net48 you must install it in your before_script section.
The provisionning of the build machine is somewhat slower than a linux maching running docker, our builds average 15mn which we find acceptable.
That being said, here is a trimmed example based on our build scripts:
variables:
MSBUILD_EXE: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin\msbuild.exe'
UPDATE_VERSION: '.\path\to\Update-Version.ps1'
APP_FOLDER: '.\path\to\Artifacts\_PublishedWebsites\MyApp\'
.windows_build_base:
tags:
- shared-windows
- windows
- windows-1809
before_script:
- Set-Variable -Name "time" -Value (date -Format "%H:%m")
- echo ${time}
- echo "started by ${GITLAB_USER_NAME}"
- echo ".NET versions already installed"
- Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*", "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
| Where {$_.DisplayName -like '*.NET*' -and $_.DisplayVersion -like '4.*'}
| Select-Object DisplayName, DisplayVersion
- echo "Installing .NET 4.8 Developer Pack"
- choco install netfx-4.8-devpack -y
stages:
- build
- publish
build:
only:
- prod
- test
extends:
- .windows_build_base
stage: build
script:
- nuget restore
- '& "${UPDATE_VERSION}" -srcDir . | Set-Variable -Name VERSION' # capture output of UPDATE_PRODUCTINFO script in variable VERSION
- echo "VERSION=${VERSION}"
- Add-Content -Path app_version.env -Value "VERSION=${VERSION}" # store value of VERSION in dotenv file to be passed to dependent stages, as per this workaround https://gitlab.com/gitlab-org/gitlab/-/issues/212629#note_430278657
- Get-Content app_version.env
- '& "${MSBUILD_EXE}" /t:solution_path\to\MyApp /p:Configuration=Release /clp:Summary /verbosity:Minimal /p:OutDir=.\Artifacts'
artifacts:
expire_in: 1 day
paths:
- '${APP_FOLDER}'
reports:
dotenv: app_version.env
publish:
only:
- prod
- test
image:
name: octopusdeploy/octo
entrypoint: [""]
stage: publish
dependencies:
- build
script:
- echo "VERSION=$VERSION"
- octo pack --id="MyApp" --format="zip" --version="$VERSION" --basePath="path/to/Artifacts/_PublishedWebsites/MyApp" --outFolder="/output/"
- octo push --overwrite-mode="OverwriteExisting" --server="https://mycompany.octopus.app" --space "MyOctoSpace" --package="/output/MyApp.$VERSION.zip"
This script:
Installs .net 4.8 dev pack
Restores nuget packages
Manually updates the software version and passes it between the build and publish stages
Builds the app
Packs and pushes it to octopus deploy
I've been working on a C# application and wanted to try the GitLab CI out. All I can see is Ruby and can't find any information on how to build a C# application using it.
When I run the test settings, I make the commit, but I don't have my build.
How should I make a simple build? Which command could I use for that? I don't mind if I get a failed build (but a build).
I just wanted to share my .gitlab-ci.yml complete with unit testing. You will have to adjust your nuget and possibly other paths. This is for a single project in a solution of the same name.
variables:
PROJECT_NAME: "ProjectNameGoesHere"
before_script:
- echo "starting build for %PROJECT_NAME%"
- echo "Restoring NuGet Packages..."
- d:\tools\nuget restore "%PROJECT_NAME%.sln"
stages:
- build
- test
build:
stage: build
script:
- echo "Release build..."
- '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "%PROJECT_NAME%.sln"'
artifacts:
untracked: true
test:
stage: test
script:
- echo "starting tests"
- cd %PROJECT_NAME%Tests/bin/Release
- '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe" /testcontainer:%PROJECT_NAME%Tests.dll'
dependencies:
- build
In order to build a C# application you should have a Windows runner (with shell executor) configured for a project in GitLab CI.
Your .gitlab-ci.yml file should look something like that:
stages:
- build
job:
stage: build
script:
- echo "Restoring NuGet Packages..."
- '"c:\nuget\nuget.exe" restore "MySolution.sln"'
- ''
- echo "Release build..."
- C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe /consoleloggerparameters:ErrorsOnly /maxcpucount /nologo /property:Configuration=Release /verbosity:quiet "MySolution.sln"
tags:
except:
- tags
On a Windows machine you need the following tools:
Runner installed
Git, added to PATH
Latest nuget.exe at C:\nuget (or somewhere else. Just make sure you got the path right in the .gitlab-ci.yml file)
The other answers are good. But I'd like to explain how to install a runner in addition. I use my own local system (Windows), so I chose to run shell. But you could use a Docker image if you'd like.
cd C:\Multi-Runner
gitlab-ci-multi-runner register
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
Please enter the gitlab-ci token for this runner
xxx
Please enter the gitlab-ci description for this runner
my-runner
INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh?
shell
INFO[0037] Runner registered successfully. Feel free to start it, but if it's
running already the config should be automatically reloaded!
Source: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/windows.md
Afterwards, you can use a YAML file a like this:
stages:
- build
job:
stage: build
script: '"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" "something.sln"'
Installing the build runner on a Windows machine helps a lot, and #prasanth-louis has a great example on how to do that.
As for the .gitlab-ci.yml file, you can simplify it even more by using Cake Build:
stages:
- build
build:
stage: build
script:
- .\build.ps1 -Target Build
tags:
- windows
And your build.cake file can look like this (based of the example repository):
#tool nuget:?package=NUnit.ConsoleRunner&version=3.4.0
var target = Argument("target", "Default");
var configuration = Argument("configuration", "Release");
var solution = "./example-project.sln";
var buildDir = Directory("./example-project/bin");
Task("Default")
.IsDependentOn("Unit-Tests")
.Does(() =>
{
Information("Running Default task!");
});
Task("Clean")
.Does(() =>
{
CleanDirectory(buildDir);
});
Task("PackageRestore")
.IsDependentOn("Clean")
.Does(() =>
{
Information("Restoring NuGet packages for {0}", solution);
NuGetRestore(solution);
});
Task("Build")
.IsDependentOn("PackageRestore")
.Does(() =>
{
Information("Restoring NuGet packages for {0}", solution);
MSBuild(solution, settings => settings.SetConfiguration(configuration));
});
Task("Unit-Tests")
.IsDependentOn("Build")
.Does(() =>
{
NUnit3("./example-project.Tests/**/bin/" + configuration + "/*.Tests.dll");
});
Task("Publish")
.Does(() =>
{
});
RunTarget(target);
Here my working .gitlab-ci.yml file for c# application with NUnit as unit test framework and mono as basic image.
Not very fancy but working:
image: mono:latest
stages:
- build
- test
variables:
solution: "Project.sln"
test: "Project.Test"
before_script:
- nuget restore
build:
stage: build
script:
- msbuild /p:Configuration=Release $solution
test:
stage: test
script:
- msbuild /p:Configuration=Release $solution
- mono ./packages/NUnit.ConsoleRunner.3.10.0/tools/nunit3-console.exe ./$test/bin/Release/$test.dll
The other answers, while informative, miss a few crucial bits of info:
If you are targetting .net core 3.1, .net 5, .net 6 or any newer version then you can build and run your app on linux
If you are targetting .net framework (4.8 or below) then you have to build and run your code on a windows machine.
Now Gitlab runs build jobs using runners (aka build agents), that in turn use executors to specifiy the environment in which the build process happens. Runners can run on the Gitlab infrastructure (Saas runners), or can be installed on premise. There are several types of executors: docker, shell, custom, ...
Most of the gitlab build scripts that can be found around the internet assume a saas runner with a docker executor running on linux, which is based on a specific docker image. This won't work if you want to build your app on windows. For this, either install your own executor, as several other answers instruct to do, or use a windows saas runner which, although in beta, works fine even for production (we have been doing this for months without trouble). While installing your own runner can be useful, e.g. for debugging purposes, I find this defeats the whole purpose of building your software on a hosted cicd platform (github actions, gitlab ci, ...). For debugging, I prefer to base my build script on shell commands which can be run on your local dev box, which minimizes trial and error and makes installing your own runner superfluous.
To get started with a windows runner, see this exemple script. One or two gotchas that I went through:
You cannot choose the VM image of the build machine, it is managed by Gitlab and its content is not documented. This leaves you vulnerable to breaking changes if they decide to change their image.
Strangely, at the time of writing, the .net framework 4.8 developer pack is not installed on the windows executor image, but luckily chocolatey is, so if you target net48 you must install it in your before_script section.
The provisionning of the build machine is somewhat slower than a linux maching running docker, our builds average 15mn which we find acceptable.
That being said, here is a trimmed example based on our build scripts:
variables:
MSBUILD_EXE: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin\msbuild.exe'
UPDATE_VERSION: '.\path\to\Update-Version.ps1'
APP_FOLDER: '.\path\to\Artifacts\_PublishedWebsites\MyApp\'
.windows_build_base:
tags:
- shared-windows
- windows
- windows-1809
before_script:
- Set-Variable -Name "time" -Value (date -Format "%H:%m")
- echo ${time}
- echo "started by ${GITLAB_USER_NAME}"
- echo ".NET versions already installed"
- Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*", "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
| Where {$_.DisplayName -like '*.NET*' -and $_.DisplayVersion -like '4.*'}
| Select-Object DisplayName, DisplayVersion
- echo "Installing .NET 4.8 Developer Pack"
- choco install netfx-4.8-devpack -y
stages:
- build
- publish
build:
only:
- prod
- test
extends:
- .windows_build_base
stage: build
script:
- nuget restore
- '& "${UPDATE_VERSION}" -srcDir . | Set-Variable -Name VERSION' # capture output of UPDATE_PRODUCTINFO script in variable VERSION
- echo "VERSION=${VERSION}"
- Add-Content -Path app_version.env -Value "VERSION=${VERSION}" # store value of VERSION in dotenv file to be passed to dependent stages, as per this workaround https://gitlab.com/gitlab-org/gitlab/-/issues/212629#note_430278657
- Get-Content app_version.env
- '& "${MSBUILD_EXE}" /t:solution_path\to\MyApp /p:Configuration=Release /clp:Summary /verbosity:Minimal /p:OutDir=.\Artifacts'
artifacts:
expire_in: 1 day
paths:
- '${APP_FOLDER}'
reports:
dotenv: app_version.env
publish:
only:
- prod
- test
image:
name: octopusdeploy/octo
entrypoint: [""]
stage: publish
dependencies:
- build
script:
- echo "VERSION=$VERSION"
- octo pack --id="MyApp" --format="zip" --version="$VERSION" --basePath="path/to/Artifacts/_PublishedWebsites/MyApp" --outFolder="/output/"
- octo push --overwrite-mode="OverwriteExisting" --server="https://mycompany.octopus.app" --space "MyOctoSpace" --package="/output/MyApp.$VERSION.zip"
This script:
Installs .net 4.8 dev pack
Restores nuget packages
Manually updates the software version and passes it between the build and publish stages
Builds the app
Packs and pushes it to octopus deploy
As per suggestions from this thread on running C# apps sans .NET I've compiled my app using mono. I built the original app using the latest Visual C# .NET Express Edition. It runs fine on .NET on Windows. I then opened up Cygwin and navigated to my source where I compiled the project again, under mono using the following command:
$ mcs <myProjectHere>.cs
This produces MyProject.exe, which can be run from within Cygwin with success, and can be run from the Window command line successfully. Commands used are:
$ mono MyProject.exe
C:\...>mono MyProject.exe
and just for kicks, simply:
C:\...>MyProject.exe
All work as expected. I then tried to build the mono compiled executable into a statically linked binary using the mkbundle command as follows:
$ mkbundle -o MyProject MyProject.exe --deps
This is where things begin to go downhill. It starts off well enough and then complains that the output file (presumably, MyProject.exe) cannot be opened because it is busy. The full output of it all is here:
$ mkbundle -o Program Program.exe --deps
OS is: Windows
Sources: 1 Auto-dependencies: True
embedding: c:\Documents and Settings\bsweeney\My Documents\Visual Studio 2008
\Projects\TestConsole\TestConsole\Program.exe
embedding: C:\PROGRA~1\Mono-2.2\lib\mono\2.0\mscorlib.dll
Compiling:
as -o temp.o temp.s
gcc -mno-cygwin -g -o Program -Wall temp.c `pkg-config --cflags --libs mono|dos2
unix` temp.o
/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/bin/ld: cannot op
en output file Program.exe: Device or resource busy
collect2: ld returned 1 exit status
[Fail]
I claim that my unix gcc toolchain is installed and in good condition because I've been able to successfully compile a few c++ apps in eclipse using it recently (although i supposed i should be open to any number of problems...).
Anyone ever run into anything like this? I'm stumped...
It seems like it's trying to output into MyProject.exe, which is the same as the input file.
Try running
$ mkbundle -o ProgramOutput Program.exe --deps
This is just a guess, by the way, since I don't know mkbundle.