Iâve been plagued by âCircular
file references are not allowedâ errors on our converted ASP.NET 2.0
applications. This can happen when one ASCX control references
another which contains a reference back to the first, but can also
happen when thereâs no obvious circular reference, such as when an ASCX
control references another in a different directory that also
contains other controls that reference back to the first one,
or something like that (can you tell that I find this new build process
slightly confusing?)⦠Point is, how do you get rid of it?
The solution for first type of circular reference is to create
an abstract base class in the App_Code folder with one of the
references, then remove the Reference directive from the associated web
form or user control file. This will break the circular reference.
The
second type of circular reference is a by-product of the ASP.NET
compiler "batching" assemblies together for performance reasons. By
default it will take the web forms and user controls in a folder and
compile them into an assembly.
There are several ways to solve
this issue, but we recommend moving the referenced pages (e.g.
Pages2.aspx.vb and Pages3.aspx.vb) to their own folder. By default, the
ASP.NET compiler will create a separate assembly containing these pages
and the circular reference will be removed between Assembly A and B.
The circular references in our project werenât completely obvious,
and Iâve got bigger fish to fry right now than moving a bunch of
files to get around this batch compilation issue. Fortunately, I found some good discussion here about how to deal with this. .
One additional note on batch=false -- this tells the ASP.NET
compiler to not batch assemblies, and create an assembly for each web
form and user control. When it is set to true, then the compiler will
batch assemblies (in a non-deterministic way, but usually one per
folder) which may hide broken references, including circular
references. We recommend during development you run with batch=false,
but for deployment set batch=true. This flag is set web.config, e.g.
Basically, you can just turn off batching during
development, then turn it back on for deployment. Not a perfect
solution, I know but will work for the time being, until I can get
around to refactoring, to the recommend solution.
Another problem I ran into was running ASP.NET 2.0 and 1.1 applications side by side. It turns out that most
of the time, you can simply run your ASP.NET 1.1 compiled apps using
the ASP.NET 2.0 runtime, but I did have one project that didnât seem to
want to run under 2.0. So, I used the ASP.NET
configuration tab to set the offending app to run using ASP.NET
1.1. When I did this, Iâd get âServer Application Unavailableâ when running the project. A quick peek in the event log revealed the culprit:
It is not possible to run two different versions of ASP.NET in the
same IIS process. Please use the IIS Administration Tool to reconfigure
your server to run the application in a separate process.
Well, this message is a bit confusing.. By
âServerâ they really mean âSiteâ or âVirtual Directoryâ and by
âSeparate Process,â they really mean Application Pool. Setting
the 1.1 site to run in its own App Pool did the trick.
We spent half of today in production with ASP.NET 2.0! Hooray! Iâve still got the CSS switch ready to turn it off if things go haywire, but for now things look good!
Previous Topic
