SharpDevelop

Currently we are working on a 2.0 release of Refactoring Essentials, that will include a considerable number of new refactorings and bugfixes/improvements - for C# and VB! Please see the complete list in our release notes. Because some of our devs ... [More] will be on vacation next week, the official release will arrive only after September 14th, 2015. But if you are interested in experiencing the new features now, you can pick one of our development builds automatically pushed to VSIX Gallery. Don't get confused: The development builds still have a 1.2.x version number. Feel free to test (especially the new refactorings and analyzers) and let us know about any problems through GitHub! P.S.: Many thanks to all contributors and testers who helped us in the last months to make Refactoring Essentials better! [Less]

Currently we are working on a 2.0 release of Refactoring Essentials, that will include a considerable number of new refactorings and bugfixes/improvements - for C# and VB! Please see the complete list in our release notes. Because some of our devs ... [More] will be on vacation next week, the official release will arrive only after September 14th, 2015. But if you are interested in experiencing the new features now, you can pick one of our development builds automatically pushed to VSIX Gallery. Don't get confused: The development builds still have a 1.2.x version number. Feel free to test (especially the new refactorings and analyzers) and let us know about any problems through GitHub! P.S.: Many thanks to all contributors and testers who helped us in the last months to make Refactoring Essentials better! [Less]

At the SharpDevelop Developer Days 2015 in Bad Ischl we had two focus areas - one was the new decompilation engine for ILSpy vNext (3.0), the other our NRefactory 6 roadmap. NRefactory 6 is our rewrite of the IDE services (code completion ... [More] , refactorings, et al) from our full-stack (lexer, parser, you-name-it) NRefactory 5 to using Roslyn in the new version. Given that we have a decade of legacy in our stack, rewriting it meant unlearning a few habits, making quite a few architectural changes along the way, and restructuring the project a lot. NRefactory 5 had a lot of analyzers and refactorings that we wanted to bring forward, and we did so in the NR6Pack. It was initially tied very tightly to NRefactory, and we had a shared project that copied code to both (at first it was straight linking). As we learned, we removed more and more ties and NR6Pack was finally independent from NRefactory. However, they still shared the same GitHub repository - making contributing unnecessarily hard (oh, and the repo was quite big because the Web properties were also in there). Thus, in Ischl we sat down together for name-finding because the initial "pack" was no longer correctly reflecting what was in the codebase: the refactorings had taken center stage. With that in mind, it didn't take us long to settle on a new name - and so 5/30/2015 marked the last release that used the old name (we still wanted a stable release before doing renaming, and, once again, a restructuring). Refactoring Essentials has a GitHub repository of its own now, and the Web site is also split out into a GitHub repository (pay for play: devs don't need to download stuff they are not interested in). Also, we no longer tweet as part of the @sharpdevelop account, we now have a dedicated Twitter: @vsrefactoring. One thing before closing: although we use the suffix "for Visual Studio", the refactoring/analyzer library itself is a portable class library (PCL). Yes, it is cross platform, and not only for fun: it is used in MonoDevelop today (remember: Refactoring Essentials is a part of our NRefactory 6 effort). [Less]

At the SharpDevelop Developer Days 2015 in Bad Ischl we had two focus areas - one was the new decompilation engine for ILSpy vNext (3.0), the other our NRefactory 6 roadmap. NRefactory 6 is our rewrite of the IDE services (code completion ... [More] , refactorings, et al) from our full-stack (lexer, parser, you-name-it) NRefactory 5 to using Roslyn in the new version. Given that we have a decade of legacy in our stack, rewriting it meant unlearning a few habits, making quite a few architectural changes along the way, and restructuring the project a lot. NRefactory 5 had a lot of analyzers and refactorings that we wanted to bring forward, and we did so in the NR6Pack. It was initially tied very tightly to NRefactory, and we had a shared project that copied code to both (at first it was straight linking). As we learned, we removed more and more ties and NR6Pack was finally independent from NRefactory. However, they still shared the same GitHub repository - making contributing unnecessarily hard (oh, and the repo was quite big because the Web properties were also in there). Thus, in Ischl we sat down together for name-finding because the initial "pack" was no longer correctly reflecting what was in the codebase: the refactorings had taken center stage. With that in mind, it didn't take us long to settle on a new name - and so 5/30/2015 marked the last release that used the old name (we still wanted a stable release before doing renaming, and, once again, a restructuring). Refactoring Essentials has a GitHub repository of its own now, and the Web site is also split out into a GitHub repository (pay for play: devs don't need to download stuff they are not interested in). Also, we no longer tweet as part of the @sharpdevelop account, we now have a dedicated Twitter: @vsrefactoring. One thing before closing: although we use the suffix "for Visual Studio", the refactoring/analyzer library itself is a portable class library (PCL). Yes, it is cross platform, and not only for fun: it is used in MonoDevelop today (remember: Refactoring Essentials is a part of our NRefactory 6 effort). [Less]

