Develop Reference

Process terminated. Couldn't find a valid ICU package installed on the system in Asp.Net Core 3 - ubuntu

I am trying to run a Asp.Net Core 3 application in Ubuntu 19.10 thru terminal using dotnet run command but it does not seem to work. I get this error.
Process terminated. Couldn't find a valid ICU package installed on the system.
Set the configuration flag System.Globalization.Invariant to true if you want
to run with no globalization support.
at System.Environment.FailFast(System.String)
at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
at System.Globalization.GlobalizationMode..cctor()
at System.Globalization.CultureData.CreateCultureWithInvariantData()
at System.Globalization.CultureData.get_Invariant()
at System.Globalization.CultureInfo..cctor()
at System.StringComparer..cctor()
at System.StringComparer.get_OrdinalIgnoreCase()
at Microsoft.Extensions.Configuration.ConfigurationProvider..ctor()
at Microsoft.Extensions.Configuration.EnvironmentVariables.EnvironmentVariablesConfigurationSource.Build(Microsoft.Extensions.Configuration.IConfigurationBuilder)
at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder..ctor(Microsoft.Extensions.Hosting.IHostBuilder)
at Microsoft.Extensions.Hosting.GenericHostWebHostBuilderExtensions.ConfigureWebHost(Microsoft.Extensions.Hosting.IHostBuilder, System.Action'1<Microsoft.AspNetCore.Hosting.IWebHostBuilder>)
at Microsoft.Extensions.Hosting.GenericHostBuilderExtensions.ConfigureWebHostDefaults(Microsoft.Extensions.Hosting.IHostBuilder, System.Action'1<Microsoft.AspNetCore.Hosting.IWebHostBuilder>)
at WebApplication.Program.CreateHostBuilder(System.String[])
at WebApplication.Program.Main(System.String[])
I installed the dotnet core sdk using the ubuntu store and after that I also installed Rider IDE.
The weird thing here is that when I run the app using Rider it runs fine, the only issue is using terminal dotnet core commands.
Does anybody know what might be the issue ?
The application is created using Rider. I don't think that this plays a role but just as a side fact.
I know there are also other ways to install dotnet core in ubuntu but since the sdk is available in the ubuntu story I thought it should work out of the box and of course its an easier choice.
Also tried this one but does not seem to work for me. Still the same issue happens after running the commands.

The alternative solution as described in Microsoft documentation is to set environment variable before running your app
export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1

If you want to run with no globalization support, you need to get "System.Globalization.Invariant": true into your published output AppName.runtimeconfig.json file as shown in the example below:
{
"runtimeOptions": {
"tfm": "netcoreapp3.0",
"configProperties": {
"System.GC.Server": true,
"System.Globalization.Invariant": true
}
}
}
You can add it manually every time you deploy by adding or updating the AppName.runtimeconfig.json file. Better yet, add it once to a runtimeconfig.template.json file like this:
{
"configProperties": {
"System.Globalization.Invariant": true
}
}
Make sure that runtimeconfig.template.json is included in build/publish.

It seem the package libicu63 will provide the ico support for dotnet on Linux, at least on Debian'ish distros.
Update:
And it seems it's "missing" when doing a small installing of Debian (i.e. deselect all applications/system-options in the installation program, except for SSH server)

The trick around it on Ubuntu 20.04 based on this thread https://github.com/dotnet/core/issues/2186#issuecomment-671105420
$export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1

Yes. When installing Github action in Debian. It is also required.
As the response from MrCalvin,
sudo apt-get update && sudo apt-get install -qqq libicu63 resolve my issue.

edit your .bashrc file by adding the following line, e.g.:
nano ~/.bashrc
add
export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1
Ctrl+o, Ctrl+x
restart terminal and run pwsh again

I had this issue while trying to run Umbraco version 9.2.0. Fiddling with System.Globalization.Invariant was not a good solution as it broke globalization in the backoffice. This issue has been solved in v9.4: https://github.com/umbraco/Umbraco-CMS/pull/11961
I didn't want to upgrade my Umbraco version to solve this, so I just copied the change in that commit to my project.
Simply go into the .csproj file of your web project and change the ICU package reference lines to:
<!-- Force windows to use ICU. Otherwise Windows 10 2019H1+ will do it, but older windows 10 and most if not all winodws servers will run NLS -->
<ItemGroup>
<PackageReference Include="Microsoft.ICU.ICU4C.Runtime" Version="68.2.0.9" />
<RuntimeHostConfigurationOption
Condition="$(RuntimeIdentifier.StartsWith('linux')) Or $(RuntimeIdentifier.StartsWith('win')) Or ('$(RuntimeIdentifier)' == '' And !$([MSBuild]::IsOSPlatform('osx')))"
Include="System.Globalization.AppLocalIcu"
Value="68.2.0.9" />
</ItemGroup>

In my case, I followed the Windows documentation to install SDK dependencies and Runtime, watch out for the corresponding version to each Linux distribution to avoid compatibility issues.

This helped me override the default ICU version to the one that's installed on the machine running arch linux.
export CLR_ICU_VERSION_OVERRIDE=$(pacman -Q icu | awk '{split($0,a," ");print a[2]}' | awk '{split($0,a,"-");print a[1]}')

DotNet core 3.0 compilation issues in VSCode

I am new to DotnetCore and MS programming. With the new push from MS to be more platform neutral, I had an interest in me to try it out and see if it works the way it promises. That said, I have had problem even getting a helloworld program work on DotNetCore on windows from VSCode. Everything seems to work fine on my command prompt and VisualStudio 2019, my mac's VS Studio for mac. Real strain seems to be on VSCode in Windows 10. I'd appreciate all your help, if you can
The error I receive is "Cannot find debug adapter for type coreclr". No matter what I do, I end up with this error.
1. INstalled Dotnet core 3.0
2. Set up MSBuildSDKsPath env variable that points to C:\Program Files\dotnet\sdk\3.0.100\Sdks
3. Restarted machine as many times
Nothing works. Here's the sample code as well as my launch.json.
using System;
namespace OOPExample
{
public struct Dimensions {
public double Length { get; }
public double Width { get; }
public Dimensions(double length, double width) {
Length = length;
Width= width;
}
public double Diagonal => Math.Sqrt(Length * Length + Width * Width);
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine($"Hello World - {new Dimensions(10.0, 15.0).Diagonal}");
}
}
}
Here's my launch.json
{
// Use IntelliSense to find out which attributes exist for C# debugging
// Use hover for the description of the existing attributes
// For further information visit https://github.com/OmniSharp/omnisharp-vscode/blob/master/debugger-launchjson.md
"version": "0.2.0",
"configurations": [
{
"name": ".NET Core Launch (console)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
// If you have changed target frameworks, make sure to update the program path.
"program": "${workspaceFolder}/bin/Debug/netcoreapp3.0/OOPExample.dll",
"args": [],
"cwd": "${workspaceFolder}",
// For more information about the 'console' field, see https://aka.ms/VSCode-CS-LaunchJson-Console
"console": "internalConsole",
"stopAtEntry": false
},
{
"name": ".NET Core Attach",
"type": "coreclr",
"request": "attach",
"processId": "${command:pickProcess}"
}
]
}
When I execute dotnet build and dotnet run from command prompt, everything is fine
dotnet build:
C:\Users\Krishnan\Projects\DotNet\OOPExample> dotnet build
Microsoft (R) Build Engine version 16.3.0+0f4c62fea for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 12.86 ms for C:\Users\Krishnan\Projects\DotNet\OOPExample\OOPExample.csproj.
OOPExample -> C:\Users\Krishnan\Projects\DotNet\OOPExample\bin\Debug\netcoreapp3.0\OOPExample.dll
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.77
dotnet run:
PS C:\Users\Krishnan\Projects\DotNet\OOPExample> dotnet run
Hello World - 18.027756377319946
If you are wondering how I created this project, it was nothing more than a simple
dotnet new console command. So nothing fancy

Maybe this can help someone having this problem: Twice in the past week I have resolved this error.
First time by uninstalling/re-installing the OmniSharp C# extension.
Second time by updating VSCode to latest.
I haven't figured out if the two things are related, but I don't see anything in OmniSharp or VSC release notes about it specifically.

first of all, ensure that you had install official Microsoft C# extension for vs-code.
then, if still doesn't run it would be a problem with your launch.json file.

The following error message appeared when I tried to start debugging.
"Cannot find debug adapter for type 'coreclr'".
If the following error message was appearing too, like in my case, I'd recommend you to also consider to click on "Developer Tools" because I think there's a very good chance that you would be able to get a good hint there.
"Extension host terminated unexpectedly".
In the box of the above message, I clicked "Developer Tools" and then I could see some error messages containing a string "kite" that made me guess that, in my case, these error messages could've been coming from the extension "kite" that I had installed a long time ago. After disabling this extension and restarting VS Code, neither error message appeared again. (Now I'm not sure if restarting was essential.) I'm not saying that the extension kite is troublesome. In your case, the problem could've been coming from some other extensions or something other than an extension. I'm saying that the "Developer Tools" could be a goldmine of hints.
I've one more piece of happy news. Later on, these error messages didn't appear even after enabling this extension "kite". I could start debugging without giving up this extension.

