VS 2005: multiple dll's for one website possible?

[Steven Spits]

Hi,

Because we have a large WebApp, back in 2002 we decided to use the following
method:

http://support.microsoft.com/default.aspx?scid=kb;en-us;307467

In short:

Create a project "a" at http//localhost/MyWebApp
Create a project "b" at http//localhost/MyWebApp/Part1
Create a project "c" at http//localhost/MyWebApp/Part2

In IIS, remove applications for project "b" and "c" and add references to
project "b" and "c" from project "a". Works like a charm!

This method has serveral advantages: your solution only contains the
projects you're working on (quickly compiled) and we get a seperate DLL for
each project (easy deployment).

But in VS 2005 the concept of projects doesn't exist anymore for websites.
If I convert & open project "a"', it also contains project "b" and "c".

Is there still a way to compile our website to multiple DLL's?

Steven

- - -

 

[Juan T. Llibre]

See the : VS 2005 "Web Deployment Projects" wdproj lacks macros? thread.

 

[DBxGlock]

It sounds like you're trying to do the very thing we're doing.
Essentially, each aspx page has its own dll (or even multiple dlls).
This means that each page had its own solution and project (and
possibly sub-projects like you described for other dlls specific to
that page). You need a beta VS 2005 add-in called "Web Deployment
Projects". You can get it here:

http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx

Make sure you read the "Using Web Deployment Projects with Visual
Studio 2005" document and it will walk you through doing exactly what
you want to do. Basically, you'll now have the option to combine your
App_Code.dll and your App_Web<mangled>.dll into a single assembly and
you get to choose the name.

It also gives you other options, such as compiling a different assembly
for each page, etc.

Dan

 

[Steven Spits]

You need a beta VS 2005 add-in called "Web Deployment
Projects". You can get it here:

Thank you for your mail! I will look into it...!

Steven

- - -

 

[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]

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.

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 the page or
control 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 has a very granular compilation model.

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.

 

[john]

Scott,

All valid points.

My only sticking point is the thought that external assemblies can't
and shouldn't reference and web project assemblies.

Let me give you some concrete examples we can debate.

Our 1.1 web project has a configuration and a session class that
provide clean and consistent access to information stored in the
web.config and session state. From a design perspective, that
information is owned by the web application and the web application is
responsible for maintaining it; therefore, the classes are located in
the appropriate component. We have an external class library that
contains custom controls used on pages in the web application. If one
of those controls needs to retrieve a value from session or
configuration, it calls the classes in the web app. In order to
migrate to 2.0, we have to move those classes into separate assemblies.
It seems like a clean design to me.

Here is another example where the web app can't reference itself
properly. Our 1.1 web project has custom controls. The pages in the
web app have register tag prefix directives that use a strong
reference. The controls are only used by the web project; therefore,
they don't belong in a separate component. In 2.0 the controls end up
in App_code.dll and you can't specify the version or control the
assembly name. It seems that the only solution is to move the controls
to a shared assembly, or keep them in the web app and remove the strong
reference.

Thoughts?

John Powell

 

[Scott Allen]

Scott,

All valid points.

My only sticking point is the thought that external assemblies can't
and shouldn't reference and web project assemblies.

Yes, I agree.

Let me give you some concrete examples we can debate.

Our 1.1 web project has a configuration and a session class that
provide clean and consistent access to information stored in the
web.config and session state. From a design perspective, that
information is owned by the web application and the web application is
responsible for maintaining it; therefore, the classes are located in
the appropriate component. We have an external class library that
contains custom controls used on pages in the web application. If one
of those controls needs to retrieve a value from session or
configuration, it calls the classes in the web app. In order to
migrate to 2.0, we have to move those classes into separate assemblies.
It seems like a clean design to me.

I think I get what you are saying.

I generally approach these types of problems with a factory type
design pattern and interfaces.

Define an interface (lets call it ISessionManager) in a class Library
(lets call it sessionmanager.dll). The interface could well be an
abstract base class, too.

Next I'd build a custom control library that references
sessionmanger.dll and program against the ISessionManager interface.
That's all the controls need to know - that someone will provide an
ISessionManager as a paramter. No references to the web app are
needed.

The web app references sessionmanager.dll, and the custom control
library - it can use components from either assembly. The web
application derives from a class from ISessionManager and provides a
concrete implementation of that ISessionManager contract. For example,
if ISessionManager has a property called UserName, then the web app
implements that property by retrieving a string from the Session
object (or the database, or ViewState) - the important part if that
the details are hidden from anyone who uses an ISessionManager object.

When the web app needs an object from the custom control library to
perform some action that requires an ISessionManager, it passes along
it's session manager object. The custom control library doesn't need
to reference the web app, or know the exact type that the web app is
using to manage session information - it only needs to know that the
object is an ISessionManager.

Here is another example where the web app can't reference itself
properly. Our 1.1 web project has custom controls. The pages in the
web app have register tag prefix directives that use a strong
reference. The controls are only used by the web project; therefore,
they don't belong in a separate component. In 2.0 the controls end up
in App_code.dll and you can't specify the version or control the
assembly name. It seems that the only solution is to move the controls
to a shared assembly, or keep them in the web app and remove the strong
reference.

1) Versioning and naming an assembly in ASP.NET 2.0

You should be able to do this with a wed deployment project. It
doesn't change what happens at compile time - but the end result can
be a strongly named assembly with an AssemblyVersion attribute
applied.

2) Maybe I'm missing something obvious, if so I plead ignorance

I'm guessing you have a custom control in AppCode derived from
WebControl or Control?

Doesn't the following work (where pcc is your concention and Foo is
your namespace - App_Code is consistently App_Code.dll).

<%@ Register TagPrefix="pcc" Assembly="App_Code" Namespace="Foo" %>

 

[john]

In regards to versioning...

If I use the web deployment project to create a strongly named
assembly, how would a page like this work at design time:

Page
Inherits="MyCompany.MyTechnology.MyCodeBehind,MyCompany.MyTechnology,Version=1.0.0.0,Culture=Neutral,PublicKeyToken=45234KDF"

 

[Scott Allen]

Honestly, John, I'm not sure. It's something I'll have to experiment
with.

 

[john]

Thanks if you can help.