At the SharpDevelop Developer Days 2015 in Bad Ischl we had two focus areas - one was the new decompilation engine for ILSpy vNext (3.0), the other our NRefactory 6 roadmap. NRefactory 6 is our rewrite of the IDE services (code completion ... [More] , refactorings, et al) from our full-stack (lexer, parser, you-name-it) NRefactory 5 to using Roslyn in the new version. Given that we have a decade of legacy in our stack, rewriting it meant unlearning a few habits, making quite a few architectural changes along the way, and restructuring the project a lot. NRefactory 5 had a lot of analyzers and refactorings that we wanted to bring forward, and we did so in the NR6Pack. It was initially tied very tightly to NRefactory, and we had a shared project that copied code to both (at first it was straight linking). As we learned, we removed more and more ties and NR6Pack was finally independent from NRefactory. However, they still shared the same GitHub repository - making contributing unnecessarily hard (oh, and the repo was quite big because the Web properties were also in there). Thus, in Ischl we sat down together for name-finding because the initial "pack" was no longer correctly reflecting what was in the codebase: the refactorings had taken center stage. With that in mind, it didn't take us long to settle on a new name - and so 5/30/2015 marked the last release that used the old name (we still wanted a stable release before doing renaming, and, once again, a restructuring). Refactoring Essentials has a GitHub repository of its own now, and the Web site is also split out into a GitHub repository (pay for play: devs don't need to download stuff they are not interested in). Also, we no longer tweet as part of the @sharpdevelop account, we now have a dedicated Twitter: @vsrefactoring. One thing before closing: although we use the suffix "for Visual Studio", the refactoring/analyzer library itself is a portable class library (PCL). Yes, it is cross platform, and not only for fun: it is used in MonoDevelop today (remember: Refactoring Essentials is a part of our NRefactory 6 effort). [Less]

