Control of Web Assembly Generation

[john]

Maybe I haven't had that "a-ha" moment yet, but I think the new
approach to web projects is a step in the wrong direction. My main
beef is that control over the assembly generation process has been
taken away from us! I also don't agree with the logic behind a web
site not having a project file, but I'll save that for another thread!
Here's our scenario:
We have a web project that runs in a non-managed sharepoint directory.
The web project is a strongly named assembly and is deployed to the GAC

on production web servers. Each of our pages in the web project
contains strong references to server controls that are in the same web
project, for example: Register TaxPrefix="ctl"
Assembly="Company.Technology.Class,Version=1.0.0.0 ,Culture=Neutral...".

In addition, all of our page directives use strong references. We
used the migration wizard, and it moved all the class files to the
app_code directory. When we precompiled, we got an app_code.dll and an

assembly for each page. Of course, our app won't work with this setup.

In order to get our application over to 2.0 (which we are eager to do)
we have to modify about 100 pages to point each control directive to
app_code and each page directive to some seemingly randomly named
assembly (which could change if someone forgets to use the fixed name
option). We want to use strong references. I suppose we could put
App_Code in the GAC, but I have more than one application on the
server, how would that work? If I want to use strong references in my
page directives, am I supposeed to put hundreds of randomly named
assemblies into the GAC as well? I haven't even figured out how to make

a strong reference to the app_code assembly yet! What is the version--
0.0.0.0?
Another issue I have is that you can no longer reference a web project
from another assembly. We have components that make references to
classes (not aspx pages) in the web project. I don't believe there are

any design issues with putting web-related classes into a web project,
plese speak up if you disagree. You can no longer add a reference to a

web project, so we have to change our design.
I have come to the conclusion that the only way to get to 2.0 is to
de-stabilize the solution and move shared classes into a separate
assembly. We must also touch every page and change the page directives

to lose the strong references.
I'm sure there are workarounds, but this isn't a V1 product. Don't
take away features, add them! It's early days, and I can only hope for

a service pack to fix it.
Maybe some of you smart guys can answer some of these questions for me:

1.) What is the logic behind special web folders that result in
separate assemblies ?
2.) Why would you want an assembly for each page ?
3.) Why can't you add a reference to a web project--is there some kind
of fundamental design issue or is this out of technical necessity ?
4.) Why can't I put my web assembly(s) into the GAC and use strong
references in my page and control directives ?
5.) Why is the fixed name and generate an assembly per page put
together in one option-- aren't they two different things ?
John Powell

[Scott Allen]

I posted a reply in a previous thread, but I'll put it here, too, with
some additional resources.

1.) What is the logic behind special web folders that result in
separate assemblies ?
There have always been separate assemblies. In 1.1 when the asp.net
runtime parsed and compiled ASPX and ASCX markup, it produced multiple
assemblies in the temporary asp.net files directory. Visual Studio
compiled the rest (the code-behind).

The biggest difference in 2.0 is that the IDE doesn't do any
compilation - the ASP.NET platform does all the compilation.

This post is talking about debug versus release - but also address the
different compilation model:
http://odetocode.com/Blogs/scott/arc...1/15/2464.aspx
2.) Why would you want an assembly for each page ?
There are applications, architectures, and some subset of software
developers who rely on the 'script like' ability of asp.net to
dynamically compile and update a page or control when a file changes.
In these scenarios they don't want the entire application to recompile
when a single aspx file changes. To support dynamic updates ASP.NET
still keeps this very granular compilation model, but does add
precompilation options.

http://odetocode.com/Articles/417.aspx

See all the web deployment project linked in the 1st url.

3.) Why can't you add a reference to a web project--is there some kind
of fundamental design issue or is this out of technical necessity ?
I don't think this type of design is anticipated by MS. The web
project is generally dependant on components in other assemblies and
not vice versa. The only reason I can think of to reference a web
assembly is to reuse a Page or Control - but again that is a scenario
where you can package a UI component into a class library for reuse.
4.) Why can't I put my web assembly(s) into the GAC and use strong
references in my page and control directives ?
I think this goes back to #3? A web project is just not typically a
repository for common code - class libraries are.
5.) Why is the fixed name and generate an assembly per page put
together in one option-- aren't they two different things ?

