Convert Figma logo to code with AI

mono logomono

Mono open source ECMA CLI, C# and .NET implementation.

11,192
3,831
11,192
2,269
View on GitHub

Top Related Projects

dotnet's avatar

runtime

15,701

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

microsoft's avatar

dotnet

14,516

This repo is the official home of .NET on GitHub. It's a great starting point to find many .NET OSS projects from Microsoft and the community, including many that are part of the .NET Foundation.

dotnet's avatar

coreclr

12,795

CoreCLR is the runtime for .NET Core. It includes the garbage collector, JIT compiler, primitive data types and low-level classes.

dotnet's avatar

corefx

17,649

This repo is used for servicing PR's for .NET Core 2.1 and 3.1. Please visit us at https://github.com/dotnet/runtime

dotnet's avatar

android

1,954

.NET for Android provides open-source bindings of the Android SDK for use with .NET managed languages such as C#

xamarin's avatar

xamarin-macios

2,506

.NET for iOS, Mac Catalyst, macOS, and tvOS provide open-source bindings of the Apple SDKs for use with .NET managed languages such as C#

Quick Overview

Mono is an open-source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime. It allows developers to create cross-platform applications using C# and other .NET languages, enabling them to run on various operating systems, including Linux, macOS, and Windows.

Pros

  • Cross-platform compatibility, allowing developers to write code once and run it on multiple operating systems
  • Large and active community, providing support and continuous improvements
  • Extensive library of tools and frameworks, including ASP.NET, Xamarin, and Unity
  • Open-source nature, promoting transparency and allowing for customization

Cons

  • Performance may not always match that of the official Microsoft .NET Framework
  • Some Windows-specific features may not be fully supported or implemented
  • Occasional compatibility issues with certain third-party libraries
  • Learning curve for developers transitioning from Windows-only .NET development

Code Examples

  1. Hello World console application:
using System;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello, Mono!");
    }
}
  1. Simple web server using ASP.NET Core:
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.Configure(app =>
                {
                    app.UseRouting();
                    app.UseEndpoints(endpoints =>
                    {
                        endpoints.MapGet("/", async context =>
                        {
                            await context.Response.WriteAsync("Hello from Mono!");
                        });
                    });
                });
            });
}
  1. Cross-platform GUI application using Gtk#:
using Gtk;
using System;

class HelloWorld
{
    static void Main()
    {
        Application.Init();

        var window = new Window("Hello Mono!");
        window.SetDefaultSize(300, 200);
        window.DeleteEvent += (sender, args) => Application.Quit();

        var button = new Button("Click me!");
        button.Clicked += (sender, args) => Console.WriteLine("Button clicked!");

        window.Add(button);
        window.ShowAll();

        Application.Run();
    }
}

Getting Started

To get started with Mono:

  1. Install Mono on your system:

    • Linux: Use your distribution's package manager (e.g., sudo apt-get install mono-complete for Ubuntu)
    • macOS: Download and install from the official Mono website
    • Windows: Download and install from the official Mono website

  2. Create a new C# file (e.g., HelloWorld.cs) with your preferred text editor.

  3. Compile the code using the Mono C# compiler:

    mcs HelloWorld.cs

  4. Run the compiled executable:

    mono HelloWorld.exe

For more advanced development, consider using an IDE like MonoDevelop or Visual Studio Code with the C# extension.

Competitor Comparisons

dotnet logo

runtime

15,701

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

Pros of runtime

  • More active development and frequent updates
  • Better performance for modern .NET applications
  • Broader platform support, including ARM64

Cons of runtime

  • Steeper learning curve for newcomers
  • Larger codebase, potentially more complex to contribute to
  • Less suitable for older .NET Framework applications

Code Comparison

runtime:

public static int Main(string[] args)
{
    Console.WriteLine("Hello World!");
    return 0;
}

mono:

public static void Main(string[] args)
{
    Console.WriteLine("Hello World!");
}

Summary

runtime is the modern, high-performance implementation of .NET, focusing on cross-platform support and newer technologies. It offers better performance and more frequent updates but may be more complex for beginners.

mono, while still maintained, is more suitable for older .NET Framework applications and has a simpler codebase. However, it lacks some of the advanced features and optimizations found in runtime.

