Any way to disable these analysis errors?

Hi all,

my first question, so please excuse me if I'm missing something obvious (or not-so-). I did find this relevant link, though: <[http://support.jetbrains.com/kb/entry!default.jspa?categoryID=28&externalID=142&fromSearchPage=true|http://support.jetbrains.com/kb/entry!default.jspa?categoryID=28&externalID=142&fromSearchPage=true]>.

Our team of a dozen or so developers is considering using ReSharper instead of (or as well as) VisualAssistX. So far a couple of us have full licenses but we're seeing a couple of issues which would make it a bit of a pain to use.

There are two or three of the solution analysis errors which trigger lots of false positives because of the way our solution is set up, and I'm wondering if there's some way to completely disable analysis of just those options. I've looked under "ReSharper > Options > Code Inspection > Inspection Severity" but they don't appear there. I also don't seem to be given any option to disable the errors with comments, although I'd rather not do that anyway, as there are hundreds of occurrences of these all over our code.

We have a large solution (28 projects) with mixed C# and C++ projects. Some projects are referenced using DLL references instead of project references, for obscure reasons to do with how we package DLLs further down the line, and some have custom MSBuild steps which generate code at compile time.

The specific errors I'd like to be able to turn off are:
- "Argument type ... is not assignable to parameter type ..." (not sure if this is caused by the C#/C++ mix or the DLL-instead-of-project references, or something else)
- "Cannot resolve symbol ..." (caused by our on-the-fly code generation, and the output files not being in the project's files/items)

There could be cleverer ways to work around these, but I'd be happy if I could simply turn off these particular analyses altogether (which I'm assuming would be relatively easy).

Thanks,
Hugh.

7 comments
Comment actions Permalink

Hmm...
Does this errors disappear after full solution rebuild?
If not, please could you try to create the small solution which demonstrates
this problem, and send it to us for analysis?

As for inspection severity - compiler errors couldn't be configured. Of
course this is the problem if ReSharper is wrong (shows red underline, but
solution compiles fine), but fixing such problems is high-priority task

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Hugh Greene" <jetbrains@tameter.org> wrote in message
news:24892091.148761216825323764.JavaMail.jive@app4.labs.intellij.net...

Hi all,

>

my first question, so please excuse me if I'm missing something obvious
(or not-so-). I did find this relevant link, though:
<[http://support.jetbrains.com/kb/entry!default.jspa?categoryID=28&externalID=142&fromSearchPage=true|http://support.jetbrains.com/kb/entry!default.jspa?categoryID=28&externalID=142&fromSearchPage=true]>.

>

Our team of a dozen or so developers is considering using ReSharper
instead of (or as well as) VisualAssistX. So far a couple of us have full
licenses but we're seeing a couple of issues which would make it a bit of
a pain to use.

>

There are two or three of the solution analysis errors which trigger lots
of false positives because of the way our solution is set up, and I'm
wondering if there's some way to completely disable analysis of just those
options. I've looked under "ReSharper > Options > Code Inspection >
Inspection Severity" but they don't appear there. I also don't seem to be
given any option to disable the errors with comments, although I'd rather
not do that anyway, as there are hundreds of occurrences of these all over
our code.

>

We have a large solution (28 projects) with mixed C# and C++ projects.
Some projects are referenced using DLL references instead of project
references, for obscure reasons to do with how we package DLLs further
down the line, and some have custom MSBuild steps which generate code at
compile time.

>

The specific errors I'd like to be able to turn off are:
- "Argument type ... is not assignable to parameter type ..." (not sure if
this is caused by the C#/C++ mix or the DLL-instead-of-project references,
or something else)
- "Cannot resolve symbol ..." (caused by our on-the-fly code generation,
and the output files not being in the project's files/items)

>

There could be cleverer ways to work around these, but I'd be happy if I
could simply turn off these particular analyses altogether (which I'm
assuming would be relatively easy).

>

Thanks,
Hugh.



0
Comment actions Permalink

Hello,

- "Argument type ... is not assignable to parameter type ..." (not
sure if this is caused by the C#/C++ mix or the DLL-instead-of-project
references, or something else)


That very well could be. If a symbol is declared in C#, then used in some
C++/CLI code, say in a member signature, and then that method is called from
a C# project (like, C# — C++ — C# chain), then currently R# might have a
hard time realizing that the type coming from C++ and the C# type are the
same thing. We discovered the issue too late in the release cycle, so the
fix didn't get into the R#4 release :(

Probably, there's no workaround for R#4. I've ran into the same issue in
a solution where the use of such "tunneling" types is low, but I can see
how it makes things hard if there're lots of such usages.

- "Cannot resolve symbol ..." (caused by our on-the-fly code
generation, and the output files not being in the project's
files/items)


We have some generated code too, and we would include the generator output
files into the project (but not to the source control, obviously). This way
R# can "see" all of the types coming from the generated files. After the
first full build of the solution, the files are there and all of the red
"false errors" go away.

If the files could not be included into the project for some reason, their
usages are considered "unresolved symbol errors", not unreasonably at that.
If the generated classes are used only in a few places, the issue could just
be ignored (you don't see red code unless you open the file, and the errors
in Solution Wide Analysis could be ignored on per-error or per-file basis).
If the generated classes are widely used across the solution, then it's a
problem. I'd consider trying to add the files to the project somehow as the
first approach. If that is not possible, I'd try introducing wrappers for
the generated code so that to keep the actual references to the generated
classes to a few files I wouldn't ever open and see the red code (this is
not always possible or reasonable though).

There is special support in R# for certain compile-time-code-generation technologies,
like ASPX and XAML. What is the case your generated files are addressing?

There could be cleverer ways to work around these, but I'd be happy if
I could simply turn off these particular analyses altogether (which
I'm assuming would be relatively easy).


The "unresolved symbol" error is among the most useful R# analyses. It allows
to see the broken code right when you write it and before you can compile
the whole bunch of new classes. On this error the Import Popup appears and
suggests introducing a using directive for the namespace of the unresolved
symbol if that'll make it non-red. There're QuickFixes on this error to create
the missing methods and classes, which allows to create new symbols by first
calling them as if they already exist (TDD and so on).

Unfortunately, in the current R# version it's not possible to suppress most
errors in the code files. They could only be excluded from the Solution-Wide
Analysis list, a real-time view on all of the errors in the solution.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

I am having the same problem while evaluating Resharper 4. In all previous versions we did'nt have any problems, and in 4 we get several errors like this - "argument type '...' is not assignable to parameter type '...'

Any news about when you are going to fix this? This could be a showstopper for us migrating to the new version.

--Coby.

0
Comment actions Permalink

Hi Eugene,

thanks for your quick response, and sorry it's taken me a while to isolate a reproducible example. For now I only have an example for the "Cannot resolve symbol ..." (caused by our code generation), which is in the attached ZIP. I'm working on the other and will post another reply when I have a good example.

In the attachment there are two solutions. First you need to build the "CustomTask" one to create a custom MSBuild task. Then you should open the AppWithGeneratedCode solution and, when you get a Security Warning (because the build task is unsigned), choose "Load project normally". If you open Program.cs, you'll seethat ReSharper says "Cannot resolve symbol 'Three'". You can build and run the solution, but the error still exists.

It may seem odd that both the input to and output of the custom build task are not included in the ".csproj" file, but this is a valid way of using MSBuild, so it would be good if ReSharper could handle it. Let me know if you need more info.

Thanks,
Hugh.



Attachment(s):
ReSharperCodeGenProblem.zip
0
Comment actions Permalink

Hello,


Hi Serge,

apologies for the slow reply -- I thought I'd managed to set up the "new reply notification" on your forum, but I didn't seem to get a message about your posting. I'll check that again ...

- "Argument type ... is not assignable to parameter type ..." (not
sure if this is caused by the C#/C++ mix or the DLL-instead-of-project
references, or something else)


That very well could be. If a symbol is declared in C#, then used in some
C++/CLI code, say in a member signature, and then that method is called from
a C# project (like, C# — C++ — C# chain), then currently R# might have a
hard time realizing that the type coming from C++ and the C# type are the
same thing. We discovered the issue too late in the release cycle, so the
fix didn't get into the R#4 release :(


As I just said in my other reply, I'll let you know more about this once I've managed to reproduce it in a small example. Maybe the fix can make it into 4.1? ;)

- "Cannot resolve symbol ..." (caused by our on-the-fly code
generation, and the output files not being in the project's
files/items)


We have some generated code too, and we would include the generator output
files into the project (but not to the source control, obviously). ...


I did try that temporarily and it fixed the problem, but it's not really a workable solution for us.

There is special support in R# for certain compile-time-code-generation technologies,
like ASPX and XAML. What is the case your generated files are addressing?


We're writing our own domain-specific application framework, and generating a large number of constant values used as keys into our own resource mechanism, for localised (or otherwise customised) text, images, etc. There were various design decisions which led us away from using the standard Windows resource mechanisms. The resource input files are expected to be edited relatively often as the code base evolves, and we don't really want to have to manually update the list of generated files if we can avoid it.

Actually, I think there's enough information in the ".csproj" file to allow ReSharper to find the files dynamically, though I've no idea how easy/urgent that would be for you. I think you just have to look inside the

element (and any targets it depends on) for children of the form ]]>

