thoughts-dotnet

Here are some thoughts on how to make dotnet toolchain more user friendly on different OS's.

Note: These are simply proposals. Feel free to consider or discard them.

Dotnet First Contact Executable (DFCE)

• A tool that can be downloaded on any OS by a user which lets them express their intent of use. Based on the intent specified, the tool does all the necessary installation such as:

  • installing the right runtime, or
  • installing the right SDK, or
  • installing the right IDE's (vscode and/or addons, unity, xamarin).

• After this installation, the DFCE also runs through a diagnostic flow to ensure that the user will actually be able to perform those intents on this setup. This is where the Dotnet Doctor tool comes in.

• Responsibilities of DFCE

  • Collect user intent
  • Keep track of environment variables and notify the user if they have gotten unintentionally modified by some other tool.
    • Check the .bashrc, .bash_profile files on ubuntu, and other files for other OS's
  • Keep track of integrity of the installation sites (folders) and inform if there is any mismatch in file signatures.
  • To enable quick actions such as "upgrade/downgrade" of runtimes/sdks/ide's.
  • Suggestion to remove a version of dotnet if it's not being used (atleast once in 6 months).

Dotnet Doctor (DD)

• Based on the learnt intent of the user, with the DFCE, this tool attempts to create projects behind the scenes (temp folders) and execute them end-to-end.
  • Examples:
    • Dotnet console project
      • The tool creates a new dotnet project and runs it. Then checks if the output to the console was "Hello world!" or not.
    • Blazor server project
      • The tool creates a new blazorserver project and runs it in a headless browser. Then checks the outputs of the console (both in the shell and in the headless browser) to detect any failures.
    • Xamarin Android development
      • The tool first looks for android dependencies, environment variables, Java SDK configuration, emulators/devices are usable etc.
      • Mono tools and Xamarin IDE are functioning as expected.
      • Then it checks if the hello world equivalent works as well

Why would we need this ?

The reason to have the DFCE and DD is :

• to be assured that the right bits are present on the system.
• to catch installation errors early on and not when developers start working on the application they want to build.
  • For example, building a wpf project is not supported on ubuntu as of today.
• Know right away whether a particular setup configuration can help achieve the intent of the user. If not, what steps could be taken.
• Adding deterministic flow to configuration reduces anxiety of whether a configuration will work or not, on not just our machines, but also in docker, or in cloud VPS/VMs or iot devices and wherever dotnet can reach - also addresses the "I don't want to mess with this machine" problem.
• Ability to export configuration (configuration.json, for example) and replicate the exact setup on a remote machine with simply the configuration.json and the DFCE.

Glossary

User

• An application consumer or application developer

Intents

• End-User intents
  • Install a particular runtime for a particular application.
    • We don't want the user to be concerned with which package manager is being used.
• Developer intents
  • Install a particular sdk.
  • Create a WPF application
  • Create a BlazorServer application etc.

Setup configuration

• A state representing all the dotnet runtimes, sdks, IDE's settings installed globally or locally on the disk.