still confused by @assembly directive

[Steve Richter]

When I build a C# class and install it in the GAC, my code works as it
should, my .aspx code finds the DLL and can run a static method:

<%@ Assembly Name="AutoCoder, Culture=neutral,
Version=1.0.1922.22245, PublicKeyToken=0a4067d718757385" %>
<%@ Import Namespace="AutoCoder" %>
Trace.Write( "AutoCoder", AutoCoder.Common.GetConnectionString( )) ;

But I cant locate the assembly in its directory using the src=
property.
- in IIS I map a virtual directory
- use the following @Assembly directive to reference the DLL:

<%@ Assembly src="\src#\AutoCoder\AutoCoder\bin\release\AutoCoder.dll"
%>

Parser Error Message: There is no build provider registered for the
extension '.dll'. You can register one in the
<compilation><buildProviders> section in machine.config or web.config.
Make sure the appliesTo attribute includes the value 'Web' or 'All'.

Why do I have to provide a build provider when using src= to reference
the assembly, but dont have to the assembly is founc in the GAC?

-Steve

 

[Brock Allen]

@Assembly with src is used to have ASP.NET compile an additional source file
for you. You specify a .cs or .vb file in there, not a DLL (since a DLL is
already compiled). If you already have a DLL, the only places it can be depolyed
is the GAC or in ~/bin. If it's in the ~/bin then it's automatically referenced.
If it's in the GAC< you need the <@Assembly Name="" %> directive.

 

[Steve Richter]

@Assembly with src is used to have ASP.NET compile an additional source file
for you. You specify a .cs or .vb file in there, not a DLL (since a DLL is
already compiled). If you already have a DLL, the only places it can be depolyed
is the GAC or in ~/bin. If it's in the ~/bin then it's automatically

referenced.

what is the ~/bin directory? There is none within /inetpub on my
system.

so is this statement crap?

"...One popular misconception is that strongly-named assemblies must
always be installed in the GAC. Strongly-named assemblies can be put in
the GAC, but by no-means have to be put there. It is desirable to put
strongly-named assemblies under the application directory if you want
to ensure your application has no system-wide impact, and make sure
that it can be XCOPY deployed. ..."

http://www.codeproject.com/dotnet/DemystifyGAC.asp?df=100&forumid=15829&exp=0&select=940022

thank you,

-Steve

 

[Juan T. Llibre]

Hi, Steve.

re:

what is the ~/bin directory?

The ~/bin directory is the /YourAppdirectory/bin directory.

The " ~ " is a shortcut for the root directory of any application.

re:

so is this statement crap?

You *can* place strongly-named assembies in the /bin
directory. That doesn't mean you *should* do that.

Read this :
http://blogs.msdn.com/junfeng/archive/2004/08/05/208375.aspx

It will make the concepts clearer.

Chris Brumme's blog entry at :
http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx
will give you additional background info.

 

[Brock Allen]

what is the ~/bin directory? There is none within /inetpub on my

system.

If you have DLLs you want to use from your application they can either be
installed into the GAC 9as you've seen) or they can be installed into a well-known
directory called "bin" which must be in the root of your application directory.
When I say application directory I mean the directory that's configured in
IIS as a virtual directory.

so is this statement crap?

"...One popular misconception is that strongly-named assemblies must
always be installed in the GAC. Strongly-named assemblies can be put
in the GAC, but by no-means have to be put there. It is desirable to
put strongly-named assemblies under the application directory if you
want to ensure your application has no system-wide impact, and make
sure that it can be XCOPY deployed. ..."

This is correct but it's not written fore the ASP.NET audience. When they
say application direcotry, normally that's your application's directory,
but ASP.NET disables this particular load location, and instead only ever
looks in the bin directory. So you can put strongly named assembles in the
~/bin. Anything in the ~/bin will automatically be referenced (IOW, visible)
from your code. If it's not in ~/bin then it must be in the GAC but you need
to let ASP.NET know you need it via <%@Assembly Name= %> directive.

 