I was getting OPs error message, but only when using Run & Debug with ".NET Core Launch (web)" configuration in a Dev Container:
Couldn't find a debug adapter descriptor for debug type 'coreclr' (extension might have failed to activate)
I noticed in VS Code's Output tab, on the C# console, the following additional output:
Installing C# dependencies...
Platform: linux, x86_64, name=ubuntu, version=20.04
Downloading package 'OmniSharp for Linux (x64)'
Retrying from 'https://roslynomnisharp.blob.core.windows.net/releases/1.37.8/omnisharp-linux-x64-1.37.8.zip'
Failed at stage: downloadPackage
Error: Failed to establish a socket connection to proxies: ["PROXY 127.0.0.1:8118"]
It seems that the Dev Container picks up the HTTP_PROXY and HTTPS_PROXY environment variables from the host but, being a guest container, its 127.0.0.1 address is different than the host computer's 127.0.0.1 address.
I fixed this by way of Windows-Pause > Advanced System Settings > Advanced > Environment Variables... > with the host computer's "public" IP address as returned from ipconfig /all, e.g.:
HTTP_PROXY = http://192.168.0.111:8118/
HTTPS_PROXY = http://192.168.0.111:8118/
Followed by closing and reopening VS Code, with Run & Debug now working as expected in the Dev Container.