Both projects aim to provide .NET runtime environments, but runtime is generally recommended for new development due to its active development and broader platform support.

microsoft logo

dotnet

14,516

This repo is the official home of .NET on GitHub. It's a great starting point to find many .NET OSS projects from Microsoft and the community, including many that are part of the .NET Foundation.

Pros of dotnet

  • Officially supported by Microsoft, ensuring long-term maintenance and updates
  • Broader platform support, including ARM64 and more Linux distributions
  • More comprehensive documentation and community resources

Cons of dotnet

  • Larger codebase and potentially more complex build process
  • Less flexibility for customization compared to Mono's more modular approach
  • Steeper learning curve for contributors due to its extensive ecosystem

Code Comparison

Mono:

public class HelloWorld
{
    public static void Main(string[] args)
    {
        Console.WriteLine("Hello World!");
    }
}

dotnet:

using System;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello World!");
    }
}

The code examples are nearly identical, reflecting the compatibility between Mono and .NET. The main difference lies in the namespace usage and class naming conventions, with dotnet following more recent C# standards.

Both projects aim to provide a robust runtime for .NET applications, but dotnet offers a more comprehensive and officially supported solution, while Mono maintains its niche in cross-platform development and specialized use cases.

dotnet logo

coreclr

12,795

CoreCLR is the runtime for .NET Core. It includes the garbage collector, JIT compiler, primitive data types and low-level classes.

Pros of CoreCLR

  • Higher performance and better optimization for modern hardware
  • More active development and frequent updates
  • Stronger support for cloud and containerized environments

Cons of CoreCLR

  • Less cross-platform support compared to Mono
  • Steeper learning curve for developers transitioning from .NET Framework
  • Limited support for older .NET technologies

Code Comparison

Mono:

public class Example
{
    public static void Main()
    {
        Console.WriteLine("Hello from Mono!");
    }
}

CoreCLR:

using System;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello from CoreCLR!");
    }
}

The code examples are similar, reflecting the shared C# language. However, CoreCLR typically uses more modern coding conventions and may leverage newer language features not available in older Mono versions.

Both projects aim to provide .NET runtime environments, but CoreCLR focuses on modern, high-performance scenarios, while Mono emphasizes broader platform support and compatibility with older .NET technologies. CoreCLR is the primary runtime for .NET Core and .NET 5+, making it the preferred choice for new projects, while Mono remains valuable for specific cross-platform scenarios and maintaining legacy applications.

dotnet logo

corefx

17,649

This repo is used for servicing PR's for .NET Core 2.1 and 3.1. Please visit us at https://github.com/dotnet/runtime

Pros of CoreFX

  • More actively maintained and developed by Microsoft
  • Better performance and optimization for modern hardware
  • Broader platform support, including ARM64 and WebAssembly

Cons of CoreFX

  • Less compatibility with older .NET Framework versions
  • Steeper learning curve for developers transitioning from Mono
  • More complex build and contribution process

Code Comparison

Mono:

public class Example
{
    public static void Main()
    {
        Console.WriteLine("Hello from Mono!");
    }
}

CoreFX:

using System;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello from CoreFX!");
    }
}

Summary

CoreFX, part of the .NET Core ecosystem, offers improved performance and broader platform support compared to Mono. However, it may have less compatibility with older .NET Framework versions and a steeper learning curve for developers familiar with Mono. The code structure between the two projects is similar, with minor differences in namespace usage and class naming conventions. Both repositories continue to play important roles in the .NET ecosystem, with CoreFX being more actively developed by Microsoft for modern applications.

dotnet logo

android

1,954

.NET for Android provides open-source bindings of the Android SDK for use with .NET managed languages such as C#

Pros of android

  • Specifically optimized for Android development, providing better performance and integration with Android APIs
  • More actively maintained and updated, with frequent releases aligned with .NET updates
  • Smaller footprint and faster build times compared to Mono

Cons of android

  • Limited to Android platform, lacking cross-platform capabilities of Mono
  • Less mature ecosystem and community support compared to Mono's long-standing presence
  • May have compatibility issues with some existing Mono-based projects

Code Comparison

android:

[Activity(Label = "MyApp", MainLauncher = true)]
public class MainActivity : Activity
{
    protected override void OnCreate(Bundle savedInstanceState)
    {
        base.OnCreate(savedInstanceState);
        SetContentView(Resource.Layout.Main);
    }
}

mono:

using System;
using Gtk;

class MainWindow : Window
{
    public MainWindow() : base("Hello Mono World")
    {
        Button btn = new Button("Click me!");
        btn.Clicked += OnButtonClicked;
        Add(btn);
    }
}

The android code showcases Android-specific attributes and lifecycle methods, while the mono code demonstrates cross-platform GUI development using GTK#.

xamarin logo

xamarin-macios

2,506

.NET for iOS, Mac Catalyst, macOS, and tvOS provide open-source bindings of the Apple SDKs for use with .NET managed languages such as C#

Pros of xamarin-macios

  • Focused specifically on iOS and macOS development
  • More frequent updates and releases
  • Tighter integration with Apple's ecosystem and APIs

Cons of xamarin-macios

  • Limited to Apple platforms, less versatile than Mono
  • Smaller community and contributor base
  • Potentially steeper learning curve for developers new to Apple platforms

Code Comparison

xamarin-macios:

[Export ("application:didFinishLaunchingWithOptions:")]
public bool FinishedLaunching (UIApplication application, NSDictionary launchOptions)
{
    // iOS-specific initialization code
    return true;
}

mono:

public static void Main(string[] args)
{
    // Cross-platform initialization code
    Console.WriteLine("Hello, Mono!");
}

The xamarin-macios code snippet demonstrates iOS-specific lifecycle methods, while the Mono example shows a more generic, cross-platform approach. This highlights the platform-specific focus of xamarin-macios compared to Mono's broader applicability.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Mono is a software platform designed to allow developers to easily create cross platform applications. It is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime.

The Mono project is part of the .NET Foundation

[!IMPORTANT] The Mono Project (mono/mono) (‘original mono’) has been an important part of the .NET ecosystem since it was launched in 2001. Microsoft became the steward of the Mono Project when it acquired Xamarin in 2016.

The last major release of the Mono Project was in July 2019, with minor patch releases since that time. The last patch release was February 2024.

We are happy to announce that the WineHQ organization will be taking over as the stewards of the Mono Project upstream at wine-mono / Mono · GitLab (winehq.org). Source code in existing mono/mono and other repos will remain available, although repos may be archived. Binaries will remain available for up to four years.

Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork. That work is now complete, and we recommend that active Mono users and maintainers of Mono-based app frameworks migrate to .NET which includes work from this fork.

We want to recognize that the Mono Project was the first .NET implementation on Android, iOS, Linux, and other operating systems. The Mono Project was a trailblazer for the .NET platform across many operating systems. It helped make cross-platform .NET a reality and enabled .NET in many new places and we appreciate the work of those who came before us.

Thank you to all the Mono developers!

Join us on Discord in the #monovm channel:

Contents

  1. Compilation and Installation
  2. Using Mono
  3. Directory Roadmap
  4. Contributing to Mono
  5. Reporting bugs
  6. Configuration Options
  7. Working with Submodules

Build Status

Public CI: Azure Pipelines

Legacy Jenkins CI (no longer available publicly):

OSArchitectureStatus
Debian 9amd64debian-9-amd64
Debian 9i386debian-9-i386
Debian 9armeldebian-9-armel
Debian 9armhfdebian-9-armhf
Debian 9arm64debian-9-arm64
OS Xamd64osx-amd64
OS Xi386osx-i386
Windowsamd64windows-amd64
Windowsi386windows-i386
CentOSs390x (cs)centos-s390x
Debian 9ppc64el (cs)debian-9-ppc64el
AIX 6.1ppc64 (cs)aix-ppc64
FreeBSD 12amd64 (cs)freebsd-amd64

(cs) = community supported architecture

Compilation and Installation

Building the Software

Please see our guides for building Mono on Mac OS X, Linux and Windows.

Note that building from Git assumes that you already have Mono installed, so please download and install the latest Mono release before trying to build from Git. This is required because the Mono build relies on a working Mono C# compiler to compile itself (also known as bootstrapping).

If you don't have a working Mono installation

