Saturday, July 25, 2015
The bad news is that it's no longer in development.
The good news is that the successor of the refactoring part is (RefactoringEssentials). The rest of the code has been moved to the monodevelop source code and is still available and in active development as open source.
So the 5.0 version will remain - and will be still maintained a bit by Daniel Grundwald and me.
Why was this decision made ?
Mostly because most NRefactory6 code was just wrappers around internal roslyn classes (and making them public). I don't think that it's worth as a stand alone library.
Since #Develop was discontinued the 2nd big NRefactory user is no longer around and it's more time effective to move that code to monodevelop and split the refactorings so they can be used in VS.NET 2015 as well.
So I deleted the NRefactory6 today. Bye NRefactory we had a nice time - and hello RefactoringEssentials :)
Wednesday, November 13, 2013
What most Xamarin Studio users don't know is that they already have static code analysis. It is possible to get the same development experience in Xamarin Studio as well without buying any 3rd party addin. We had that feature since some releases but it's shaping up quite well now. With the latest 4.2 release it's really worth turning it on. You just need to:
- Get the latest Xamarin Studio (or MonoDevelop) release - newer is always better
- Enable background source analysis
Background source analysis is like pair programming. That means that that two programmers work at one computer. And while the you write code the other will observe what you write any review each line you type.
Enable it through the IDE options:
Now after that notice that the scroll bar has been replaced with a new control:
If Xamarin Studio finds a possible issue in your code you can see it in that control. And directly jump to the location (or you can use the button at the top of the control - this button quickly shows the status of the file - if there are any errors/warnings etc. - a click on that button takes you to the most urgent issue in that file).
The issues are marked in the text editor as well. Most issues are underlined - but there are other markers for example redundant code is grayed out:
Generally code issues in Xamarin Studio provide a resolution to fix them. Even for most common errors fixes are available. That's dramatically reducing development time.
A little marker appears when the caret is at the marked code. This indicates that a refactoring action is available - either press alt+enter to open the context sensitive refactoring menu or look in the context menu to perform the action.
|Action marker over a code issue|
But the IDE does even more: Quick fixes
If you're not at a code issue that marker appears for various constructs - it shows that refactoring actions are available which let you easily change code without typing.
There are hundreds of code actions and code issues available which make the daily work with Xamarin Studio a charm.
Thursday, September 5, 2013
MonoDevelop runs on Linux quite well (in case you use a light theme - see MonoDevelop 4.0 and dark themes). Many developers from Xamarin are Linux users and run MonoDevelop on Linux every day (but without a dark theme :)).
It is possible to get a very good looking monodevelop environment on Linux as well. I'll try to explain how I do it and show a screenshot as 'proof of concept' :)
Parallel Mono EnvironmentTo get the latest mono you'll need to build a parallel mono environment. This is far easier than it sounds and wont affect the mono your distribution has. (But you need to install a mono in your distribution for building a mono from the repositories)
First you need a script for 'switching' to the parallel environment. I use this script for doing it:
#!/bin/bash MONO_PREFIX=/opt/mono GNOME_PREFIX=/opt/gnome export DYLD_LIBRARY_PATH=$MONO_PREFIX/lib:$DYLD_LIBRARY_PATH export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH export C_INCLUDE_PATH=$MONO_PREFIX/include:$GNOME_PREFIX/include export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig:$GNOME_PREFIX/lib/pkgconfig PATH=$MONO_PREFIX/bin:$PATH /opt/monodevelop/bin/monodevelop
The best way is to build mono, gtk# (gtk-sharp-2-12-branch) and gnome-sharp from the sources found on github(I hope you're familiar with git):
For building mono & gtk-sharp your distribution needs some prerequisites - either you follow what the configure/bootstrap scripts tell you or try something like sudo apt-get build-dep monodevelop.
You need to run the configure/bootstrap scripts with the option --prefix=/opt/mono - and then it installs 'as usual' with make/make install.
And just run it with "make run" - that's all.
Some tips: Adjust the fonts (I use Source Code Pro for the text editor and Source Sans Pro almost everywhere else).
Get the Xamarin gtk theme from https://github.com/mono/xamarin-gtk-theme (you may need to set the prefix here to --prefix=/usr) and enable it in Environment->Language.
The end result should like this:
Ok I agree that there is a drawing error in the tab bar - but that's due a graphic device driver bug (it should render a horizontal linear gradient - chrome tabs suffer from the same bug on my machine).
Friday, August 2, 2013
Writing unit tests should be easy and fun.
Saturday, March 30, 2013
As you see there is a space after the 'null' that shouldn't be there. I could've just removed the space and continue my work - but what would happen if I do it again ? Wouldn't it be nice if it could be auto formatted like in a IDE. Just make the code format itself!
First step - make the program print itself. For that I added some code around the if that repeats the program and prints it:Now running the program on the console gives: The self formatting source code - easy and without any external IDE. The wrong space is finally gone. But the formatter has done something with the brackets. That's because of the options I gave to the formatter. The C# formatter needs an options object that specifies how the C# code should be formatted. The CSharpFormattingOptions class provides a large set of very fine grained formatting options. The factory gives easy access to the most common indenting styles (see wikipedia). The Allman style is used in Visual Studio .NET which puts all braces on it's own line. That's why the formatter has altered the if brackets. That's just one way to call the formatter. It was built for in IDE use. The formatter can generate the minimum change set of replace operations required to do the formatting. Furthermore it's possible to format only a portion of the text inside a document. In monodevelop the on the fly formatter uses this functionality to provide formatting. The formatting engine in NRefactory is mighty and easy to use - let me know if you find uses for it or have improvements.
Monday, February 25, 2013
The Visual Studio color importer !Defining own color schemes is very painful it is much easier to use a pre defined scheme from Studio Styles. Now it is easy to do as well importing a visual studio color scheme. Now finally what once has been an April's fool joke can now become a reality:
Sunday, April 8, 2012
In SharpDevelop the actions and issue providers are running too. With NRefactory as base we can share these features.
Furthermore a code issue can provide a code action to fix the issue.
Writing the Code Issue Provider
In the code above pi is assigned to a constant value that never changes (I would recommend using Math.PI, but that's not part of this blog) and can be converted to a local constant:
For the analysis we need to do:
- Check that the variable declaration is not constant
- Check that all variables of the declaration have an initializer that is a constant expression
- Analyze the data flow to ensure that the variables are read only
Creating the provider class
Code Issue logic
Adding the issue and fix action
Now time for creating the code issue and a fix action. Note that the fix action is optional. The code issues share the code action infrastructure with the code actions.
The difference here is that the issue and fix action is added to a node in the syntax tree - in our case the variable declaration.
An action contains a script. This is basically an syntax tree transformation, but can contain more text editor like actions as well like activating a linked name mode in the text editor (for naming newly created variables for example).
In our case we just need to add a 'const' before the variable declaration. That would be fairly easy with a script.InsertBefore (varDecl, new CSharpModifierToken (Modifiers.Const)); call - but let's do it with a more complex syntax tree transformation.
We need to change the variable declarations modifiers. But the tree is immutable. However it is possible to clone an immutable node which can be altered. That's what we do - we clone the declaration, add a const modifier to it and replace the original variable declaration with it's altered version:
The TranslateString function should be used for all strings displayed (The IssueDescription is included as well) so that they're automatically added to our translation database.