Good morning, I wanted to at least throw in on this conversation as I've been working with .Net and security for almost 7 years at this point. Yes, since the early Beta. A signed assembly is only a requirement for placing an assembly in the Global Assembly Cache, not the other way around. People who are interested in this process should look up the .Net Assembly Discovery Process to see how .Net looks for assemblies at run time. The first place it does check is the GAC. So if you have a signed assembly there that's what will get run, after that it does check your run time directory of the executable.
I would highly recommend signing your assemblies though; it is really considered a basic step in securing your .Net application. This in conjunction with security link demands when calling between assemblies is the only way to prevent attacks such as Man in the Middle and Assembly replacement. Just my two cents. Jonathan L. Wiggs Software Engineering Manager Envision Telephony Inc. ________________________ Office: 206.225.0800, ext. 236 Cell: 206.387.7860 [EMAIL PROTECTED] www.envisioninc.com -----Original Message----- From: GlennDoten [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 7:20 AM To: Log4NET Dev Subject: Re: Strong name private key policy 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=/De sign/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 >