then extract the path specifications "XXX" and scan the disk for any matching files, and treat them as included in the project. Easy in theory ...

There could be cleverer ways to work around these, but I'd be happy if
I could simply turn off these particular analyses altogether (which
I'm assuming would be relatively easy).


The "unresolved symbol" error is among the most useful R# analyses.


Absolutely -- I think it's great, and the import popup is one of my favourite features. But with so many false positives in our solution it becomes a pain.

Unfortunately, in the current R# version it's not possible to suppress most
errors in the code files. They could only be excluded from the Solution-Wide
Analysis list, a real-time view on all of the errors in the solution.


Oh well -- can I post a feature request somewhere? :)

Thanks,
Hugh.

0
Comment actions Permalink

Thank you. I've received the solution, and the we are investigating the
problem.
You can monitor it's state here:

http://www.jetbrains.net/jira/browse/RSRP-76882

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Hugh Greene" <jetbrains@tameter.org> wrote in message
news:17104118.197371217934078099.JavaMail.jive@app4.labs.intellij.net...

Hi Eugene,

>

thanks for your quick response, and sorry it's taken me a while to isolate
a reproducible example. For now I only have an example for the "Cannot
resolve symbol ..." (caused by our code generation), which is in the
attached ZIP. I'm working on the other and will post another reply when I
have a good example.