In the last two months Mike Krüger has done some intensive refactoring of NRefactory 6 code and we also have restructured the project and the way how NRefactory and NR6Pack share their code: Analyzers & Refactorings are now plain Roslyn ... [More] NRefactory 6 began as a thin wrapper API around some Roslyn base classes to emulate the API of NRefactory 5. The intention was to simplify porting of code actions and issues from the pre-Roslyn NRefactory 5. But since concepts of NR5 and Roslyn are not completely congruent, this led to some restrictions. An example: In Roslyn a code analyzer and a code fix may exist independently from each other. NR5 (and therefore NR6 wrapper) API didn't allow this separation. That way it wasn't possible to implement custom fixes for analyzers already shipped with Roslyn without reimplementing the analyzer. The wrapper API has been removed, there are no NR6-specific base classes or attributes anymore. There is no difference to analyzers or refactorings implemented plainly with Roslyn. This is the reason why we have dropped the NRefactory.Templates project (and Visual Studio extension) published in January: The ".NET Compiler Platform SDK Templates" provided by Microsoft are now sufficient. Changes in naming In NRefactory and NR6Pack "Analyzers" and "Refactorings" were previously called "Issues" and "Actions", a relict from NR5. All classes were renamed to fit Roslyn terminology. All ...CodeFixProvider classes were moved to their own .cs files. What's new and what's past? Some new analyzers were ported, like ThreadStaticAtInstanceFieldAnalyzer, FieldCanBeMadeReadOnlyAnalyzer, PublicConstructorInAbstractClassAnalyzer and several more. On the other side some analyzers/refactorings were removed because they are similar to what Roslyn already provides. For some compiler errors Roslyn delivers only the analyzers, while NR6(Pack) also implements appropriate code fixes. Therefore only the CodeFixProviders were kept, while the analyzers have been dropped. There are also some examples of refactorings which were combined into one, so their number might even have decreased without loosing features. NRefactory "vs." NR6Pack In previous releases NR6Pack project was more or less a reduced copy of NRefactory 6 project consisting of file links to analyzers and refactorings in ICSharpCode.NRefactory6.CSharp.Refactoring project. It was quite hard to keep both projects synchronized all the time. After recent restructuring all projects have clear responsibilities: ICSharpCode.NRefactory6.Shared: Shared project containing utility classes used by NR6 and NR6Pack NR6Pack: Now regularly contains all the analyzers and refactorings. No copies or links of these classes are needed anymore, the NR6Pack project will simply be used by MonoDevelop as well as by NR6Pack Visual Studio extension. NR6Pack.Tests: This new project hosts all unit tests for analyzers and refactorings of NR6Pack. ICSharpCode.NRefactory6.CSharp: Rest of NRefactory 6 remaining after excluding all utility APIs and analyzers/refactorings. This includes code completion and special refactoring features mainly needed by MonoDevelop. ICSharpCode.NRefactory6.CSharp.Tests: Contains unit tests for features of ICSharpCode.NRefactory6.CSharp.   All this work should simplify maintenance and extending of NR/NR6Pack a lot. And there are still some unported analyzers and refactorings you could help us with! [Less]

In the last two months Mike Krüger has done some intensive refactoring of NRefactory 6 code and we also have restructured the project and the way how NRefactory and NR6Pack share their code: Analyzers & Refactorings are now plain Roslyn ... [More] NRefactory 6 began as a thin wrapper API around some Roslyn base classes to emulate the API of NRefactory 5. The intention was to simplify porting of code actions and issues from the pre-Roslyn NRefactory 5. But since concepts of NR5 and Roslyn are not completely congruent, this led to some restrictions. An example: In Roslyn a code analyzer and a code fix may exist independently from each other. NR5 (and therefore NR6 wrapper) API didn't allow this separation. That way it wasn't possible to implement custom fixes for analyzers already shipped with Roslyn without reimplementing the analyzer. The wrapper API has been removed, there are no NR6-specific base classes or attributes anymore. There is no difference to analyzers or refactorings implemented plainly with Roslyn. This is the reason why we have dropped the NRefactory.Templates project (and Visual Studio extension) published in January: The ".NET Compiler Platform SDK Templates" provided by Microsoft are now sufficient. Changes in naming In NRefactory and NR6Pack "Analyzers" and "Refactorings" were previously called "Issues" and "Actions", a relict from NR5. All classes were renamed to fit Roslyn terminology. All ...CodeFixProvider classes were moved to their own .cs files. What's new and what's past? Some new analyzers were ported, like ThreadStaticAtInstanceFieldAnalyzer, FieldCanBeMadeReadOnlyAnalyzer, PublicConstructorInAbstractClassAnalyzer and several more. On the other side some analyzers/refactorings were removed because they are similar to what Roslyn already provides. For some compiler errors Roslyn delivers only the analyzers, while NR6(Pack) also implements appropriate code fixes. Therefore only the CodeFixProviders were kept, while the analyzers have been dropped. There are also some examples of refactorings which were combined into one, so their number might even have decreased without loosing features. NRefactory "vs." NR6Pack In previous releases NR6Pack project was more or less a reduced copy of NRefactory 6 project consisting of file links to analyzers and refactorings in ICSharpCode.NRefactory6.CSharp.Refactoring project. It was quite hard to keep both projects synchronized all the time. After recent restructuring all projects have clear responsibilities: ICSharpCode.NRefactory6.Shared: Shared project containing utility classes used by NR6 and NR6Pack NR6Pack: Now regularly contains all the analyzers and refactorings. No copies or links of these classes are needed anymore, the NR6Pack project will simply be used by MonoDevelop as well as by NR6Pack Visual Studio extension. NR6Pack.Tests: This new project hosts all unit tests for analyzers and refactorings of NR6Pack. ICSharpCode.NRefactory6.CSharp: Rest of NRefactory 6 remaining after excluding all utility APIs and analyzers/refactorings. This includes code completion and special refactoring features mainly needed by MonoDevelop. ICSharpCode.NRefactory6.CSharp.Tests: Contains unit tests for features of ICSharpCode.NRefactory6.CSharp.   All this work should simplify maintenance and extending of NR/NR6Pack a lot. And there are still some unported analyzers and refactorings you could help us with!   UPDATE 2015-06-25: We have finished the next evolutional step with NR6Pack and separated all refactorings and analyzers to a new project: "Refactoring Essentials" were born! Read the full post. [Less]