[Steve Richter]

Hi, Steve.

re:

The ~/bin directory is the /YourAppdirectory/bin directory.

The " ~ " is a shortcut for the root directory of any application.

ok. so I am using Visual Web Developer to code my web pages and am not
using the "New Web Site" option. All my .aspx files are standalone
files, all in the same directory, all are compiled by IIS when the page
is first referenced. In this scenario, I dont have a /bin directory,
right?

re:

You *can* place strongly-named assembies in the /bin
directory. That doesn't mean you *should* do that.

Read this :
http://blogs.msdn.com/junfeng/archive/2004/08/05/208375.aspx

It will make the concepts clearer.

Chris Brumme's blog entry at :
http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx
will give you additional background info.

note to Microsoft and the MVP people: I am a typical idiot who is
capable of getting a web page to work. What you all think is clear is
not very clear to me. ( I am not complaining, and I appreciate the high
quality answers I am getting to my questions. This is just feedback
from a beginner that maybe asp.net is being made more complicated than
it has to be. )

Just curious. Are the appdomain and shared assemblies concepts that
apply to high volume web server environments? The idea being that if
the separate processes and threads the web server runs to service all
the browser posts can be made to share the static objects in the
assemblies then overall performance will be improved?

thanks for all the help,

-Steve

 

[Brock Allen]

ok. so I am using Visual Web Developer to code my web pages and am

not using the "New Web Site" option. All my .aspx files are standalone
files, all in the same directory, all are compiled by IIS when the
page is first referenced. In this scenario, I dont have a /bin
directory, right?

So sounds like you're using ASP.NET 2.0. It's optional to have a ~/bin. If
you have assemblies (DLLs) that you'd like to use then you can have a bin.
If you don't have any other DLLs then you don't have a ~/bin. BTW, VS.NET
adds the ~/bin when you select "Add Reference" for your project (unless it's
a GAC assembly though, since that's already deployed in the GAC).

note to Microsoft and the MVP people: I am a typical idiot who is
capable of getting a web page to work. What you all think is clear is
not very clear to me. ( I am not complaining, and I appreciate the
high quality answers I am getting to my questions. This is just
feedback from a beginner that maybe asp.net is being made more
complicated than it has to be. )

Well, I'm not a MVP, but I'd say it's not a problem -- that's the point of
these newsgroups. Ask questions. All of the questions you've asked have been
compelling questions that we've all had while learning this stuff. So, no
it's not a problem.

Just curious. Are the appdomain and shared assemblies concepts that
apply to high volume web server environments? The idea being that if
the separate processes and threads the web server runs to service all
the browser posts can be made to share the static objects in the
assemblies then overall performance will be improved?

AppDomains are like processes and in the context of ASP.NET they're used
to isolate applications and application's data from one another. You get
a distinct copy of all static variables per AppDomain, so that each ASP.NET
application is isolated and thus won't inadvenently affect another. Assemblies
are also loaded per-AppDomain so just because you have an assembly loaded
in your web app doesn't mean I can see it or use it from my web app. So,
at the end of the day AppDomains serve the same role as processes in Win32
-- it's an isolation boundary.

Now, you might ask why we have them at all? Win32 processes already do this
for us. Well, AppDomains are much lighter weight that Win32 processes. Releatively
speaking Win32 processes are very expensive, so a web server with 100 distinct
processes, one for each application is usually unnecessary and wasteful.
AppDomains serve to mitigate this.

thanks for all the help,

np

 

[Brock Allen]

So sounds like you're using ASP.NET 2.0. It's optional to have a

~/bin. If you have assemblies (DLLs) that you'd like to use then you
can have a bin.

Oops, another sloppy post. Juan's gonna have a field day with me

These two statements:

So sounds like you're using ASP.NET 2.0.
and

It's optional to have a ~/bin. If you have assemblies (DLLs) that
you'd like to use then you can have a bin.

Are unrelated. I was just making an observation with the first one (re: 2.0).
Just for the record