Resharper and its ecosystem

I am a user of Resharper, not a developer of plug-ins, but I can't help noticing that it seems to be difficult-to-impossible for plug-in developers to keep plug-ins reliable as the development of R# proceeds. Is this because the API really does change all the time, even as part of a 0.0.1 bugfix release like the one currently in EAP?

Or is the problem that plug-ins tend to use the API incorrectly, and so they get caught by changes that shouldn't affect the API? (I am aware that the API documentation is not exactly fantastic)

(Agent Smith doesn't work with the current EAP builds, and RGreatEx seems to need a new version every few days to keep-up - perhaps their version-number checking is over-zealous, but perhaps they're just trying to avoid breaking on new versions.)

I understand why the API might change with a 3.x to 4.x revision, but surely JB owes it to the plug-in developers to keep things stable in between major releases?

What's the real problem here, and how could things be improved?

13 comments

Hello Will,

The short answer would be "stability vs evolution". To fix some bugs, to
improve performance, to reduce memory consumption we often need to change
architecture. It's like in "agile". When we change architecture we often
have to change API, because there is no special SDK, or API for plugin developers
- we just keep our system open and build it in modular way. In fact, most
of the ReSharper features can be detached from its kernel and deployed as
plugin. There is no special treatment of plugins, except for their initial
loading. Toolwindows, commands, option pages, language features, quickfixes
and analyses - all work through the same mechanisms in ReSharper itself and
in plugins.

We are constantly looking for a better way to deal with that dilemma and
some steps to reduce the pain are going to happen in 4.5. But having current
level of technology rush (new language versions every 2 years, new frameworks
every few months) doesn't leave us enough resources to polish API, or even
develop SDK shim with simplistic but stable API. So, I'm afraid, API still
will be changing regulary and may be even radically in the couple of next
few versions.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


WD> I am a user of Resharper, not a developer of plug-ins, but I can't
WD> help noticing that it seems to be difficult-to-impossible for
WD> plug-in developers to keep plug-ins reliable as the development of
WD> R# proceeds. Is this because the API really does change all the
WD> time, even as part of a 0.0.1 bugfix release like the one currently
WD> in EAP?
WD>
WD> Or is the problem that plug-ins tend to use the API incorrectly, and
WD> so they get caught by changes that shouldn't affect the API? (I am
WD> aware that the API documentation is not exactly fantastic)
WD>
WD> (Agent Smith doesn't work with the current EAP builds, and RGreatEx
WD> seems to need a new version every few days to keep-up - perhaps
WD> their version-number checking is over-zealous, but perhaps they're
WD> just trying to avoid breaking on new versions.)
WD>
WD> I understand why the API might change with a 3.x to 4.x revision,
WD> but surely JB owes it to the plug-in developers to keep things
WD> stable in between major releases?
WD>
WD> What's the real problem here, and how could things be improved?
WD>


0

Ok, Ilya - thanks for the answer - seems fair enough, though it's a rather miserable outlook for the plug-in developers.

I hadn't really appreciated that there was no 'published' API distinct from the internal code, and I know what a delicate balance has to be struck between backwards compatibility and excessive restriction of your ability to move forward.

Will

0

Or is the problem that plug-ins tend to use the API incorrectly, and so they get caught by changes that shouldn't affect the API? (I am aware that the API documentation is not exactly fantastic)


Documentation not exactly fantastic? Well, I haven't been able to find any at all...

0


Documentation not exactly fantastic? Well, I haven't been able to find any at all...


Yes, I was deliberately trying to be polite! It seems it's all a bit of a shambles, and everyone acknowledges that, but JB don't have the capacity to sort it out.

I guess the person at JB who thought having 3rd party plug-ins was a good idea has moved on to other stuff now.

Will

0

Ilya, that's the first time I've heard any explanation for the state of your
API and its documentation. Thank you very much. That was my greatest point
of displeasure with ReSharper.

