[MonoDevelop] Migrating from VS and R#

[IBBoard]

On 21/08/10 13:31, xeno.by wrote:
> 
> Hi all!
> 
> Some days ago I've decided to check out Linux, and I liked it so much that
> now I want to completely migrate from Windows. The only problem is my job
> that involves coding .NET stuff. I have installed mono together with
> monodevelop, so currently I'm in the middle of migration (luckily, my
> project doesn't involve interaction with Windows-only stuff). 

Sounds like a good plan :) For those remaining WinForms projects I've
got a VirtualBox VM of XP for development and testing, but everything
else I do is using MonoDevelop in openSUSE

> 
> I've spent quite a bit of time digging into MonoDevelop and, frankly
> speaking, I'm pretty much astonished at the amount of functionality
> available. 80-90% of things I use with VS and R# are already here and (omg!)
> usually have much better performance (e.g. intellisense with loads of
> options is instant, whereas in VS+R# environment it usually lags a lot). Now
> I've got only to fix those missing percents, and I'm all happy with my Linux
> development environment. 

If you're comfortable with the idea, then I'd strongly recommend getting
involved in helping to improve MonoDevelop. I've not got to the stage of
contributing code, but I've been running the bleeding edge version for
the past few months, contributing loads of bugs (as Mike Krueger will
attest to ;) ) and generally providing thoughts, suggestions and feedback.

> 
> So the questions are as follows:
> 
> 1) My top feature of R# is, surprisingly, identifier coloring. Personally
> for me it significantly simplifies mental parsing of the program. Being able
> to easily distinguish fields, methods, locals and arguments is invaluable.
> Any ideas how I can achieve this with MonoDevelop? I tried semantic
> highlighting, but it seems to only highlight class names (e.g. within
> typeofs).

I'm not sure if MonoDevelop supports as much as Eclipse and R# probably
do (different colours and styles for boxed types, static access, etc),
but there is more to the colour themes than the defaults seem to
indicate. Have a look at
http://www.teknynja.com/2009/10/monodevelop-custom-color-schemes.html
for quite a good write-up and then submit a feature request if it needs
to do more (http://monodevelop.com/Developers#Reporting_Bugs)

> 
> 2) Another thingie in R# that I also use frequently is "Ctrl+Alt+Space",
> which displays an intellisense list of applicable methods that gets
> populated from all referenced assemblies and namespace, *regardless* of
> whether there's a corresponding "using" at the top of the file. So, if I
> have lots of utility extension methods (and I do), I don't have to populate
> usings first or enter a name and then wait for the quick-fix popup to
> emerge, I just type several first symbols of the method name and then hit
> Ctrl+Alt+Space - it will automatically search through my references and
> auto-import namespaces if necessary. How does one achieve the same effect in
> MonoDevelop? I tried "Toggle Completion Suggestion Mode", but didn't manage
> to figure out what it does.

I got confused by "Toggle Completion Suggestion Mode" as well -
apparently that's just to determine whether it auto-selects the results
or not (i.e. whether it autocompletes on punctuation or whether you've
got to actively pick the suggestion).

Ctrl+Alt+Space and auto-adding of "using" references is a feature I use
a lot in the dev builds, so either it made it into v2.4 and you're still
using v2.2 or else it was added after 2.4 and it'll be in the next
release (or the dev release if you want to build from scratch)

> 
> 3) If we talk about navigation, I must confess that I'm impressed by the
> speed of various "Go To..." dialogs. However, I wasn't able to find
> analogues of several important features I use every day. Firstly, "Go To
> Definition" doesn't display something like Studio's assembly browser (or w/e
> it is called) when I use it on a library class. Secondly, it appeared that
> I'm quite addicted at Ctrl+clicking method/class usages to go to definition.
> It seems, that both features are missing. Any workarounds?

F3 is the "go to definition" (I think - or maybe I just mapped that
because it is what Eclipse uses).

As for the assembly browser, it does exist, but I always get to it via
the References (double-click on a reference). I've just checked what
you're mentioning and it appears that "Go To Definition" on a
base.SomeMethod() where base is a class from an assembly just goes to
the highest level in your code. Mike just fixed another issue with "Go
To Definition" that I reported the other day, so maybe that'll get fixed
with a bug report as well :)

> 
> 4) (An offtopic). Expanding the topic of navigation, I'd love to ask your
> opinion on Reflector's replacement. Yeh, of course, one can run Reflector
> under Mono, however, most navigation features in Reflector depend on IE, so
> they become broken in Linux. Any ideas here?

Sorry, never used it. I'll leave that to others.

> 
> 5) Finally, is there a possibility to turn off automatic highlighting of
> local/parameter usages within a method. That's a rough analogue of R#'s
> Alt+Shift+F7, however, sometimes it's annoying, so I'd love to disable this
> feature by default and toggle it whenever I need it. How do I do that? Upd.
> Yeh, a small addition. Is there a way to make those symbol highlighting
> persistent as in R#, so that they don't disappear whenever I move the caret
> away from the symbol of interest?

I think they both need a feature request in the bug tracker. I know
Eclipse has a little button to enable and disable occurrence
highlighting, but I think it tracks the cursor as well. I've not seen
anything like that in MD, though, and it does seem to always be on.

> 
> I'd like to stress it once again - I'm very pleasantly surprised to see that
> overwhelming amount of my favourite VS+R# features have equivalent or better
> analogues in MD. Yeh, there are some bugs (e.g. with extract/inline variable
> refactorings), but they can be tolerated - overall quality is still pretty
> impressive.

Ah, that'd be one reason to wait a little on the dev builds, actually.
Someone has broken the "Extract Method" refactoring at the moment! It
works (the code is extracted) but it forgets the method name you gave it
and so it just gets called "()" rather than "MyExtractedMethod()". I've
not noticed any bugs with extracting and inlining variables in the dev
builds, though.