That is how we got started with the idea of getting ReSharper’s platform to automatically detect changes in the APIs its plugins reference. It was not lost on us that sticking with this approach made the job of plugin writers maddening, and we knew things had to change. Due to our internal refactorings, we could not guarantee seamless migration.īoth ReSharper and Rider have major releases three times a year, which means that until recently, plugin developers were forced to recompile their plugins at least three times a year. For years, we’ve declared every new version of ReSharper as incompatible with the installed plugins, even if the set of APIs they reference hasn’t technically changed. ![]() It also makes huge refactorings like preparing ReSharper for the out-of-process mode or preparing our codebase for integration into Fleet much harder. But there’s a flip side to such freedom.įollowing the “each public component is an extension point” strategy limits our ability to refactor the existing code. ![]() That means that any component of ReSharper is like a building block that can be overridden with plugins, opening up virtually limitless possibilities for fine-tuning every aspect of ReSharper’s behavior.Īs a plugin author, you get to take advantage of each and every component that ReSharper developers themselves use. ReSharper’s development team uses the dependency injection approach to design every aspect of the product. Despite being a plugin itself, ReSharper serves as an incredible platform for plugin creation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |