Hi Tom. I work at PC Connection and we've been using signed assemblies
with .NET 1.1 for two years now, and they are in the bin directory and
not GACed. They don't need to be GACed. Keep in mind that an signed
assembly is no different than a non-signed assembly except, of course,
it has a public/private key pair embedded in it. But this has no
effect whatsoever on whether the assembly is run from a bin directory
(whether ASPX or not) or whether it is run from the GAC.
From that blog entry:
As you probably already know every asp.net application lives in its own
application
domain (a unit of isolation inside an application)
To be precise, it should be a "unit of isolation inside a process."
This is true for all assemblies that are not strong named. For example, you
wouldn't
want System.Web.dll loaded up into each application domain as it would mean that
System.Web.dll would be loaded once for each application, bad bad bad!!! So
strong
named assemblies, irrespectively of where they are loaded from are loaded into a
shared domain (they are domain neutral).
This paragraph really doesn't make sense. The reloading of signed
assemblies in the bin directory (so long as they are not in the GAC
also) occurs just the same as it does with non-signed assemblies. Try
it. We've been doing this exact thing for a long time.
Then she mixes a GACed assembly (System.Web.dll) with other assemblies
that are signed but not in the GAC. Bad, bad, bad! This is comparing
apples and oranges. And signed assemblies are most definitely *not*
loaded into a shared address space (and I don't know what "shared
domain" and "domain neutral" means here--GACed assemblies are in
memory only once, not per app domain or anything like that).
For these reasons it is not supported to store strong named assemblies in the
bin
directories of ASP.NET applications in 1.1.
That's just plain wrong. It works fine in not only 1.1 but 1.0 also. And in 2.0.
A Chris who replied to her blog points to this article:
http://www.gotdotnet.com/team/fxcop/docs/rules.aspx?version=1.32&url=/Design/AssembliesShouldHaveValidStrongNames.html
This is exactly why you want to sign assemblies. The primary reason is
not so that they can be GACed (although that is certainly necessary at
times) but so that the assemblies can be trusted by a client. Not only
do signed assemblies work just fine without any of the supposed
problems this blogger points out they also work just fine in the bin
directory of a console app and/or a Windows Forms app. Been doing both
since .NET 1.0 with no problems at all. I also know a lot of web site
developers that also keep their signed assemblies in the ASPX bin
directory.
So I have years of empirical evidence refuting how signed assemblies
work. Jeffrey Richter's books are extremely good at describing how all
this works and it's even supported.
Hope this information proves useful.
-glenn-
On 6/22/06, Whitner, Tom <[EMAIL PROTECTED]> wrote:
Glenn,
Please refer to the following articles -
http://support.microsoft.com/?kbid=324519
http://support.microsoft.com/default.aspx?scid=kb;en-us;813833
http://blogs.msdn.com/tess/archive/2006/04/13/575361.aspx
These all indicate that running ASP.NET applications with strong
named assemblies deployed to the bin folder is not supported in .NET 1.1
or 2.0 as well as some of the symptoms might be experienced.
Thanks,
Tom
-----Original Message-----
From: GlennDoten [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 2006 10:19 PM
To: Log4NET Dev
Subject: Re: Strong name private key policy
Not true, Tom. Just because an assembly is signed does not mean it
must be in the GAC to be used by ASPX. We run non-GACed, signed
assemblies with ASPX in production all the time.
FYI
On 6/21/06, Whitner, Tom <[EMAIL PROTECTED]> wrote:
> We are facing a similar question with some internal code. We have
> decided, at least for now, to produce both strong named and non-strong
> named binaries. Most agree that the strong named option is preferred.
> However, due to ASP.NET'sbehavior when loading strong named assemblies
> (i.e. it requires the GAC), not all individuals can/will tolerate GAC
> installation on highly locked down server. Hence, having the
non-strong
> versions has become a necessity.
>
> - Tom