>

In the attachment there are two solutions. First you need to build the
"CustomTask" one to create a custom MSBuild task. Then you should open
the AppWithGeneratedCode solution and, when you get a Security Warning
(because the build task is unsigned), choose "Load project normally". If
you open Program.cs, you'll seethat ReSharper says "Cannot resolve symbol
'Three'". You can build and run the solution, but the error still exists.

>

It may seem odd that both the input to and output of the custom build task
are not included in the ".csproj" file, but this is a valid way of using
MSBuild, so it would be good if ReSharper could handle it. Let me know if
you need more info.

>

Thanks,
Hugh.



0
Comment actions Permalink

Hello,

apologies for the slow reply -- I thought I'd managed to set up the
"new reply notification" on your forum, but I didn't seem to get a
message about your posting. I'll check that again ...


I'd recommend using NNTP if possible (news://news.jetbrains.com/jetbrains.resharper.community),
this way the new posts will be downloaded right into your News reader, like
Outlook Express / Windows Mail / JetBrains Omea / etc. The Web forums are
a mirror to the newsgroups, so they're more failure-prone.

>>> - "Argument type ... is not assignable to parameter type ..." (not
>>> sure if this is caused by the C#/C++ mix or the
>>> DLL-instead-of-project references, or something else)

As I just said in my other reply, I'll let you know more about this
once I've managed to reproduce it in a small example. Maybe the fix
can make it into 4.1? ;)


We're getting ready with 4.0.1, which is mostly a "service pack" release.
I'm afraid the fix is dangerous enough to get into the SP, if it means changing
the infrastructure. Eugene Pasynkov should know for sure :) But the fix seems
like getting into the 4.x version.

>> We have some generated code too, and we would include the generator
>> output files into the project (but not to the source control,
>> obviously). ...

I did try that temporarily and it fixed the problem, but it's not
really a workable solution for us.


Why is it so?

The resource
input files are expected to be edited relatively often as the code
base evolves, and we don't really want to have to manually update the
list of generated files if we can avoid it.


Ah, the dynamic set of generated files. That's one of our compile-time code
generation cases as well. We'd leverage the wildcard support in MSBuild static
item groups, like this:

]]>

The only problem is that you have to reload the project after the set of
files changes. However, that's far from editing the file list by hand, and
would not happen that often.

If the files mainly consist of constant declarations rather than code, I'd
consider emitting them into a separate assembly during the pre-build step
and referencing that assembly as a DLL reference of the project. This way
R# will catch up with modifications after the project is first built, you
don't have to reload anything for that.

Actually, I think there's enough information in the ".csproj" file to
allow ReSharper to find the files dynamically, though I've no idea how
easy/urgent that would be for you. I think you just have to look
inside the

<Target Name="BeforeBuild">

element (and any targets it depends on) for children of the form

<CreateItem Include="XXX">
<Output TaskParameter="Include" ItemName="Compile"/>
</CreateItem>
then extract the path specifications "XXX" and scan the disk for any
matching files, and treat them as included in the project. Easy in
theory ...


The "BeforeBuild" target is just one of the (clumsiest) ways of patching
the project file, often the CompileDependsOn or PrepareResourcesDependsOn
or whatever property group will be modified to include the additional dependencies,
and the CreateItem task (or its replacement, ItemGroup child of the Target
element) would use the output from custom build tasks as the source for populating
the Compile item group. Too many variations, and usually you can't know the
item group contents without running the build process per se, to see the
live output.

In the case indicated by the CreateItem sample above, it's easy to include
the generated files right into the project using the wildcard. This way your
build will work roughly the same way it would right now, and R# will see
the necessary declarations to go green. You'll have to add a few lines instead
of CreateItem though, otherwise the build process will use the set of files
BEFORE generation (when the build of the project starts), not after.

I still think that emitting the resource keys into a separate assembly referenced
in the project looks like a more elegant solution, if it's possible. The
Compile item group modification protocol, as described above, is still available
as an alternative, as far as our build works :)

>> The "unresolved symbol" error is among the most useful R# analyses.

Absolutely -- I think it's great, and the import popup is one of my
favourite features.


In the .NET Framework source code by Microsoft some of the using directives
in the head of the file are hand-annotated with comments, like, the reason
that using was added. Makes you feel the difference, actually :)

But with so many false positives in our solution
it becomes a pain.


Let's see if it's possible to keep from hiding the generated files from VS
project model, like described above, and the problem could very well go away.

Oh well -- can I post a feature request somewhere? :)


http://www.jetbrains.net/jira


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0

Please sign in to leave a comment.