In the last two months Mike Krüger has done some intensive refactoring of NRefactory 6 code and we also have restructured the project and the way how NRefactory and NR6Pack share their code: Analyzers & Refactorings are now plain Roslyn ... [More] NRefactory 6 began as a thin wrapper API around some Roslyn base classes to emulate the API of NRefactory 5. The intention was to simplify porting of code actions and issues from the pre-Roslyn NRefactory 5. But since concepts of NR5 and Roslyn are not completely congruent, this led to some restrictions. An example: In Roslyn a code analyzer and a code fix may exist independently from each other. NR5 (and therefore NR6 wrapper) API didn't allow this separation. That way it wasn't possible to implement custom fixes for analyzers already shipped with Roslyn without reimplementing the analyzer. The wrapper API has been removed, there are no NR6-specific base classes or attributes anymore. There is no difference to analyzers or refactorings implemented plainly with Roslyn. This is the reason why we have dropped the NRefactory.Templates project (and Visual Studio extension) published in January: The ".NET Compiler Platform SDK Templates" provided by Microsoft are now sufficient. Changes in naming In NRefactory and NR6Pack "Analyzers" and "Refactorings" were previously called "Issues" and "Actions", a relict from NR5. All classes were renamed to fit Roslyn terminology. All ...CodeFixProvider classes were moved to their own .cs files. What's new and what's past? Some new analyzers were ported, like ThreadStaticAtInstanceFieldAnalyzer, FieldCanBeMadeReadOnlyAnalyzer, PublicConstructorInAbstractClassAnalyzer and several more. On the other side some analyzers/refactorings were removed because they are similar to what Roslyn already provides. For some compiler errors Roslyn delivers only the analyzers, while NR6(Pack) also implements appropriate code fixes. Therefore only the CodeFixProviders were kept, while the analyzers have been dropped. There are also some examples of refactorings which were combined into one, so their number might even have decreased without loosing features. NRefactory "vs." NR6Pack In previous releases NR6Pack project was more or less a reduced copy of NRefactory 6 project consisting of file links to analyzers and refactorings in ICSharpCode.NRefactory6.CSharp.Refactoring project. It was quite hard to keep both projects synchronized all the time. After recent restructuring all projects have clear responsibilities: ICSharpCode.NRefactory6.Shared: Shared project containing utility classes used by NR6 and NR6Pack NR6Pack: Now regularly contains all the analyzers and refactorings. No copies or links of these classes are needed anymore, the NR6Pack project will simply be used by MonoDevelop as well as by NR6Pack Visual Studio extension. NR6Pack.Tests: This new project hosts all unit tests for analyzers and refactorings of NR6Pack. ICSharpCode.NRefactory6.CSharp: Rest of NRefactory 6 remaining after excluding all utility APIs and analyzers/refactorings. This includes code completion and special refactoring features mainly needed by MonoDevelop. ICSharpCode.NRefactory6.CSharp.Tests: Contains unit tests for features of ICSharpCode.NRefactory6.CSharp.   All this work should simplify maintenance and extending of NR/NR6Pack a lot. And there are still some unported analyzers and refactorings you could help us with!   UPDATE 2015-06-25: We have finished the next evolutional step with NR6Pack and separated all refactorings and analyzers to a new project: "Refactoring Essentials" were born! Read the full post. [Less]

