SharpDevelop/TODOnewNR.txt

Commented code, needs to be ported and re-enabled:
	ParseProjectContent
	Class Browser (removed from source tree; to be reimplemented using WPF)
	NRefactoryLanguageConverter
	Context Actions (EditorContext etc.)
	RefactoringService
	FindReferencesAndRenameHelper
	NamespaceRefactoringService
	RefactoringMenuBuilder
	TaskService.UpdateCommentTags
	CodeManipulation.cs (btw, I think this doesn't belong into AvalonEdit.AddIn - more a job for a language binding)

--> See TODO-list on Google Docs

Important features (self-hosting):
	Ctrl+Space Completion
	ctor snippet
	Rename refactoring
	Run unit test from icon bar margin
	"Add using" context action (and other resolve error MD context actions)
	ILSpy-AddIn

Stuff that was renamed/moved:
	ICSharpCode.SharpDevelop.Dom -> the type system and resolvers now are part of ICSharpCode.NRefactory
	IDocument -> moved to ICSharpCode.NRefactory.Editor
	IClass -> ITypeDefinition
	ICompilationUnit -> IUnresolvedFile
	ITextBuffer -> ITextSource (in ICSharpCode.NRefactory.Editor)
	IReturnType -> ITypeReference (unresolved) or IType (resolved)
	Location -> TextLocation in ICSharpCode.NRefactory
	TextLocation -> moved to ICSharpCode.NRefactory

Functionality changes:
	
	SharpDevelop.Dom was replaced by NRefactory 5:
		Apart from plenty of API changes, there are also a couple of architectural changes
		to look out for.
		Most importantly, the type system has been split up into an unresolved and a resolved
		version. When porting code using SD.Dom, be careful which one of the two you choose.
		
		If possible, try to avoid using the unresolved type system. The planned observable code model
		(will be implemented for the 5.0 class browser) might be a better alternative in some cases.
		Features related to the type system / refactorings should probably wait for this code model
		before they are ported to 5.0.

		NRefactory 5 introduction: http://www.codeproject.com/Articles/408663/Using-NRefactory-for-analyzing-Csharp-code


	Static services replaced with interfaces:
		To make writing unit tests easier, the static services in SharpDevelop are getting
		replaced with interfaces. The class "SD" has static properties to get references
		to the services, so the call "ResourceService.GetString()" becomes "SD.ResourceService.GetString()".
		
		In unit tests, Rhino.Mocks can be used to easily create mocks of the services:
			SD.InitializeForUnitTests(); // initialize container and remove services from previous test cases
			SD.Services.AddService(typeof(IParserService), MockRepository.GenerateStrictMock<IParserService>());
			SD.ParserService.Stub(p => p.GetCachedParseInformation(textEditor.FileName)).Return(parseInfo);
			SD.ParserService.Stub(p => p.GetCompilationForFile(textEditor.FileName)).Return(compilation);
		
		It is possible to define a service interface in ICSharpCode.SharpDevelop.dll and have the implementation
		somewhere else (SD will find it using the AddInTree).
		This allows for AddIns to consume each other's functionality (e.g. debugger accessing the decompiler service)
		without having to define a custom AddIn tree path.
		The long-term goal is to have only interfaces and helper classes in ICSharpCode.SharpDevelop.dll (the API for AddIns)
		and have the implementation details in SharpDevelop.exe (which AddIns aren't supposed to reference).


	ICSharpCode.Core.WinForms hidden behind service interfaces:
		This is an extension of the previous point.
		The whole assembly ICSharpCode.Core.WinForms still exists and has the old static services,
		which makes porting old AddIns a bit easier.
		However, it should no longer be used in new code and AddIns should get rid of the reference
		to ICSharpCode.Core.WinForms if possible.
		The services in SD.WinForms provide the same functionality.


	Namespaces in ICSharpCode.SharpDevelop reorganized:
		I'm currently moving types around in ICSharpCode.SharpDevelop, so you'll have to update
		plenty of usings.
		The idea behind the new namespaces is that grouping the code into 'Gui' and 'Services'
		isn't very useful; so I'm getting rid of those namespaces and the old folder structure,
		and re-group the types into feature areas.
		
		Within the ICSharpCode.SharpDevelop project, the 'Src' folder contains the old code
		that hasn't been cleaned up yet and may still be in an old namespace.
		
		When I'm done cleaning up a code file, I'm moving to out of the 'Src' folder into one of
		the new folders corresponding to the new namespace.
		As part of this cleanup, I'm also replacing static services with service interfaces (see above).


	AddInTree paths reorganized
		Plenty of AddIn tree paths have been changed to better match the new namespace structure.
		
		I used a global replace operation for renaming paths; so AddIns that are in the SharpDevelop
		repository but not in the SharpDevelop solution (because they haven't been ported yet)
		have been adjusted as well.


	SD.MainThread:
		The new best way to invoke a call on the main thread is:
			SD.MainThread.InvokeAsync(delegate { ... }).FireAndForget();
		
		Note that InvokeAsync returns a Task (like all .NET 4.5 *Async APIs). If any exceptions occur while
		executing the delegate, they will get stored in the task object. This can cause the exception to get
		silently ignored if the task object isn't used later. The "FireAndForget()" extension method solves
		this problem by reporting any (future) errors to the message service.
		
		It is also often possible to avoid explicit thread switches alltogether by using the C# 5 async/await feature.


	ICSharpCode.Core.ICommand replaced with WPF ICommand
		New menu commands should derive from 'SimpleCommand' instead of 'AbstractMenuCommand'.
		If 'IsEnabled'-handling is required, new commands should just implement ICommand directly without using any base class.
		
		The old class AbstractMenuCommand still exist and simulates the old API, which makes porting AddIns a bit easier.
		I'm thinking about writing a tool that automatically ports AbstractMenuCommand-derived classes to SimpleCommand,
		so you don't need to bother updating your commands manually.


	SD.PropertyService:
		The Get()/Set() methods no longer support nested Properties objects or lists of elements -
		you will need to use the new dedicated GetList()/SetList()/NestedProperties() methods for that.
		
		The Get() method no longer causes the default value to be stored in the container; and GetList()
		results in a read-only list - an explicit SetList() call is required to store the resulting value again.
		
		However, a nested properties container still is connected with its parent, and any changes done
		to the nested container will get saves without having to call the SetNestedProperties() method.
		
		The property service now uses XAML serialization instead of XML serialization. This might require
		some changes to your classes to ensure they get serialized correctly, for example
		you need to use public properties instead of public fields.


	SD.ParserService:
		The result of a parser run (ParseInformation) now may contain a fully parsed AST.
		The ParserService may cache such full ASTs, but may also drop them from memory at any time.
		This will be implemented by keeping the last N accessed files in the cache. (currently we just keep the caches around forever)
		Every parse information also contains an IUnresolvedFile instance with the type system information.
		The IUnresolvedFile is stored permanently (both in ParserService and in the IProjectContents).


	Solution model:
		The class 'Solution' has been replaced with the interface 'ISolution'.
		The static events that report changes to the solution (e.g. project added) no longer exist on IProjectService;
		instead the ISolution.Projects collection itself has a changed event.


	Text editor and document services:
		In SharpDevelop 4.x it was possible to use IDocument.GetService(typeof(ITextEditor)) to find the
		editor that presents the document.
		This is no longer possible in SharpDevelop 5, as the same IDocument may be used by
		multiple editors (e.g. split view).
		
		ITextEditor and IDocument now use separate service containers.
		ITextEditor.GetService() will also return document services, but not the other way around.
		
		The attributes [DocumentService] and [TextEditorService] are used to mark the service interfaces
		that are available in the document and in the editor respectively.
		The attributes exist purely for documentation, and some services may not use them
		(for example the service interfaces defined in AvalonEdit, where the attributes aren't referenced).


	View content services:
		Instead of casting a view content to an interface "var x = viewContent as IEditable;",
		code should use the viewContent.GetService() method.
		This allows the view content implementation to be flexible where the interface is implemented,
		it no longer is necessary to implement everything in the same class.
		
		Interfaces that are supposed to be used as view content services are marked with the
		[ViewContentService] attribute.
		
		In the case of the AvalonEditViewContent, all text editor and document services are
		also available via IViewContent.GetService().
		If split view is in use, the view content will return the services from the editor that has the focus.


	XML Forms:
		Classic .xfrm still exists and can be used in SD 5.0.
		However XML forms support should be considered a temporary feature for making AddIns easier to port,
		we still plan to get rid of all .xfrms and the associated infrastructure by the time SD 5.0 ships.
		
		Simply porting an .xfrm to a regular WinForms control with InitializeComponents() is acceptable,
		but porting it to WPF is preferred.



What wasn't changed:

	SD-1234 still makes implementing view contents difficult by preventing them from loading/saving
	files when they want to. I'd like to fix this, but this likely won't fit into 5.0 and will have to wait for 5.1.


	The IProject/ProjectItem model is mostly unchanged and still does not provide proper change notifications
	(apart from those in the static ProjectService).
	Lacking a good project model, we also haven't started moving the project browser to WPF.
	This is a major refactoring on top of the already existing major changes in 5.0, so it doesn't fit.
	But it's definitely a goal for 5.1.


Context Actions vs. Member Context Menu:
	Members context menu should include refactoring options that can be applied from the outside,
	for example in the classes pad when the code file isn't open.
	Refactorings that don't make sense without opening the file shouldn't be in the member menu.
	
	The context actions menu should show all refactorings (even those that are also in the members context menu).

Automatic Translation:
	WorkbenchSingleton.AssertMainThread() -> SD.MainThread.VerifyAccess()
	AbstractMenuCommand-derived classes that do not override IsEnabled -> SimpleCommand