From an architectural point of view, perhaps you should look back at your
last several API changes, and try to abstract out a framework layer that
would have remained stable with respect to your API changes. You may wind up
with a framework layer that does not expose your complete capabilities, but
it would at least be stable.

And you could even document it.

--
John

"Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
news:76a2bd0b15ed398caccef700d1b49@news.intellij.net...

Hello Will,

>

The short answer would be "stability vs evolution". To fix some bugs, to
improve performance, to reduce memory consumption we often need to change
architecture. It's like in "agile". When we change architecture we often
have to change API, because there is no special SDK, or API for plugin
developers - we just keep our system open and build it in modular way. In
fact, most of the ReSharper features can be detached from its kernel and
deployed as plugin. There is no special treatment of plugins, except for
their initial loading. Toolwindows, commands, option pages, language
features, quickfixes and analyses - all work through the same mechanisms
in ReSharper itself and in plugins.
We are constantly looking for a better way to deal with that dilemma and
some steps to reduce the pain are going to happen in 4.5. But having
current level of technology rush (new language versions every 2 years, new
frameworks every few months) doesn't leave us enough resources to polish
API, or even develop SDK shim with simplistic but stable API. So, I'm
afraid, API still will be changing regulary and may be even radically in
the couple of next few versions.
Sincerely,
Ilya Ryzhenkov

>

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>
>

WD> I am a user of Resharper, not a developer of plug-ins, but I can't
WD> help noticing that it seems to be difficult-to-impossible for
WD> plug-in developers to keep plug-ins reliable as the development of
WD> R# proceeds. Is this because the API really does change all the
WD> time, even as part of a 0.0.1 bugfix release like the one currently
WD> in EAP?
WD> WD> Or is the problem that plug-ins tend to use the API incorrectly,
and
WD> so they get caught by changes that shouldn't affect the API? (I am
WD> aware that the API documentation is not exactly fantastic)
WD> WD> (Agent Smith doesn't work with the current EAP builds, and
RGreatEx
WD> seems to need a new version every few days to keep-up - perhaps
WD> their version-number checking is over-zealous, but perhaps they're
WD> just trying to avoid breaking on new versions.)
WD> WD> I understand why the API might change with a 3.x to 4.x revision,
WD> but surely JB owes it to the plug-in developers to keep things
WD> stable in between major releases?
WD> WD> What's the real problem here, and how could things be improved?
WD>

0

In the case of "frequent EAPers", such as myself, I am not that upset that an existing plugin may stop working with a particular nightly build. But I wonder if RS, and plugin developers, might be able to agree on some sort of startup "supported" version check mechanism?

For example, if a plugin requires a certain version of RS at install time , I think the plugin should do the same sort of check at startup time to see if a different version of RS has been installed. If a plugin did a network ping to update their internal list of "supported RS versions" from their home site (similar to the checks if a newer version is available), then this would be a fairly transparent check. Personally, I could even live with a plugin using a modal popup to warn me that it is no longer "supported", with an option whether to disable the plugin for that session or take my chances.

If RS could put together a "sample" of such a mechanism, and publish it, I am pretty sure that most RS plugin developers would adopt it. Who know, this could be the start of a "certified RS plugin" program.

0

The problem I see with just 'better version checking' is that because nothing is ever considered stable in the API, then every single nightly build has to be assumed to be a breaker. That would basically rule out either plug-ins or EAP - unless the developers of the plug-ins could test their plug-in on every nightly build and update the 'compatibility list'.

To me it seems that stabilising the API is the important thing - I don't know enough about the internals to know what the implications of that would be, and it's clearly not a negligible bit of work, as it has management and control implications which are well beyond a mere bit of coding.

0

Hello John,

I'm sorry you feel displeasure with ReSharper, but there are cases when being
honest is better than being "marketingly polite". Every time we are going
to change something in architecture and API we try to decide, if it is really
needed. Quite often we decide we have to do this in order to give majority
of our users more performance, stability, features or whatever else. We DO
understand that it would be fantastic, if API would be easy to use, stable
and didn't require deep understanding, but unfortunately the problem area,
like C# language, is not that simple.

