SWEA broken in latest builds for MVC2 views (VS2010) ?

Hello Sergei,

I was unable to reproduce this problem. Which build of ReSharper are you
running? Does this happen with any solution or only with a particular one?
Thank you!

Andrey Serebryansky
Support Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hi,

Just trying to find out if I'm the only one who experiences this:

(i tried to find corresponding issue in youtrack but there were to
many false ambiguous invocation issues to deal with)

0. clean r# caches, restart vs, take sources from tfs 2010

1. open solution - swea says everything's ok

2. rebuild solution - swea says i've got bunch of errors:
ambiguous invocation/references etc..

(the problem appears only with views of mvc2 project)

is there any way to work around this - or maybe someone knows an
existing issue i should keep track of?

Regards,
Sergei
---
Original message URL:
http://www.jetbrains.net/devnet/message/5264853#5264853

Hi,

Builds are R#5.1: 1703, 1704, 1705
before these builds i wasn't able to run swea at all - 5.0 release and 5.1 endedup with overflow error exception (fixed since 1703).

the problem appeared in mvc2 project of a .net 4 solution

swea caches point to temp folder for me and i tried to clean them from resharper/options but they weren't deleted physically (not all of them) -> removed all caches manually and that seemed to fix the problem for now...

But for future reference:
1. clean resharper caches
2. open solution swea on - no errors ( swea analyses solution )
3. rebuild solution - after that swea detects lots of changes again and tries to reanalyze them ending up with bunch of false errors.

The bug is still there (build 1709 and all previous builds). It is hard to track - appears/disappears randomly - sometimes "Reanalyze files with errors" helps, sometimes - not.
The only thing in common is that all ambiguous errors are in MVC Views. References that are not resolved belong to a project form solution.

When I click Goto Definition on one of this ambiguous referenced members - it gives me choice of to lines that are the same except first one has an assembly version specified.

Regards,
Sergei

Is it possible you have an assembly reference to output of the project, instead
of the project itself? If this is the case, does it help to reference project
instead of output assembly?

Sincerely,
Ilya Ryzhenkov

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


IR> The bug is still there (build 1709 and all previous builds). It is
IR> hard to track - appears/disappears randomly - sometimes "Reanalyze
IR> files with errors" helps, sometimes - not.
IR>
IR> The only thing in common is that all ambiguous errors are in MVC
IR> Views. References that are not resolved belong to a project form
IR> solution.
IR>
IR> When I click Goto Definition on one of this ambiguous referenced
IR> members - it gives me choice of to lines that are the same except
IR> first one has an assembly version specified.
IR>
IR> Regards,
IR> Sergei
IR> ---
IR> Original message URL:
IR> http://www.jetbrains.net/devnet/message/5265393#5265393

Is it possible you have an assembly reference to output of the project, instead
of the project itself? If this is the case, does it help to reference project
instead of output assembly?

Errors are back again today. Nothing changed much since yesterday - rebooted pc, took latest version, rebuilt the solution and here they are... And i'm not the only one to experience them - my colleagues here have same problem (btw - it was temporarily fixed for them too by my yesterday's removal of duplicate reference in .proj file).

One additional thing that annoys me slightly - resharper tends to reanalyze half of the solution on every rebuild - it seems that it is really trying to get my referenced dlls from debug/bin folder instead of their original locations..

I double checked - all references in broken project are ok.

Regards, Sergei

I'm experiencing the same issues, although mine seems to appear in AS.NET Webforms whenever I change the build configuration (ie. from Debug to Release).
It's quite annoying as it makes the Solution wide analysis pretty much useless. :(

I can confirm getting similar problems with an ASP.NET 4 Web Forms application.

