-->
Today, we are comparing Visual Studio and Monodevelop. We'll also look at Visual Studio Code and briefly compare it to Monodevelop for Mac & Linux, Enjoy Ace:). MonoDevelop facilitates Game developers to quickly write desktop and web applications on Linux, Windows and Mac OS X. It also makes it easy for developers to port.NET applications created with Visual Studio to Linux and Mac OS X maintaining a single code base for all platforms.
Visual Studio for Mac consists of a set of modules called Extension Packages. You can use Extension Packages to introduce new functionality to Visual Studio for Mac, such as support for an additional language or a new Project template.
Extension packages build from the extension points of other extension packages. Extension points are placeholders for areas that can be expanded upon, such as a menu or the list of IDE Commands. An extension package can build from an extension point by registering a node of structured data called an extension, such as a new menu item or a new Command. Each extension point accepts certain types of extensions, such as a Command, Pad, or FileTemplate. A module that contains extension points is called an add-in host, as it can be extended by other extension packages.
To customize Visual Studio for Mac, you can create an extension package that builds from extension points contained in add-in hosts within pre-existing libraries in Visual Studio for Mac, as illustrated by the following diagram:
In order for an extension package to build from Visual Studio for Mac, it must have extensions that build from pre-existing extension points within the Visual Studio for Mac IDE. When an extension package relies on an extension point defined in an add-in host, it is said to have a dependency on that extension package.
The benefit of this modular design is that Visual Studio for Mac is extensible -- there are many extension points that can be built upon with custom extension packages. Examples of current extension packages include support for C# and F#, debugger tools, and Project templates.
Note
If you have an Add-in Maker project that was created before Add-in Maker 1.2, you need to migrate your project as outlined in the steps here.
This section looks at the different files generated by the Add-in Maker and the data a command extension requires.
Attribute files
Extension packages store metadata about their name, version, dependencies, and other information in C# attributes. The Add-in Maker creates two files,
AddinInfo.cs
and AssemblyInfo.cs
to store and organize this information. Extension packages must have a unique ID and namespace specified in their Addin
attribute:Extension packages must also declare dependencies on the extension packages that own the extension points they plug into, which are automatically referenced at build time.
Furthermore, additional references can be added via the Add-in reference node in the solution pad for the project, as depicted by the following image:
They also have their corresponding
assembly:AddinDependency
attributes added at build time. Once the metadata and dependency declarations are in place, you can focus on the essential building blocks of the extension package.Extensions and extension points
An extension point is a placeholder that defines a data structure (a type), while an extension defines data that conforms to a structure specified by a specific extension point. Extension points specify what type of extension they can accept in their declaration. Extensions are declared using type names or extension paths. See the Extension Point reference for a more in-depth explanation on how to create the extension point that you need.
The extension/extension point architecture keeps the development of Visual Studio for Mac fast and modular.
Command Extensions
Command Extensions are extensions that point to methods that are called every time it is executed.
Command Extensions are defined by adding entries to the
/MonoDevelop/Ide/Commands
extension point. We defined our extension in Manifest.addin.xml
with the following code:The extension node contains a path attribute that specifies the extension point that it is plugging into, in this case
/MonoDevelop/Ide/Commands/Edit
. Additionally, it acts as a parent node to the Command. The Command node has the following attributes:id
- Specifies the identifier for this Command. Command Identifiers must be declared as enumeration members, and are used to connect Commands to CommandItems._label
- The text to be shown in menus._description
- The text to be shown as a tooltip for toolbar buttons.defaultHandler
- Specifies theCommandHandler
class that powers the Command
A CommandItem extension that plugs into the
/MonoDevelop/Ide/MainMenu/Edit
extension point is demonstrated in the following code snippet:A CommandItem places a Command specified in its
id
attribute into a menu. This CommandItem is extending the /MonoDevelop/Ide/MainMenu/Edit
extension point, which makes the Command's label appear in the Edit Menu. Note that the ID in the CommandItem corresponds to the ID of the Command node, InsertDate
. If you remove the CommandItem, the Insert Date option would disappear from the Edit Menu.Command Handlers
The
InsertDateHandler
is an extension of the CommandHandler
class. It overrides two methods, Update
and Run
. The Update
method is queried whenever a Command is shown in a menu or executed via key bindings. By changing the info object, you can disable the Command or make it invisible, populate array commands, and more. This Update
method disables the command if it can't find an active Document with a TextEditor to insert text into:You only need to override the
Update
method when you have special logic for enabling or hiding the Command. The Run
method executes whenever a user executes a Command, which in this case occurs when a user selects the Command from the Edit Menu. This method inserts the date and time at the caret in the text editor:Declare the Command type as an enumeration member within
DateInserterCommands
:The Command and CommandItem are now tied together - the CommandItem calls the Command when the CommandItem is selected from the Edit Menu.
IDE APIs
For information on the scope of areas that are available for development, see the Extension Tree Reference and the API Overview. When building advanced extension packages, also refer to Developer Articles. Below is a partial list of areas for customization:
- Pads
- Key Binding Schemes
- Policies
- Code formatters
- Project file formats
- Preferences panels
- Options Panels
- Debugger Protocols
- Debugger visualizers
- Workspace layouts
- Solution pad tree nodes
- Source editor margins
- Unit test engines
- Code generators
- Code snippets
- Target frameworks
- Target runtime
- VCS back-ends
- Refactoring
- Execution handlers
- Syntax highlighting
Extending The New Editor
Visual Studio for Mac introduces a new native Cocoa text editor UI built on top of the same editor layers from Visual Studio on Windows.
One of the many benefits of sharing the editor between Visual Studio and Visual Studio for Mac is that code targeting the Visual Studio editor can be adapted to run on Visual Studio for Mac.
Note
The new editor supports only C# files at this time. Other languages and file formats will open in the legacy editor. The legacy editor does however implement some of the Visual Studio Editor APIs described below.
Visual Studio Editor Overview
Before touching on extension details specific to Visual Studio for Mac, it is helpful to understand more about the shared editor itself. Below are a few resources that may deepen this understanding:
With those resources in hand, the primary concepts that you need to be familiar with are an
ITextBuffer
and an ITextView
:- An
ITextBuffer
is an in-memory representation of text that can be changed over time. TheCurrentSnapshot
property onITextBuffer
returns an immutable representation of the current contents of the buffer, an instance ofITextSnapshot
. When an edit is made on the buffer, the CurrentSnapshot property is updated to the latest version. Analyzers can inspect the text snapshot on any thread and its contents is guaranteed to never change. - An
ITextView
is the UI representation of howITextBuffer
is rendered on screen in the editor control. It has a reference to its text buffer, as well asCaret
,Selection
, and other UI-related concepts.
For a given
MonoDevelop.Ide.Gui.Document
, you can retrieve the associated underlying ITextBuffer
and ITextView
via Document.GetContent<ITextBuffer>()
and Document.GetContent<ITextView>()
respectively.Additional Information
Note
We are currently working on improving the extensibility scenarios for Visual Studio for Mac. If you are creating extensions and need additional help or information, or would like to provide feedback, please fill in the Visual Studio for Mac Extension Authoring form.
See also
This project contains advanced editing support for the F# addin in MonoDevelop, Xamarin Studio and Visual Studio for Mac.
##Features
- Code completion
- Syntax highlighting
- Tooltips
- Debugging
- F# Interactive scripting (Alt-Enter execution)
- Templates (Console Application, Library, Tutorial Project, Gtk Project, iOS, Android)
- more...
Prerequisites
To use F# language support please ensure that you have F# installed on your system, for details on this please see http://fsharp.org
Installation
This addin is included by default for MonoDevelop/Xamarin Studio/Visual Studio for Mac.
Building and installing from scratch
This code is directly part of the
monodevelop
repository so the easiest ways of building is to clone monodevelop and work in the submodule directly:Can't get it to work?
Don't give up! Add an issue to this repository. Your issue will be seen by the developers.
Notes on Manual Testing (old instructions, unverified)
To check things are working try a few different things somewhat at random:
- Check the F# templates are appearing
- Create a console project (NOTE: retarget it to .NET 4.0 using right-click->options->General)
- Check there are completion lists in the console project e.g. for 'System.' and 'System.Console.WriteLine(' and 'List.'
- Check you can build the console project
- Check you can run the console project
- Check you can 'debug-step-into' the console project
- Check you can set a break point in the console project
- Check there are type tips showing when you move the mouse over code identifiers
- Load an existing .fsproj (e.g. see MonoDevelop.FSharpBinding/tests/projects/...) and check if completion works etc.
- Run msbuild on a few .fsproj (this is nothing to do with the binding, it is just fsharp/fsharp)
Debugging Tips (old instructions, unverified)
To be able to debug the add-in in Xamarin Studio or Monodevelop, invoke
./configure.sh --debug
or configure.bat --debug
. This adds the necessary .mdb files to the add-in.When configured with --debug
you can simply Start debugging
in Xamarin Studio. This will launch a debugged instance of Xamarin Studio.On Mac, if you make changes to the add-in after debugging, you will need to restart Xamarin Studio or MonoDevelop before rebuilding.
Note that you can not build the add-in in release mode when configured with
--debug
. To build a release build, first ./configure.sh
without --debug
On Mac/Linux, if you make changes to the binding, then loss of completion lists etc. can be disturbing and hard to debug. There are some debugging techniques. To launch MonoDevelop you can use the command:
or this command for Xamarin Studio:
to enable some logging you can use
On Windows you can generally use Visual Studio to help develop the binding.You can start Xamarin Studio or MonoDevelop under the debugger using the normal technique:
Building the addin separately (old instructions, unverified)
To configure and compile the addin seperately then the following commands can be executed from the addin directory (/main/external/fsharpbining if cloning as part of monodevelop)
If MonoDevelop is installed in an unusual prefix you will need to invoke
configure.sh
with e.g. --prefix=/path/to/prefix/lib/monodevelop
. Use ./configure.sh --help
to see a list of the paths searched by default.If you subsequently make changes to the add-in, you will need to
make install
again and restart MonoDevelop/Xamarin Studio.The first time you
make install
the AddIn you'll override Xamarin's official one and it will initially be set to disabled, so you need to go to the AddIn manager and ensure the F# AddIn is enabled.Note: One thing to check is the the version specified in
configure.fsx
is higher than the pre-installed version, if it's not then the local addin will not be loaded.For reference on Mac the locally installed addin is at the following location:
/Users/<username>/Library/Application Support/XamarinStudio-6.0/LocalInstall/AddIns/fsharpbinding/<version>
Build on Windows (old instructions, unverified, builds and installs the Debug version into Xamarin Studio - adjust as needed)
If you subsequently make changes to the add-in, you will need to
build-and-install-debug.bat
again and restart MonoDevelop/Xamarin Studio.For more information about F# see The F# Software Foundation. Join The F# Core Engineering Group.