From an architectural point of view, last API change happened when we were
support C# 3.0. There are new "range variables" which don't work like local
variables, automatic properties without bodies and yet not abstract, different
rules in resolve and so on and so forth. All this new language features had
to be integrated into program model we build, at almost every level. And
of course, the model had to be changed to accomodate for those changes. Unlike
in Java world, we have a quickly changing language here, and have to update
our structures with each version of C# and VB.

There are also other changes which we have to do all the time. For example,
when people started using ReSharper on the mixed framework solutions (like
Compact Framework and Desktop Framework projects), we had to revisit our
treatment of mscorlib, and you'd better even don't think about how Microsoft
treats mscorlib for mixed projects :(

That said, we don't do architecture and API changes just for fun. We really
have to.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


JS> Ilya, that's the first time I've heard any explanation for the state
JS> of your API and its documentation. Thank you very much. That was my
JS> greatest point of displeasure with ReSharper.
JS>
JS> From an architectural point of view, perhaps you should look back at
JS> your last several API changes, and try to abstract out a framework
JS> layer that would have remained stable with respect to your API
JS> changes. You may wind up with a framework layer that does not expose
JS> your complete capabilities, but it would at least be stable.
JS>
JS> And you could even document it.
JS>
JS> "Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
JS> news:76a2bd0b15ed398caccef700d1b49@news.intellij.net...
JS>
>> Hello Will,
>>
>> The short answer would be "stability vs evolution". To fix some bugs,
>> to
>> improve performance, to reduce memory consumption we often need to
>> change
>> architecture. It's like in "agile". When we change architecture we
>> often
>> have to change API, because there is no special SDK, or API for
>> plugin
>> developers - we just keep our system open and build it in modular
>> way. In
>> fact, most of the ReSharper features can be detached from its kernel
>> and
>> deployed as plugin. There is no special treatment of plugins, except
>> for
>> their initial loading. Toolwindows, commands, option pages, language
>> features, quickfixes and analyses - all work through the same
>> mechanisms
>> in ReSharper itself and in plugins.
>> We are constantly looking for a better way to deal with that dilemma
>> and
>> some steps to reduce the pain are going to happen in 4.5. But having
>> current level of technology rush (new language versions every 2
>> years, new
>> frameworks every few months) doesn't leave us enough resources to
>> polish
>> API, or even develop SDK shim with simplistic but stable API. So, I'm
>> afraid, API still will be changing regulary and may be even radically
>> in
>> the couple of next few versions.
>> Sincerely,
>> Ilya Ryzhenkov
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>> WD> I am a user of Resharper, not a developer of plug-ins, but I
>> can't
>> WD> help noticing that it seems to be difficult-to-impossible for
>> WD> plug-in developers to keep plug-ins reliable as the development
>> of
>> WD> R# proceeds. Is this because the API really does change all the
>> WD> time, even as part of a 0.0.1 bugfix release like the one
>> currently
>> WD> in EAP?
>> WD> WD> Or is the problem that plug-ins tend to use the API
>> incorrectly,
>> and
>> WD> so they get caught by changes that shouldn't affect the API? (I
>> am
>> WD> aware that the API documentation is not exactly fantastic)
>> WD> WD> (Agent Smith doesn't work with the current EAP builds, and
>> RGreatEx
>> WD> seems to need a new version every few days to keep-up - perhaps
>> WD> their version-number checking is over-zealous, but perhaps
>> they're
>> WD> just trying to avoid breaking on new versions.)
>> WD> WD> I understand why the API might change with a 3.x to 4.x
>> revision,
>> WD> but surely JB owes it to the plug-in developers to keep things
>> WD> stable in between major releases?
>> WD> WD> What's the real problem here, and how could things be
>> improved?
>> WD>


0