I had the same problem, I just uninstalled the Omnisharp and all extensions from dotnet, closed the VSCode and after reopened it, and install everything again(package Omnisharp). Now is working as expected.
Just to let registered my SO is Linux Ubuntu 20.04.

I had my share of this debug error today. The following steps I took to resolve the issue might be helpful to someone.
Uninstalled "C# for Visual Studio Code (powered by OmniSharp)" and then installed it back.
Closed Visual Studio Code
Restarted VS Code
Launched the debug button
I hope this is helpful!

I was also getting same error after running dotnet clean
-i simply closed vscode
-then open vscode
-dotnet restore
-dotnet build
my error solved

.NetCore for Mac - Publish to Native Mac App/Binary?

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

How to run .net console application (built on windows) on Linux using .net core [duplicate]

I have a simple .NET Core project (console app) that I'm trying to compile and run. dotnet build succeeds, but I get the following error when I do dotnet run:
dotnet run
Project RazorPrecompiler (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in [path].
My project.json looks like this:
{
"buildOptions": {
"warningsAsErrors": true
},
"dependencies": {
"Microsoft.AspNetCore.Razor": "1.0.0",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"description": "Precompiles Razor views.",
"frameworks": {
"netcoreapp1.0": {
"imports": [ ]
}
},
"version": "1.2.0"
}
What is hostpolicy.dll, and why is it missing?

Update for dotnet core 2.0 and beyond: the file appname.runtimeconfig.json (for both debug and release configuration) is needed in the same path as appname.dll.
It contains:
{
"runtimeOptions": {
"tfm": "netcoreapp2.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "2.0.0"
}
}
}
then dotnet.exe exec "path/to/appname.dll" [appargs] works.

This error message is unhelpful. The actual problem is a missing emitEntryPoint property:
"buildOptions": {
...
"emitEntryPoint": true
},
Once this is added, the compiler will let you know about any other problems (like a missing static void Main() method). Successfully compiling the project will result in an output that dotnet run can execute.

If I'm not mistaken, one scenario when you can hit the issue is this: You have an integration project that references another application project (not library). In this case, dependentProject.runtimeconfig.json won't be copied to your integration project's output folder and you won't be able to run dependentProject.exe binary because it will throw The library hostpolicy.dll was not found..
There is a Github issue for this and a workaround.
Edit: Should be fixed in .NET SDK 5.0.200.

I had similar problem running tests in VS19.
========== Starting test run ==========
Testhost process exited with error: A fatal error was encountered. The
library 'hostpolicy.dll' required to execute the application was not
found in 'C:\Program Files\dotnet'. Failed to run as a self-contained
app.
After digging into it I found the source of the problem:
The full path the the .runtimeconfig.json in the test binary folder was above 255 characters. Renaming the module, so the file path becomes shorter, resolved the problem.

This occurred when a Visual Studio 2019 preview upgrade .Net Core to the latest preview (specifically .Net Core 3.1.100-preview2-014569).
Reinstalling/repairing .Net Core 3.0.100 solved the problem for me.

I'm not sure why but I ran in to the problem when executing the .exe file in my \bin folder while the .exe in my \obj folder works fine.

I am having this problem in Dotnet Core 3.1 Console application.
If you are publishing your application, make sure that your target runtime set to the specific runtime that you had installed in your target machine.
If you set to portable it will pick whatever runtime that it feels comfortable (which you might not have it installed)

I had this happen with .NET 6.0 where somehow the appname.runtimeconfig.dev.json file was not being generated in the bin/Debug/net6.0/ directory.
The fix was modifying the .csproj file and include this fragment inside the <PropertyGroup> element:
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
I found this solution while searching with https://www.google.com/search?q=net60+runtimeconfig.dev.json at Breaking change: runtimeconfig.dev.json file not generated - .NET | Microsoft Learn with the solution at MSBuild properties for Microsoft.NET.Sdk - .NET | Microsoft Learn:
GenerateRuntimeConfigDevFile
Starting with the .NET 6 SDK, the [Appname].runtimesettings.dev.json file is no longer generated by default at compile time. If you still want this file to be generated, set the GenerateRuntimeConfigDevFile property to true.
<PropertyGroup>
<GenerateRuntimeConfigDevFile>true</GenerateRuntimeConfigDevFile>
</PropertyGroup>
After applying this to the .csproj file and re-building the project, debugging from Visual Studio Code worked fine including stopping at the breakpoints that I had set previously.

For me the issue was with the version mismatch. I had a different ".Net core SDK" version installed and a different version was specified in .json file.
Once I modified the version in my .json file the application started working fine.

In my case it was because I was publishing a self-contained application for the wrong target. My intent was to run on alpine linux, but I was building for libc when I should have been building for musl.
The failing package was built using:
dotnet publish --self-contained true --runtime linux-x64 --framework netcoreapp2.1 --output /app
Changing the RID:
dotnet publish --self-contained true --runtime linux-musl-x64 --framework netcoreapp2.1 --output /app
produced a functional package. Notice the RID changed from linux-x64 to linux-musl-x64. If I had read the .NET Core RID Catalog page this could have been avoided. 😅

Maybe you didn't want to do a "Console .Net Core" project but a "Console .Net Framework" project. It solves the problem, for me...

My problem was that I have 2 .NET Core App projects and one is dependent on the other.
(so I can then execute that application from that other application)
But .NET Core applications (with default config) need <assembly name>.runtimeconfig.json file (to get some launch config) which isn't copied by default.
The only solution that worked for me was adding to Project Properties > Build Events (of the dependent project) this command:
COPY "$(SolutionDir)<dependency name>\$(OutDir)<dependency assymbly name>.runtimeconfig.json" "$(SolutionDir)$(ProjectName)\$(OutDir)" /Y
But you can also copy the <dependency assembly name>.runtimeconfig.json file by hand to the dependent project.
Note that there should be a better more generic way to do this for every .NET Core App Project automatically.

This error is quite generic. So the real problem can be anything.
In my case (if helps anyone with same issue), I created a Class Library project instead of a Console Application project.
A Class Library DLL can't be runned with MSBuild, even if it has a Main method.
Only Console Application DDL can be runned as dotnet <appname>.dll

I was getting similar error while running Unit tests using VSTest#2 task in Azure Devops.
In my case, the problem was with my testAssemblyVer2 value. I was giving wrong pattern for test dlls.
Below one worked for me.(if you are getting this error with VSTest)
- task: VSTest#2
displayName: 'Running UnitTests'
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
$(System.DefaultWorkingDirectory)\SrcFolder\BBBB.UnitTests\**\bin\**\*.BBBB.UnitTests.dll
$(System.DefaultWorkingDirectory)\SrcFolder\AAAAa.UnitTests\**\bin\**\*.AAAA.UnitTests.dll
!**\*TestAdapter.dll
!**\obj\**
platform: x64
configuration: Debug
codeCoverageEnabled: true
So try to give correct pattern value for testAssemblyVer2 input. Make sure its filtering only the required dlls.

I had this same problem with a .NET Core 3.0 WPF app, but I found that my app wouldn't run in Visual Studio 2019 either.
I discovered on the project properties page (right-click on project > Properties) that the Target framework was set to .NET Core 3.0.
I'd recently updated VS 2019 which had also installed .NET Core 3.1, so I switched to that in the dropdown, and it worked again.
(I also had to update my shortcut to point to the netcoreapp3.1 folder instead of the previous netcoreapp3.0 folder.)

Promoting voltrevo's comment as an answer as I believe this should be the most common case of the problem. When you build your solution, sometimes you might get 2 directories with outputs bin and obj. 'Bin' directory has everything that is needed to run dotnet.exe command. Just run from the bin directory and things should be good. :)

For me with ASP.NET Core 2.0 on Azure, it was the appname.deps.json that did the trick. You need to copy it from your build directory to Azure.

For me, the error occurred during the SonarQube coverage scan due to one of the projects had a project reference to a MSTest project.

I faced this problem and it took me couple of days to figure out the solution.
Go to Visual Studio Installer.
Click on 'More' option of the Visual Studio.
Select 'Repair'.
It'll take some time for the download and installation.
Once it's completed restart the machine and try again.
This should solve the issue.

Add the OutputType on the PropertyGroup and issue is solved
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
more about this MSBuild can be found here

What are the complete set of steps to fully build a Monotouch app bundle from the command line?

I'd like to know what the complete set of steps is to build a MonoTouch C# app consisting of the main application assembly containing xib files and a set of library assemblies that also possibly contain xib files.
We're trying to automate these steps via a proper MSBuild script (which MonoTouch has yet to support) for various reasons which I won't go into, to focus on the question here.
So far, here's what I've come up with:
1) Compile each assembly using smcs, e.g.
/Developer/MonoTouch/usr/bin/smcs /noconfig
"/out:/Users/bright/src/MonoTouchAppWithLib/AppLib/bin/Debug/AppLib.dll
"/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.dll"
"/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.dll"
"/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.Core.dll"
"/r:/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll"
/nologo /warn:4 /debug:+ /debug:full /optimize- /codepage:utf8
"/define:DEBUG"
/t:library "/Users/bright/src/MonoTouchAppWithLib/AppLib/Class1.cs"
2) Compile interface definitions: run ibtool on each xib file in each assembly, e.g
/Developer/usr/bin/ibtool
--errors --warnings --notices --output-format human-readable-text
"/Users/bright/src/App/App/ViewController_iPhone.xib"
--compile "/Users/bright/src/App/App/bin/Debug/App.app/ViewController_iPhone.nib"
--sdk "/Developer/Platforms/iPhoneSimulator.platform/Developer/
SDKs/iPhoneSimulator4.3.sdk"
3) Compile to native code:
/Developer/MonoTouch/usr/bin/mtouch
-sdkroot "/Applications/Xcode.app/Contents/Developer"
-v --nomanifest --nosign -sim
"/Users/bright/src/App/App/bin/iPhoneSimulator/Debug/App.app"
-r "/Users/bright/src/App/AppLib/bin/Debug/AppLib.dll"
-r "/Developer/MonoTouch/usr/lib/mono/2.1/System.dll"
-r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.dll"
-r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Core.dll"
-r "/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll"
-debug -profiling -nolink -sdk "5.0"
"/Users/bright/src/App/App/bin/iPhoneSimulator/Debug/App.exe"
However, it isn't clear how to do the following (taken from MonoDevelop's build output window), and in what order:
1) Extract embedded content. MonoDevelop just outputs this:
Extracted HelloWorldScreen_iPhone.nib from MtLib.dll
Extracted HelloWorldScreen_iPad.nib from MtLib.dll
2) Update application manifest: There's no command line given in the MonoDevelop build output window.
3) Update debug configuration file: There's no command line given in the MonoDevelop build output window.
4) Update debug settings file: There's no command line given in the MonoDevelop build output window.
And other steps I haven't gotten do yet like app signing and resources.
Hopefully we can get enough information here to make a go of it.

You can run, from a terminal window or from within an MSBuild task, the /Applications/MonoDevelop.app/Contents/MacOS/mdtool tool that is supplied with MonoDevelop. E.g.
/Applications/MonoDevelop.app/Contents/MacOS/mdtool -v build -t:Build "-c:Debug|iPhoneSimulator" /path/to/your/app.csproj
That will build the MonoTouch application, including all your steps above and any future feature that will be added.