If you don't have a working Mono installation, you can try a slightly more risky approach: getting the latest version of the 'monolite' distribution, which contains just enough to run the 'mcs' compiler. You do this with:

# Run the following line after ./autogen.sh
make get-monolite-latest

This will download and place the files appropriately so that you can then just run:

make

The build will then use the files downloaded by make get-monolite-latest.

Testing and Installation

You can run the mono and mcs test suites with the command: make check.

Expect to find a few test suite failures. As a sanity check, you can compare the failures you got with https://jenkins.mono-project.com/.

You can now install mono with: make install

You can verify your installation by using the mono-test-install script, it can diagnose some common problems with Mono's install. Failure to follow these steps may result in a broken installation.

Using Mono

Once you have installed the software, you can run a few programs:

  • mono program.exe runtime engine

  • mcs program.cs C# compiler

  • monodis program.exe CIL Disassembler

See the man pages for mono(1), mcs(1) and monodis(1) for further details.

Directory Roadmap

  • acceptance-tests/ - Optional third party test suites used to validate Mono against a wider range of test cases.

  • data/ - Configuration files installed as part of the Mono runtime.

  • docs/ - Technical documents about the Mono runtime.

  • external/ - Git submodules for external libraries (Newtonsoft.Json, ikvm, etc).

  • ikvm-native/ - Glue code for ikvm.

  • libgc/ - The (deprecated) Boehm GC implementation.

  • llvm/ - Utility Makefiles for integrating the Mono LLVM fork.

  • m4/ - General utility Makefiles.

  • man/ - Manual pages for the various Mono commands and programs.

  • mcs/ - The class libraries, compiler and tools

    • class/ - The class libraries (like System.*, Microsoft.Build, etc.)

    • mcs/ - The Mono C# compiler written in C#

    • tools/ - Tools like gacutil, ikdasm, mdoc, etc.

  • mono/ - The core of the Mono Runtime.

    • arch/ - Architecture specific portions.

    • benchmark/ - A collection of benchmarks.

    • btls/ - Build files for the BTLS library which incorporates BoringSSL.

    • cil/ - Common Intermediate Representation, XML definition of the CIL bytecodes.

    • dis/ - CIL executable Disassembler.

    • eglib/ - Independent implementation of the glib API.

    • metadata/ - The object system and metadata reader.

    • mini/ - The Just in Time Compiler.

    • profiler/ - The profiler implementation.

    • sgen/ - The SGen Garbage Collector implementation.

    • tests/ - The main runtime tests.

    • unit-tests/ - Additional runtime unit tests.

    • utils/ - Utility functions used across the runtime codebase.

  • msvc/ - Logic for the MSVC / Visual Studio based runtime and BCL build system. The latter is experimental at the moment.

  • packaging/ - Packaging logic for the OS X and Windows Mono packages.

  • po/ - Translation files.

  • runtime/ - A directory that contains the Makefiles that link the mono/ and mcs/ build systems.

  • samples/ - Some simple sample programs on uses of the Mono runtime as an embedded library.

  • scripts/ - Scripts used to invoke Mono and the corresponding program.

  • support/ - Various support libraries.

  • tools/ - A collection of tools, mostly used during Mono development.

Contributing to Mono

Before submitting changes to Mono, please review the contribution guidelines. Please pay particular attention to the Important Rules section.

Reporting bugs

To submit bug reports, please open an issue on the mono GitHub repo.

Please use the search facility to ensure the same bug hasn't already been submitted and follow our guidelines on how to make a good bug report.

Configuration Options