It MAY rule out every nightly build, but it makes it a lot easier for someone who frequently jumps between nightly builds and official releases of RS to be made aware (and deal with) possible incompatibilities. For example, if I install a new build, receive the warnings, and go ahead and enable the RS-addon plugins, and everything works -- fine. If things don't work, then next time I can disable them, or rollback RS. This is preferable to having to manually concurrently track which RS-addon plugins I use and which versions of RS they work with.

A stable API would be ideal, but I don't think one has ever been achieved in any non-trivial software. I presume that JB tries to minimize breaking changes through overloads, and move plugin develoers along with etc., but since Microsoft owns the real underlying bits (and with Microsoft Phoenix labeled as the way of the future), I am not sure there is sufficient real benefit to JB/RS/addon-developers to spend the amount of time on formalizing the API that it would take.

0

Ah, yes, if you could ignore the warnings and carry on, that does sound like a good idea.

I don't think MS can be held to blame for the R# plug-in API churn, though they might be responsible for trying-up all JB's resources so that the R# API isn't better managed.

And on the subject of MS, I can run 20-year old bits of software on my PC here, which rather suggests than non-trivial bits of software (and hardware, for that matter) are able to maintain non-trivial stable APIs across massive passive changes - it's just that the associated costs are non-trivial too...

But I think we all know this is not a difficult technical problem we're discussing here, it's a difficult logistical one.

0

The reason I brought MS into the topic is that C#, .NET, VS IDE, VS SDK, ... are all MS bits, and frankly the degree of evolution in C# alone has been nothing short of mind-blowing from release 1.0 to 3.0. I would much prefer that RS keep up with the latest release of MS bits then spend time on designing a complete-enough API, that personally I don't think can be done in a time/cost-effective way.

As to 20-year old software, it is one thing to freeze an API and keep it around for 20-years all the while creating new APIs as the need arises. This goes with your "costs involved" argument, and is the whole "installed base/dusty-deck/Windows on Windows" issue. Same with the hardware -- x86 is a horrificly ugly architecture, but thanks to the billions of dollars spent by Intel/AMD we can get phenomenal peformance these days.

And personally, I am not convinced that it is worth it (in most cases) to maintain support for "deficient" APIs for too long. I, like all developers, would like to see advance warning of breaking changes, and better documentation from (insert name of any vendor including JB), but for most organizations there is a point of diminishing returns where you just have to orphan off a previous release. Especially if you want to keep the product price attractively low.

Especially with the concept behind RS (i.e. refactoring and smart support for large-scale application of syntactic/semantic code checks/changes), I am more inclined to encourage API evolution as needed, but with as little pain (i.e. please make liberal use of overloads, ObsoleteAttribute, ...) as practical.

0

Ilya, I greatly appreciate honesty. Please keep it up!

I understand that the changes necessary for ReSharper to support C# 3.0 this well must have been extreme. However, when I mentioned keeping a stable layer, that is with respect to the part that did not change. A stable architecture could have been created that would have permitted the creators of plug-ins to continue to use the features of ReSharper that target the features of C# that have remained stable.

Ilya, as great as ReSharper is, I think it can be much greater. I happen to think that much of the power of .NET comes from the fact that it is extensible, yet brings complex abilities much closer to where we, as developers, can use them. The same can be said for Visual Studio itself. Although the VS APIs are not very high level in many cases, so many developers have been able to create add-ins for it.

I have recently been using the Guidance Automation Toolkit to automate features of Visual Studio. I can do some fairly neat things with it, like create projects, classes, properties, or in fact, any code I need to. It would be absolutely super if I could also automate ReSharper in the same way. I can imagine things like doing some mass refactoring operation on a set of code, then automatically running the unit tests, and reverting the change if a unit test now fails.

Take a look at the Guidance Automation Toolkit/Extensions (http://msdn.microsoft.com/en-us/practices/aa718948.aspx) and the GAX Extensions Library (http://www.codeplex.com/GEL). In the latter case, source is available. Look especially at the various actions available for manipulating source code. You'll realize that ReSharper could do much better than this!

0

Please sign in to leave a comment.