Can't access internal class' members in 2.0

[Plamen Doykov]

Hi all

I have converted a simple project from ASP.NET 1 to 2.0 with the latest
prerelease of Visual Studio 2005. The problem is I can't access internal
members from the code behind. It gives: error CS0122: 'Class' is
inaccessible due to its protection level
This happens only when access members from code behind, not from the other
classes. It compiles OK when making the class and its members public.
However, I don't want to do that.
Any suggestions will be appreciated

Thanks
Plamen

 

[Paul Glavich [MVP ASP.NET]]

Have you made some "protected" fields public to get access to controls
and/or their values?

I know that the conversion wizard changes this to fit in with the partial
class auto-generated code. The way to fix it being to expose the
properties/controls as public properties that wrap the access to those
control properties or the property values themselves, and have your consumer
classes reference/use the public properties, rather than the modified
"public" fields (which were originally private or protected.

 

[Guest]

I have not played with this for awhile, so I can only give you a response
that will put you on the right track. It will be up to you to determine the
path.

Reason: By default, ASP.NET 2.0 compiles each page to a separate class
assembly. You can, however, precompile the application and, if my
recollection is correct, this compiles into a single assembly. In a single
assembly, internal methods are accessible; in separate assemblies, they are
not.

There is a downside to going to single assembly builds, however. You cannot
update single pages without a full site deploy. This is like the 1.x model,
so it not a big deal.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Juan T. Llibre]

re:

Reason: By default, ASP.NET 2.0 compiles each page to a separate
class assembly. You can, however, precompile the application and,
if my recollection is correct, this compiles into a single assembly.

We may soon have an option to compile to a single assemby without
needing to pre-compile the application, according to Scott Guthrie :

http://weblogs.asp.net/scottgu/archive/2005/08/28/423888.aspx


"Note: one request we've heard from several people since Beta2 has been to
provide a new third compilation granularity option above which would allow you
to merge the assembly output from multiple directories into a single assembly
that has a well known name that you define (and which does not change across
re-builds - which is one unfortunate side-affect of the per-directory build option today).

We are working on a tool right now that does this, and have a prototype up and
running that seems to work great. I'll provide more details on this over the next
week or two once we confirm that it fully works for all scenarios."

He announced that last August 28, although the tool hasn't been made available yet.

 

[Plamen Doykov]

Thanks

It still doesn't work for me, but at least I know what is going on after
reading Scott Guthrie' blog.
It seems quite strange to me to have by default building assemblies for each
subdirectory in the project. Subdirectories are designed from an user
interface point of view while building units (assemblies in this case)
follow a different design logic. Having an option for each page to be in its
own assembly can be reasonable, but I would certainly expect each project to
build in its own assembly, thus leaving (and even forcing) the designer to
carefully chose wich code goes into which assembly. Unfortunately this
obviously sensible option is still left unimplemented in VS2005. Strange
logic.

 

[Bruce Barker]

asp.net 1.1 built all pages into individual assemblies (unless batch is
used). while VS2003 compiled all the codebehind into one dll each aspx page
became it own assembly.

VS2005 uses partial classes to get around all the problems of the 1.1
codebehind model, a side effect is the seperate dll. if you want pages
talking to each other, you should use the base class model, as the VS2005
import wizard does.

-- bruce (sqlwork.com)

 

[Scott Allen]

He announced that last August 28, although the tool hasn't been made available yet.

I've heard it will be availble around RTM time, or soon thereafter -
but it is coming, and it's not spang