If have a Services project and a Web project. The Web project is referencing the Services project (I tripled checked: it's a project reference, not an assembly one). In the web project code behind files, everything is fine. However in embedded code statements in .aspx/.ascx files, I got a bunch of errors similar to "Cannot convert from MyServiceType [MyServices, Version=1.0.0.0, Culture=neutral] to  MyServiceType [MyServices]". Of course the code compiles and runs fine. It doesn't seem to be specific to SWEA since I also have the errors when it's off.

Using build 1717. Will try will build 1721 later today.

Julien, are you able to send us a sample solution for investigation? Thanks in advance.

Does it fix the errors to build the solution after you changed the configuration?

Sergey, I installed build 1721, cleared the cache and the solution opened without errors. However, as soon as I build the solution, the false errors get back. Plus, I find weird that SWA is rescanning about 210 files in the solution after a build since none have changed.

For the sample solution, I don't think I'm allowed to send you the whole solution but I'll try to strip it down to a simple reproducable case and keep you in touch.

No, it only helps if i clean the solution. If I clear the ReSharper cache and restart VS2010, it helps... sometimes. It's quite hard to tell the correct reproducing steps. It only seems to happen in some projects though.

Weird :( It would be terrific if you manage to reproduce the problem reliably.

Thanks in advance.

It seems to be consistent with user controls as embedded resources. I get ambiguous reference errors for the user control's codebehind file. If I clean the project, the error disappear, but then my 3rd party reference can't be resolved (Telerik).
There just don't seem to be a way to keep it happy ;)

Any news on this issue?

I was having a similar issue with a large webforms application (VS Web Site project) after upgrading it to VS 2010 from VS 2008.  The web site referenced three class library projects, and "ambiguous reference" errors would appear for references to any classes within one of those projects.  Intellisense would show two references to the class - one with version number and one without.  One of the references took me to the object explorer, the second to the source code file.

I eventually found that even after I excluded the class library project from the solution (but left the dll in the bin so the solution would build), the solution (sln) file still contained a reference to it, like this:

Project("{F568B08F-ADFE-45F6-E423-5ABD9991F28F}") = "SomeProjectName", "SomeProjectName\SomeProjectName.vbproj", "{AEFEE856-1234-40BD-AEBC-191CF38FA9A9}"

EndProject

So I think the issue was that before I excluded the class library from the solution, there were actually two references to it in the sln file. All of the ambiguous reference errors cleared up immediately as soon as I (1) excluded the project, (2) cleared the orphaned Project reference in the sln file, and (3) added the project back into the solution.

I hope this helps someone...

I just realised that the problem occurs when you have multiple Platform Configurations. If I fx has both "Any CPU" and "x86" as configuration platform, VS2010 creates a subfolder, under bin, called x86. The "Any CPU" configuration is always placing the output assemblies in the root bin-folder.
I have no clue how to avoid this issue, but it is annoying the heck out of me..!

Kenneth,

My apologies for the delayed answer - I've been on vacation. It's very interesting thing with multiple configurations. Could you reproduce the problem on a small sample solution?
Even if not, could you please send me a sample solution for investigation. Thanks in advance.

I've been reproducing this behavior for awhile, even with the latest 5.1.  I have not been able to repro the problem in a solution that has code I could share.  I wanted to share a workaround.

In my case, MVC was failing to recognize the view's base type.  For the Page tag below, it would complain about ViewPage<>.

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="ViewPage<IEnumerable<UserCommentRecord>>" %>

To get Resharper to work, I created a class that inherits from ViewPage<IEnumerable<UserCommentRecord>> and use it instead:

<%@ Page Title="" Language="C#"  MasterPageFile="~/Views/Shared/Site.Master"  Inherits="MyComponent.Foo" %>

where Foo.cs

namespace MyComponent
{
    public class Foo : ViewPage<IEnumerable<UserCommentRecord>> { }
}

Hi,

I've been trying to reproduce the problem, but it seems to be non-existing in new solutions. The behaviour is quite strange, as a few other developers isn't experiencing this behaviour at all, even with the same solution.
This, of course, leads me to believe that the problem is local. However, others are experiencing identical problems, so I'm _not_ the only one with problems - though it might seem that way at the moment :)

Is there any way to "hard reset" ReSharper? Lately I've been upgrading to the latest nightly builds, which (in my mind) could corrupt the cache or something like that?



Kenneth

Aw man... That's just wrong! :D
I'd never redesign my application to get some tool working - that's the path to the dark side. Either the tool works or it doesn't ;)



Kenneth

I agree but after spending enough time trying to make it work, I'm inclined to accept a partial solution.  This workaround hasn't really helped though, I still would bogus error messages.  I had to turn off resharper autocomplete, now I can edit MVC files with autocomplete but the errors reported are all wrong.

I worry that by the time this is fixed, MVC3 and Razor will be out causing new problems.  I'm consider redoing the MVC project porting things over until I find the problem.  It could very well be the config or csproj is missing something.  But Resharper is supposed to save time not add project hours.

I would like to be able to just disable Resharper completely for aspx files (and Razor, etc).

Your point, that it might be a config or csproj (or sln even) is actually quite interesting.
Since I'm unable to reproduce my issues with new projects, but only old, converted, ones, seems to support that idea.

I, on the other hand, haven't got the time to "redo" all my projects. It's a timeconsuming task, that is difficult for managers to understand.
If this is a bug in ReSharper, JetBrains should provide a tool for cleaning up the files that are causing the problems...

Kenneth

I cannot reproduce the problem. Could you provide me with a sample solution? Thanks in advance.

The only thing you can do is remove caches (Resharper | Options | General | Clear caches )and restart VS.Hope, it helps.

I'll see if I am able to create a .NET 2.0 solution, upgrade til to 3.5 and see if the problem still exists.
I believe it may have something to do with the upgrade process breaking the config- or projectfiles, but I am not sure.

Kenneth

Yeah it could be related to upgrade.  My project was also originaly ASP.NET MVC 1.0, upgraded to ASP.NET MVC 2.0.  I did a manual upgrade following the instructions at http://www.asp.net/learn/whitepapers/aspnet-mvc2-upgrade-notes.  I also had SparkViewEngine installed at the time.  I've removed SparkViewEngine (which made me sad) in hopes of helping Resharper support MVC 2.

Sergey I don't have any code that reproes this that I can share.  I did  spend a good amount of time trying to get a repro last night.  Maybe I  could just send the web.config and csproj files, do you have an email  address I could use?

qx [at] jetbrains [dot] com