The following are the configuration options that someone building Mono might want to use:

  • --with-sgen=yes,no - Generational GC support: Used to enable or disable the compilation of a Mono runtime with the SGen garbage collector.

    • On platforms that support it, after building Mono, you will have both a mono-boehm binary and a mono-sgen binary. mono-boehm uses Boehm, while mono-sgen uses the Simple Generational GC.

  • --with-libgc=[included, none] - Selects the default Boehm garbage collector engine to use.

    • included: (slightly modified Boehm GC) This is the default value for the Boehm GC, and it's the most feature complete, it will allow Mono to use typed allocations and support the debugger.

    • none: Disables the inclusion of a Boehm garbage collector.

    • This defaults to included.

  • --enable-cooperative-suspend

    • If you pass this flag the Mono runtime is configured to only use the cooperative mode of the garbage collector. If you do not pass this flag, then you can control at runtime the use of the cooperative GC mode by setting the MONO_ENABLE_COOP_SUSPEND flag.

  • --with-tls=__thread,pthread

    • Controls how Mono should access thread local storage, pthread forces Mono to use the pthread APIs, while __thread uses compiler-optimized access to it.

    • Although __thread is faster, it requires support from the compiler, kernel and libc. Old Linux systems do not support with __thread.

    • This value is typically pre-configured and there is no need to set it, unless you are trying to debug a problem.

  • --with-sigaltstack=yes,no

    • Experimental: Use at your own risk, it is known to cause problems with garbage collection and is hard to reproduce those bugs.

    • This controls whether Mono will install a special signal handler to handle stack overflows. If set to yes, it will turn stack overflows into the StackOverflowException. Otherwise when a stack overflow happens, your program will receive a segmentation fault.

    • The configure script will try to detect if your operating system supports this. Some older Linux systems do not support this feature, or you might want to override the auto-detection.

  • --with-static_mono=yes,no

    • This controls whether mono should link against a static library (libmono.a) or a shared library (libmono.so).

    • This defaults to yes, and will improve the performance of the mono program.

    • This only affects the `mono' binary, the shared library libmono.so will always be produced for developers that want to embed the runtime in their application.

  • --with-xen-opt=yes,no - Optimize code for Xen virtualization.

    • It makes Mono generate code which might be slightly slower on average systems, but the resulting executable will run faster under the Xen virtualization system.

    • This defaults to yes.

  • --with-large-heap=yes,no - Enable support for GC heaps larger than 3GB.

    • This only applies only to the Boehm garbage collector, the SGen garbage collector does not use this configuration option.

    • This defaults to no.

  • --enable-small-config=yes,no - Enable some tweaks to reduce memory usage and disk footprint at the expense of some capabilities.

    • Typically this means that the number of threads that can be created is limited (256), that the maximum heap size is also reduced (256 MB) and other such limitations that still make mono useful, but more suitable to embedded devices (like mobile phones).

    • This defaults to no.

  • --with-ikvm-native=yes,no - Controls whether the IKVM JNI interface library is built or not.

    • This is used if you are planning on using the IKVM Java Virtual machine with Mono.

    • This defaults to yes.

  • --with-profile4=yes,no - Whether you want to build the 4.x profile libraries and runtime.

    • This defaults to yes.

  • --with-libgdiplus=installed,sibling,<path> - Configure where Mono searches for libgdiplus when running System.Drawing tests.

    • It defaults to installed, which means that the library is available to Mono through the regular system setup.

    • sibling can be used to specify that a libgdiplus that resides as a sibling of this directory (mono) should be used.

  • Or you can specify a path to a libgdiplus.

  • --enable-minimal=LIST

    • Use this feature to specify optional runtime components that you might not want to include. This is only useful for developers embedding Mono that require a subset of Mono functionality.

    • The list is a comma-separated list of components that should be removed, these are:

      • aot: Disables support for the Ahead of Time compilation.

      • attach: Support for the Mono.Management assembly and the VMAttach API (allowing code to be injected into a target VM)

      • com: Disables COM support.

      • debug: Drop debugging support.

      • decimal: Disables support for System.Decimal.

      • full_messages: By default Mono comes with a full table of messages for error codes. This feature turns off uncommon error messages and reduces the runtime size.

      • generics: Generics support. Disabling this will not allow Mono to run any 2.0 libraries or code that contains generics.

      • jit: Removes the JIT engine from the build, this reduces the executable size, and requires that all code executed by the virtual machine be compiled with Full AOT before execution.

      • large_code: Disables support for large assemblies.

      • logging: Disables support for debug logging.

      • pinvoke: Support for Platform Invocation services, disabling this will drop support for any libraries using DllImport.

      • portability: Removes support for MONO_IOMAP, the environment variables for simplifying porting applications that are case-insensitive and that mix the Unix and Windows path separators.

      • profiler: Disables support for the default profiler.

      • reflection_emit: Drop System.Reflection.Emit support

      • reflection_emit_save: Drop support for saving dynamically created assemblies (AssemblyBuilderAccess.Save) in System.Reflection.Emit.

      • shadow_copy: Disables support for AppDomain's shadow copies (you can disable this if you do not plan on using appdomains).

      • simd: Disables support for the Mono.SIMD intrinsics library.

      • ssa: Disables compilation for the SSA optimization framework, and the various SSA-based optimizations.

  • --enable-llvm

    • This enables the use of LLVM as a code generation engine for Mono. The LLVM code generator and optimizer will be used instead of Mono's built-in code generator for both Just in Time and Ahead of Time compilations.

    • See https://www.mono-project.com/docs/advanced/mono-llvm/ for the full details and up-to-date information on this feature.

    • You will need to have an LLVM built that Mono can link against.

  • --enable-big-arrays - Enable use of arrays with indexes larger than Int32.MaxValue.

    • By default Mono has the same limitation as .NET on Win32 and Win64 and limits array indexes to 32-bit values (even on 64-bit systems).

    • In certain scenarios where large arrays are required, you can pass this flag and Mono will be built to support 64-bit arrays.

    • This is not the default as it breaks the C embedding ABI that we have exposed through the Mono development cycle.

  • --enable-parallel-mark

    • Use this option to enable the garbage collector to use multiple CPUs to do its work. This helps performance on multi-CPU machines as the work is divided across CPUS.

    • This option is not currently the default on OSX as it runs into issues there.

    • This option only applies to the Boehm GC.

  • --enable-dtrace

    • On Solaris and MacOS X builds a version of the Mono runtime that contains DTrace probes and can participate in the system profiling using DTrace.

  • --disable-dev-random

    • Mono uses /dev/random to obtain good random data for any source that requires random numbers. If your system does not support this, you might want to disable it.

    • There are a number of runtime options to control this also, see the man page.

  • --with-csc=roslyn,mcs,default

    • Use this option to configure which C# compiler to use. By default the configure script will pick Roslyn, except on platforms where Roslyn does not work (Big Endian systems) where it will pick mcs.

      If you specify "mcs", then Mono's C# compiler will be used. This also allows for a complete bootstrap of Mono's core compiler and core libraries from source.

  If you specify "roslyn", then Roslyn's C# compiler will be used. This currently uses Roslyn binaries.

  • --enable-nacl

    • This configures the Mono compiler to generate code suitable to be used by Google's Native Client: https://code.google.com/p/nativeclient/

    • Currently this is used with Mono's AOT engine as Native Client does not support JIT engines yet.

  • --enable-wasm

    • Use this option to configure mono to run on WebAssembly. It will set both host and target to the WebAssembly triplet. This overrides the values passed to --host or --target and ignored what config.sub guesses.

      This is a workaround to enable usage of old automake versions that don't recognize the wasm triplet.

Working With Submodules

Mono references several external git submodules, for example a fork of Microsoft's reference source code that has been altered to be suitable for use with the Mono runtime.

This section describes how to use it.

An initial clone should be done recursively so all submodules will also be cloned in a single pass:

$ git clone --recursive git@github.com:mono/mono

Once cloned, submodules can be updated to pull down the latest changes. This can also be done after an initial non-recursive clone:

$ git submodule update --init --recursive

To pull external changes into a submodule:

$ cd <submodule>
$ git pull origin <branch>
$ cd <top-level>
$ git add <submodule>
$ git commit

By default, submodules are detached because they point to a specific commit. Use git checkout to move back to a branch before making changes:

$ cd <submodule>
$ git checkout <branch>
# work as normal; the submodule is a normal repo
$ git commit/push new changes to the repo (submodule)

$ cd <top-level>
$ git add <submodule> # this will record the new commits to the submodule
$ git commit

To switch the repo of a submodule (this should not be a common or normal thing to do at all), first edit .gitmodules to point to the new location, then:

$ git submodule sync -- <path of the submodule>
$ git submodule update --recursive
$ git checkout <desired new hash or branch>

The desired output diff is a change in .gitmodules to reflect the change in the remote URL, and a change in / where you see the desired change in the commit hash.

License

See the LICENSE file for licensing information, and the PATENTS.TXT file for information about Microsoft's patent grant.

Mono Trademark Use Policy

The use of trademarks and logos for Mono can be found here.