+ 7 - 3 | § ¶So many news in MD, so many...
MonoDevelop 0.8Everybody already knows, but well, let me mention that MD 0.8 was released last week.
New web site
The 0.8 release was a good excuse to set up a new web site for MD. We wanted a web site easier to update, and where everybody could contribute, and MediaWiki is ideal for this. So I started with a copy of the Mono website, and I changed the background (the blue strip), the logo, the link box, and some styles. I used Inkscape to make the images, it's the first time I use it and turned out to be really useful. In any case, we are still lacking a real logo, although looks like Idan Gazit is already working on it.
Assembly Reorganization
Some weeks ago I committed the long time due assembly
reorganization. MD is now more modular, the namespace hierarchy is more
coherent, and the source code files easier to locate (we now follow the
same convention as in Mono). Without this reorganization it would have not been possible to do all I'm going to explain next.
Application add-ins
That's a simple but interesting feature: add-ins can now register
applications that can be executed from a terminal, from outside the MD
IDE. To create an application, you only need to implement the
IApplication interface and its Run (string[] args) method, and register the class in the /Workspace/Applications
extension point. For example:
<Extension path = "/Workspace/Applications">
<Class id = "build" class = "MonoDevelop.Projects.BuildTool"/>
</Extension>
You can then execute the application using the mdrun tool and providing the ID you used to register the app:
> mdrun build
build is actually a real app already implemented, which is basically
a command line tool for compiling MD projects. By default it compiles
the first mds or mdp file it finds in the current folder, but you can
also provide a project file path with the --f option. This is an example of the output you would get:
lluis@portatil:~/Projects/ttest> mdrun build
MonoDevelop Build Tool
Loading combine: ./ttest.mds
Loading project: /home/lluis/Projects/ttest/ttest.mdp
Loading project: /home/lluis/Projects/ttest2/ttest2.mdp
Loading project: /home/lluis/Projects/ttest3/ttest3.mdp
Building Solution ttest
Building Project: ttest Configuration: Debug
Performing main compilation...
Compilation succeeded - 1 warning(s)
/home/lluis/Projects/ttest/Main.cs(28,11): warning CS0219: The variable
`r' is assigned but its value is never used
Build complete -- 0 errors, 1 warnings
Building Project: ttest2 Configuration: Debug
Performing main compilation...
Build complete -- 0 errors, 0 warnings
Building Project: ttest3 Configuration: Debug
Performing main compilation...
Build complete -- 0 errors, 0 warnings
What's
interesting is that the tool will load all add-ins it needs to run, not
only the language binding add-ins but also project extensions, such as
the extension for compiling Mono. So, if you have the MD extensions for
Mono developers, you can cd to the mcs directory and run:
mdrun build --f:Makefile
This will compile the Mono class libraries, and all driven by MD's project system. Not really useful (since you can do the same with just typing make), but cool anyways.
In addition to build there are three more commands:
- mdrun IDE: starts the MonoDevelop IDE (surprise!)
-
mdrun setup: it's a command-line frontend for the add-in manager.
- mdrun gsetup: the GTK# frontend for the add-in manager.
And what's all this about the add-in manager? keep reading...
UPDATE: mdrun has been renamed to mdtool, since an aplication with that name already exist in Linux.
The Add-in Manager
So now MD has an add-in manager you can use to download, install, update or uninstall add-ins. Here is a screenshot:
The add-in manager can be started from the MD IDE (Tools menu), from the command line (mdrun gsetup), or you can use the command-line version (mdrun setup).
With the add-in manager it is possible to install add-ins from on-line repositories, and keep track of updates. You only need to register the repository url (there is a button for this), and select the add-ins you want to install. The manager will take care of dependencies between add-ins, or between add-ins and the core assemblies.
There is already one repository, which is located at http://go-mono.com/md, and which contains all the core add-ins. Oh, I haven't said it before, but at as a result of the reorganization now all core MD assemblies are add-ins, including the IDE (but excluding MonoDevelop.Core, which contains the add-in engine itself). This means that starting in the next MD release, we'll be able to provide updates to the IDE or any of its core add-ins by just pushing a new version of the add-in in the go-mono repository. No need for repackaging. The same assembly available for everybody.
However, it's not so clear we always want to update MD in this way. I mean, if I install the MD 0.9 RPM package it might be confusing to allow upgrading the IDE to 0.10 through the add-in manager. Although upgrading to 0.9.1 (maybe a bug-fix release) would make sense.
Add-in packages and repositories
So, how can you package your add-in and make it available to all MD users? here is a quick guide:
- Make sure that the <Runtime> section of your addin.xml file
contains references to all files used by the add-in. Use <Import
assembly="relpath/to/dll"/> to reference assemblies, and <Import
file="relpath/to/file"/> for other data files, images or whatever.
- Create a local directory, for example: myaddins
- Execute "mdrun setup pb path/to/addin.xml -d:myaddins". This will create a .mpack file in myaddins, which is just a zip with all files.
- Do the above for all your add-ins.
- Execute "mdrun setup rb myaddins". This will create a couple of .mrep files, which are just an index of the add-ins in the repository.
- Upload all .mpack and .mrep files to a web server
- Tell us the url of that server.
Now, the question is: what happens if MD is installed in a directory where the user has no write privileges? it is not so clear what to do in this case. I see two options:
- Force the user to switch to root in order to install add-ins. Maybe MD could do the switch (by asking the pwd), but I don't know if there is a safe and cross-distro way to do it.
- Install new add-ins somewhere in user's home directory. This sound more sensible, but there can be problems with add-in dependencies if there are several users in the same system. Updating the shared core assemblies may lead to broken dependencies in locally installed assemblies.