In the last two months Mike Krüger has done some intensive refactoring of NRefactory 6 code and we also have restructured the project and the way how NRefactory and NR6Pack share their code: Analyzers & Refactorings are now plain Roslyn ... [More] NRefactory 6 began as a thin wrapper API around some Roslyn base classes to emulate the API of NRefactory 5. The intention was to simplify porting of code actions and issues from the pre-Roslyn NRefactory 5. But since concepts of NR5 and Roslyn are not completely congruent, this led to some restrictions. An example: In Roslyn a code analyzer and a code fix may exist independently from each other. NR5 (and therefore NR6 wrapper) API didn't allow this separation. That way it wasn't possible to implement custom fixes for analyzers already shipped with Roslyn without reimplementing the analyzer. The wrapper API has been removed, there are no NR6-specific base classes or attributes anymore. There is no difference to analyzers or refactorings implemented plainly with Roslyn. This is the reason why we have dropped the NRefactory.Templates project (and Visual Studio extension) published in January: The ".NET Compiler Platform SDK Templates" provided by Microsoft are now sufficient. Changes in naming In NRefactory and NR6Pack "Analyzers" and "Refactorings" were previously called "Issues" and "Actions", a relict from NR5. All classes were renamed to fit Roslyn terminology. All ...CodeFixProvider classes were moved to their own .cs files. What's new and what's past? Some new analyzers were ported, like ThreadStaticAtInstanceFieldAnalyzer, FieldCanBeMadeReadOnlyAnalyzer, PublicConstructorInAbstractClassAnalyzer and several more. On the other side some analyzers/refactorings were removed because they are similar to what Roslyn already provides. For some compiler errors Roslyn delivers only the analyzers, while NR6(Pack) also implements appropriate code fixes. Therefore only the CodeFixProviders were kept, while the analyzers have been dropped. There are also some examples of refactorings which were combined into one, so their number might even have decreased without loosing features. NRefactory "vs." NR6Pack In previous releases NR6Pack project was more or less a reduced copy of NRefactory 6 project consisting of file links to analyzers and refactorings in ICSharpCode.NRefactory6.CSharp.Refactoring project. It was quite hard to keep both projects synchronized all the time. After recent restructuring all projects have clear responsibilities: ICSharpCode.NRefactory6.Shared: Shared project containing utility classes used by NR6 and NR6Pack NR6Pack: Now regularly contains all the analyzers and refactorings. No copies or links of these classes are needed anymore, the NR6Pack project will simply be used by MonoDevelop as well as by NR6Pack Visual Studio extension. NR6Pack.Tests: This new project hosts all unit tests for analyzers and refactorings of NR6Pack. ICSharpCode.NRefactory6.CSharp: Rest of NRefactory 6 remaining after excluding all utility APIs and analyzers/refactorings. This includes code completion and special refactoring features mainly needed by MonoDevelop. ICSharpCode.NRefactory6.CSharp.Tests: Contains unit tests for features of ICSharpCode.NRefactory6.CSharp.   All this work should simplify maintenance and extending of NR/NR6Pack a lot. And there are still some unported analyzers and refactorings you could help us with!   UPDATE 2015-06-25: We have finished the next evolutional step with NR6Pack and separated all refactorings and analyzers to a new project: "Refactoring Essentials" were born! Read the full post. [Less]

Daniel has created a NuGet package "of" ILSpy - the decompiler engine. It is based off of the 2.3 release, and we want your feedback before officially calling it done in the 2.4 release (and yes, there is no getting started sample, ILSpy doesn't ... [More] exactly count as that...). One important note: ILSpy builds against the source code versions of NRefactory and Cecil (the former needs customizations of the latter). The decompiler NuGet package is built against the official binaries of those two. That is just fine, because the customizations do not matter for the decompiler itself. Just wanted to make this clear because issue #573 refers to the initial problems we had with packaging it in a way so you can use NR and Decompiler both in the same project without versioning issues. [Less]