You could always generate an assembly per page without a fixed name.
My understanding of fixed names is that they exist more for patch
scenarios. You can isolate which files have changed and upload just
the new binaries. This would work well with precompilation in an
environment with a strong CM process.

--
Scott
http://www.OdeToCode.com/blogs/scott/

--
Scott
http://www.OdeToCode.com/blogs/scott/

[Bruce Barker]

few more thoughts:

1.) What is the logic behind special web folders that result in
separate assemblies ?
as the aspnet compiler does not use a project file, but rather the
directories themselves, it has simple logic for grouping seperate code files
into a common assembly. for example all files in app_code are compiled into
one assembly.
2.) Why would you want an assembly for each page ?
no change here, this has alway been true. in 1.1 and the codebehind model,
there was one assembly for the code behind, and 1 assembly for every aspx
page (these we produced in temp folders at runtime).

the design is so that a page can be added to a website or updated without
forcing the site to recycle (and lose inproc session, global variables,
cache, etc).

note: these is a setting to control how many page updates before a recycle
is forced.

5.) Why is the fixed name and generate an assembly per page put
together in one option-- aren't they two different things ?
this is a badly named option. when VS builds a web site, its really building
a staging folder that you can copy to the test or production web site. what
it is asking is, if you precompile the site, how you want to do updates.

if this box is not checked, the aspx file source is shipped, the compiled
codebehind assembly is given a random name (referenced by the source). this
allows a page and its code behind to be updated, because the new codebehind
assembly will have a different name. you send the new page and its
codebehind to the server. you want a new name for codebehind assembly to
control runtime deployment. you would not want the new aspx code to call the
old assembly, (say the page showed up before the codebehind assembly). in
this case a the compiler can batch aspx assemblies together, because its
done at runtime.

if this box is checked, the aspx page source is not shipped (a empty file is
created), and the aspx page and its codebehind produces a new assembly with
a fixed name. to update the page, you ship the new assemply (which contains
the aspx and codebehind compiled code). you don't want batching, because
then you don't get an assembly a page, and you would not know which assemply
a page ended up in.

note: the VS team will supply a utility to combine all assemblies into one,
to make deployment easier for sites that always replace all content
-- bruce (sqlwork.com)


"Scott Allen" <sc***@nospam.odetocode.com> wrote in message
news:o8********************************@4ax.com...I posted a reply in a previous thread, but I'll put it here, too, with
some additional resources.

1.) What is the logic behind special web folders that result in
separate assemblies ?

There have always been separate assemblies. In 1.1 when the asp.net
runtime parsed and compiled ASPX and ASCX markup, it produced multiple
assemblies in the temporary asp.net files directory. Visual Studio
compiled the rest (the code-behind).

The biggest difference in 2.0 is that the IDE doesn't do any
compilation - the ASP.NET platform does all the compilation.

This post is talking about debug versus release - but also address the
different compilation model:
http://odetocode.com/Blogs/scott/arc...1/15/2464.aspx

2.) Why would you want an assembly for each page ?

There are applications, architectures, and some subset of software
developers who rely on the 'script like' ability of asp.net to
dynamically compile and update a page or control when a file changes.
In these scenarios they don't want the entire application to recompile
when a single aspx file changes. To support dynamic updates ASP.NET
still keeps this very granular compilation model, but does add
precompilation options.

http://odetocode.com/Articles/417.aspx

See all the web deployment project linked in the 1st url.

3.) Why can't you add a reference to a web project--is there some kind
of fundamental design issue or is this out of technical necessity ?

I don't think this type of design is anticipated by MS. The web
project is generally dependant on components in other assemblies and
not vice versa. The only reason I can think of to reference a web
assembly is to reuse a Page or Control - but again that is a scenario
where you can package a UI component into a class library for reuse.

4.) Why can't I put my web assembly(s) into the GAC and use strong
references in my page and control directives ?

I think this goes back to #3? A web project is just not typically a
repository for common code - class libraries are.

5.) Why is the fixed name and generate an assembly per page put
together in one option-- aren't they two different things ?

You could always generate an assembly per page without a fixed name.
My understanding of fixed names is that they exist more for patch
scenarios. You can isolate which files have changed and upload just
the new binaries. This would work well with precompilation in an
environment with a strong CM process.

--
Scott
http://www.OdeToCode.com/blogs/scott/

--
Scott
http://www.OdeToCode.com/blogs/scott/