ReSharper refactoring cannot handle #if compiler directives

While there are obvious coding workarounds. and I have never personally encountered this problem, I agree completeley that it is a serious issue that RS should address ASAP. In the mean time, have you tried using VS2008 renaming and does it show the same problem?

I don't think it would be much more involved for RS than the support for renaming occurrences in comments, so hopefully it can be resolved quickly.

So, how about it? Is it on a roadmap? I couldn't find this specific request in the feature tracker, but I may not have done the right search.

This is particularly important for projects that cross platform boundaries (such as Win CE, Mobile, etc.).

There's already a bug for this:
http://www.jetbrains.net/jira/browse/RSRP-65519

It appears to be currently assigned to the "Alderman" release, whatever that
is...

It doesn't appear we'll see this any time soon :/

--Oren

"John Long" <no_reply@jetbrains.com> wrote in message
news:10031460.112701215827065987.JavaMail.jive@app4.labs.intellij.net...
>I imagine this is a somewhat involved feature, but it is a big problem on
>large projects.
>

Take the code below:
private static void DummyMethod(int i)
{
Console.WriteLine(i);
}

>

public void TestMethod1()
{
#if DEBUG
DummyMethod(1);
#else
DummyMethod(2)
#endif
}

>

If I use ReSharper to rename DummyMethod, it will only be renamed in the
current project configuration (Release or Debug). Meaning that my code is
now broken in the other. You can find references in comments, but not in
code that is valid in other builds?

>

Is this feature even on the roadmap anywhere? For large, involved projects
it is really not that unusual a thing to happen.

Hello John,

As far as we know, Visual Studio doesn't handle non-active #if branches in
refactorings, too. And it is indeed almost impossibe task to handle right.
This generally means maintaining separate variations of Code Model for each
combination of known preprocessor symbols, which will completely kill performance
and RAM usage. Also, since it is preprocessor, parsing process doesn't see
non-active parts altogther. Changing this will make parser extremely complex,
slow and sometimes even impossible if you break language construct with #if/#else.


Generally, I recommend using Conditional attribute whenever possible:

private static void DummyMethod(int i)
{
Console.WriteLine(i);
}

[Conditional("Debug")]
private static void DebugDummyMethod()
{
DummyMethod(1);
}

[Conditional("Release")]
private static void ReleaseDummyMethod()
{
DummyMethod(2);
}

public void TestMethod1()
{
DebugDummyMethod();
ReleaseDummyMethod();
}

Compiler will optimize away calls which doesn't fit ConditionalAttribute.

Sincerely,
Ilya Ryzhenkov

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


JL> I imagine this is a somewhat involved feature, but it is a big
JL> problem on large projects.
JL>
JL> Take the code below:
JL> private static void DummyMethod(int i)
JL> {
JL> Console.WriteLine(i);
JL> }
JL> public void TestMethod1()
JL> {
JL> #if DEBUG
JL> DummyMethod(1);
JL> #else
JL> DummyMethod(2)
JL> #endif
JL> }
JL> If I use ReSharper to rename DummyMethod, it will only be renamed in
JL> the current project configuration (Release or Debug). Meaning that
JL> my code is now broken in the other. You can find references in
JL> comments, but not in code that is valid in other builds?
JL>
JL> Is this feature even on the roadmap anywhere? For large, involved
JL> projects it is really not that unusual a thing to happen.
JL>

Just a quick question -- the feature/bug is tentatively scheduled for that "Alderman" release -- can you say anything about the rought time-table for it? Is it 4.5 or 5.0? 6 months away; 2 years?

Thanks!

AFAIK still nog working, so more than 8 years now..

Still not working in Resharper 2018.1

It just caused a bug in my code where it saw a using as not needed... Well the using was not needed in debug mode bug due to #if it was needed in Release :-(