[210] ASP - Erroneous duplicate member detection between a class and its associated .ascx

Hi,

I'm still struggling with VSNET 2005 to get it to let me work the way I
want, so the situation may not be 'standard'. Anyway, here's a little
problem Resharper seems to be having :

I create a project intended to be a web application (for testing purposes).

Just as in VSNET 2003, but not for the same reasons, I used the Class
Library template. I don't intend to use this 'Web Site'...
thing. Don't even get me started on all the 'wonderful' new features of this
IDE. I don't need 50 wizards telling me where to put my application's
settings. I need a development environment.[/unrelated rant]

I add a .ascx file containing this :
]]>

I add the corresponding class in a .cs file :
public class Test : System.Web.UI.UserControl
{
protected System.Web.UI.WebControls.Repeater TestRepeater;
protected System.Web.UI.HtmlControls.HtmlInputHidden TestInput;
}

ReSharper indicates an error on TestRepeater, saying (in both files) that
the member name is already declared.
TestInput is not affected, the compiler is quite happy with both and
everything runs fine.

The same goes for .aspx files and Page classes.


While I'm at it, two other related things :

ReSharper also indicates an error because he wants me to add 'partial' to
the class definition, though there's no reason to do it.

Last, would it be possible to have an option to make Resharper simply ignore
.aspx and .ascx files ?
The validity checking may be useful from time to time, but not frequently
(in my case anyway). I'm not a fan of having a mix of HTML generated in the
code and 'pure' HTML in the .aspx/.ascx files, so I tend to have many of
those files with mainly 'pure' HTML. RS loses a lot of time on them (at
least on startup), and it's really not that useful (especially when it comes
with errors like the one above that would never appear if the .ascx file
wasn't looked at :)


Regards,

Lionel



4 comments
Comment actions Permalink

Lionel,

Your coding style is really absolutely not 'standard' in VS2005. I'll think
it over, how to fix the problem, but I cannot promise the fix in the nearest
build.
We'll discuss the option to ignore asp files, but I don't think, we would
accept it.

--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

"Sergey V. Coox (JetBrains)" <qx@intellij.com> wrote in message
news:dmf00a$t9e$1@is.intellij.net...

Your coding style is really absolutely not 'standard' in VS2005.


Ah, one of my preferred topics :)

The 'standard' way in VS2005 is to let the wizards and designers drive the
code. That has never been my way :)

In VS2003, using a Class Library project instead of the ASP.NET template was
a necessary workaround to be able to use Subversion (without a special build
to rename the .svn folders to _svn). A side effect was that it's also much
faster (no connections to IIS from the IDE to slow everything down).
The 2003 ASP.NET designer is also both horrible and really bad at generating
valid XHTML (and keeping it the way the developer meant to), so not using it
was necessary to keep the control on the output.
Last but not least, the WebForms model comes with many limitations and
unnecessary 'gadgets' that quickly complicates a lot of things. You just
have to look at the various posts of people having various problems with the
timing and order of execution of events, managing nested controls, having
'Enter' work as expected, side effects of relying on the viewstate and/or
using session variables as a quick way out of some problems while creating
others down the line, ...

Fortunately, ASP.NET is not limited to the WebForms model. You don't /have/
to use the designer, limit yourself to one server form per page, use the
viewstate without control over which parameters are sent to which page,
forget about having pages that are displayed correctly on any browser ,
tearing your hair off about 'Back' management and direct links to various
parts of the web site, and so on. ASP.NET is much more flexible than that.

Using a Class Library project under 2003 was an obligation (for Subversion),
without any negative side-effect. Doing the same under 2005 is not an
obligation for SVN, but is still a (huge) simplification when you don't need
the various 'tools' added to the IDE. Especially when a Web Site project
comes with strange behavioural changes. Besides, it doesn't change anything
about the bug this topic is about since it also happens if the project is
using the Web Site template :)

Not using the designer is probably a more likely cause. And as far as I
know, it's not /that/ non-standard a way to develop ASP.NET applications
(I'm not the only one having a bone to pick with this designer). It's not
the WebForms way of doing things, but it's still supported by ASP.NET.

Another possible cause would be not having the .aspx and .cs files linked in
the IDE. However, that's even less non-standard. Having the .aspx files in
one project and the .cs files in another is not that rare.


Sorry for ranting about this, it's an old source of discussions :)
I've been working on ASP.NET projects since .NET 1.0 so I've had a lot of
time to think about the WebForms model and its alternatives, and to talk
about it with quite a few people (on both sides). I've gotten used to
defending the alternatives :) I've gained too much by staying clear of
WebForms to have any intention of going back, especially when I see the
various problems people are still having with it.
It's kinda like using wizards to build a WinForms application vs coding
everything yourself, when and where you want it. Or using the unit testing
facilities of VS2k5 to create test cases by the dozen vs doing TDD (as shown
by the uproar caused by the short-lived MS article about it a few days ago).
Using tools to drive the development vs driving the development yourself,
using the appropriate tools at the appropriate time.

ASP.NET is a strange beast. WebForms is only a part of it.

I'll think it over, how to fix the problem, but I cannot promise the fix

in the nearest

build.


It's just a little glitch and not a show stopper, so there's really no rush
:)

We'll discuss the option to ignore asp files, but I don't think, we would
accept it.


Not a problem, I can live with it. As I said in the first post, having a
validation on those files can be useful, and the slowdown is only on
startup. As long as it doesn't throw dozens of exception windows (as build
209 did), it's more than usable :)


Regards,

Lionel Guilhou


0
Comment actions Permalink

Lionel,

Frankly speaking, I'm quite agree with You concerning MS designers (both
WebForms and WindowsForms :) but we have to pay attention to a couple of
things. First, there are too many people who uses it as they've been taught
to, so we have to support this coding style.
Second, our current architecture does not allow to evaluate effectively at
some early point whether base class of the web page contains field in
question or not - so we do not know whether the field should present in
generated code-behind or not.

But anyway, it's a very interesting problem, and I hope, we'll solve it
soon.

--
Sergey V. Coox
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

"Sergey V. Coox (JetBrains)" <qx@intellij.com> wrote in message
news:dmf8pm$l9j$1@is.intellij.net...

Frankly speaking, I'm quite agree with You concerning MS designers (both
WebForms and WindowsForms :)


You just made me love JetBrains even more :)

but we have to pay attention to a couple of
things. First, there are too many people who uses it as they've been

taught

to, so we have to support this coding style.


Of course. I'd never suggest to complicate things for them. I'd love to, but
it would not be realistic :)
It's unfortunately the most popul... er no, let me rephrase... the most used
way of doing things, since it both the easieset way to have something
runnable without knowing too much about the technology and MS is putting the
focus on it (VS being /heavily/ tool oriented).

It's only logical that RS would also focus on it first.

Second, our current architecture does not allow to evaluate effectively at
some early point whether base class of the web page contains field in
question or not - so we do not know whether the field should present in
generated code-behind or not.


In doubt, maybe a warning would be better than an error then ?

But anyway, it's a very interesting problem, and I hope, we'll solve it
soon.


Good luck :)


Regards,

Lionel


0

Please sign in to leave a comment.