Merge remote-tracking branch 'remotes/upstream/master'

Conflicts:
	src/AddIns/DisplayBindings/WpfDesign/WpfDesign.XamlDom/Project/XamlDocument.cs

Author: gumme

.gitignore

@@ -15,8 +15,9 @@ bin/
 /src/Tools/UpdateAssemblyInfo/bin
 /src/Setup/SharpDevelop.Setup.wixproj.user
 /src/Main/ICSharpCode.SharpDevelop.Sda/ICSharpCode.SharpDevelop.Sda.dll.config
-/src/Main/StartUp/Project/SharpDevelop.exe.config
+/src/Main/SharpDevelop/app.config
 /src/Main/GlobalAssemblyInfo.cs
+/src/Main/GlobalAssemblyInfo.vb
 /src/AddIns/Misc/UsageDataCollector/UsageDataCollector.AddIn/AnalyticsMonitor.AppProperties.cs
 
 /src/AddIns/Misc/PackageManagement/Packages/AvalonEdit/lib

README.txt

@@ -20,16 +20,14 @@ How To Compile
 SharpDevelop can be compiled using the supplied .bat files, or in SharpDevelop itself.
 
 System Requirements (running SharpDevelop)
- - Windows XP SP2 or higher.
- - .NET 4 prerequisites (might be already installed, e.g. by Windows Update):
-   - Windows Installer 3.1: http://www.microsoft.com/downloads/details.aspx?familyid=889482FC-5F56-4A38-B838-DE776FD4138C&displaylang=en
-   - Windows Imaging Component: http://www.microsoft.com/downloads/details.aspx?FamilyId=8E011506-6307-445B-B950-215DEF45DDD8&displaylang=en#filelist
- - .NET 4.0 Full (Extended, the "Client" portion is not sufficient)
+ - Windows Vista or higher.
+ - .NET 4.5
  - Visual C++ 2008 SP1 Runtime (http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en)
- 
+
 Extended Requirements (building SharpDevelop)
  - .NET 3.5 SP1
- - Windows SDK 7.1
+ - .NET 4.5 SDK (part of Windows SDK 8.0)
+ - Windows SDK 7.1 (?? not sure if this still is necessary...)
  - Windows SDK 7.0 (optional; C++ compiler needed for profiler)
  - Windows PowerShell
  - if you have cloned the SD git repository: git must be available on your PATH
@@ -73,4 +71,4 @@ SharpDevelop Contributors:
 	Siegfried Pammer
 	Peter Forstmeier (SharpDevelop Reports)
 
-	(for a full list see http://wiki.sharpdevelop.net/Contributors.ashx)
+	(for a full list see https://github.com/icsharpcode/SharpDevelop/wiki/Contributors)

SharpDevelop.Tests.sln

@@ -0,0 +1,212 @@
+
+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