Many class/inteface members that have previously been declared as public have now become protected. This means that plugin writers who inherit from these will need to adjust their access modifiers accordingly.
In order to support multi-level popup menus for context actions and quick-fixes, their respective interfaces have been modified to allow the plugin author to provide a hierarchical menu structure. To update CAs and QFs to use the new API, plugin writers need to perform the following changes:
- Using statements need to be fixed first, since both IQuickFix and IContextActions have been relocated to the JetBrains.ReSharper.Intentions.Extensibility namespace. (Additional namespaces will be added in the next step.)
- The interfaces need to be re-implemented (a ReSharper popup will help you do this). In both QFs and CAs, you can delete the Items property, as it is replaced by the CreateBulbItems() method.
- For context actions, the CreateBulbItems() method takes a BulbMenu, which you need to use to define the bulb menu items that will be shown. Typically, for existing CAs, you need to do the following:
- If your context action inherits from BulbItemImpl, you don’t need to do anything because BulbItemImpl implements a CreateBulbItems() method adding itself to the menu. However, BulbItemImpl itself is obsolete.
- If your context action has multiple items, you can call menu.ArrangeContextActions(items) where items is an IEnumerable<IBulbAction> (i.e., a list, array or some other collection of bulb items).
- The implementation of IQuickFix needs to be updated in a similar manner. The only difference is that an additional parameter of type Severity is passed into the CreateBulbItems() method.
Important: The above is a set of changes which will get your code running. However, several types were made obsolete for ReSharper 7, and will be removed in a future release. Thus, plugin writers are advised to make the following additional changes:
- The IBulbItem interface has been deprecated and may be removed in a future ReSharper release. Go through your code and replace uses of IBulbItem with IBulbAction.
- The BulbItemImpl class has been deprecated. This means that:
- If you have been using classes that inherited either (BulbItemImpl, IContextAction) or (BulbItemImpl, IQuickFix) or a base class such as CSharpContextActionBase (which became obsolete in the 6.0 release), it is recommended that you replace these base classes/interfaces with either ContextActionBase (for CAs) or QuickFixBase (for QFs).
- You need to through your code and replace uses of BulbItemImpl with BulbActionBase. Please note that, unlike BulbItemImpl, the BulbActionBase class does not provide an implementation of CreateBulbItems(). This means that after the change, you will need to implement this method as described above.
The CSharpGeneratorBuilderBase is no longer part of the API. Classes should be updated to inherit from GeneratorBuilderBase<CSharpGeneratorContext> instead. This would require some changes, for example:
- The Process(), IsAvailable() and other methods now need to have protected visibility.
- Certain inherited members are no longer available. For example, the inherited GetFactory() method now needs to be replaced with in-place factory creation, e.g., CSharpElementFactory.GetInstance(context.PsiModule).
The CreateProcess() method of a C# daemon stage now takes an extra parameter of type ICSharpFile.
The return type of an IDaemonStage is now IEnumerable<IDaemonStageProcess>, so that many processes can be created. As a result, you need to change your existing code from return to yield return.
The ToolWindowDescriptor attribute no longer has parameters called Id and Guid:
- The Id has been changed to ProductNeutralId.
- The Guid parameter is no longer used.
Also, it no longer has a parameterless contructor, which means that plugin writers must call the base class constructor passing an instance of IApplicationDescriptor that they take as a parameter.
Due to the introduction of injected PSI mechanics, certain API calls need to be changed. For example, in C# and VB (which are non-injected), this would require to change calls from GetPsiFile() to GetNonInjectedPsi(). Further information on the new API is available in 3.4 Multi-Language PSI (R7).
Due to ReSharper's new way of handling icons, code that currently uses ReSharper-provided icons requires modification, whereas your own icons need to either be converted or preprocessed using build tasks that are provided with the SDK.
A small number of useful base classes (e.g., DrivenRefactoringWorkflow) have changed as a result, and their inheritors will need to be updated.
See 4.05 Icons (R7) for more info.