Does strong naming require deployment in GAC?

[Bruce Wood]

I still haven't gotten through the .NET Framework Security tome on my
desk. Maybe the folks here can answer a burning question.

I want to use strong naming at our organization as a security measure:
we could then indicate that any assemblies we signed are fully trusted,
and so deploy centrally rather than having to deploy on each server.

However, we still want to deploy by copying each app to a separate
deployment directory, rather than using the GAC. Can we do that? Or
does strong naming mean that we have to deploy to the GAC?

 

[tdavisjr]

Yes. Assemblies MUST be strong named

 

[KJ]

no

 

[Spidey]

Installing an assembly to the GAC requires that it be strong named.
However, every strong named assembly need not be installed to the GAC.
Hope that clears your doubt.

Regards,
Sarin.

 

[Bruce Wood]

Yes, that's what I wanted to know, thanks.

 

[Bruce Wood]

I know that in order to put an assembly into the GAC, it must be
strongly named.

What I was asking was whether a strongly named assembly must be put
into the GAC, or whether it can be put in a directory and loaded from
there.

Sarin answered my question.

 

[tdavisjr]

Ok. I misread your question.

 

[Mike Schilling]

I still haven't gotten through the .NET Framework Security tome on my
desk. Maybe the folks here can answer a burning question.

I want to use strong naming at our organization as a security measure:
we could then indicate that any assemblies we signed are fully trusted,
and so deploy centrally rather than having to deploy on each server.

However, we still want to deploy by copying each app to a separate
deployment directory, rather than using the GAC. Can we do that? Or
does strong naming mean that we have to deploy to the GAC?

We've seen very odd behavior from strong-named assemblies in virtual
directories, run from ASP.NET, that are not in the GAC. This is in .NET
1.1, on Windows XP. Some sort of non-thread-safe initialization seems to go
on, which leads to weird, unreprodcible failures (things like
NullReferenceExceptions in parts of the code that logically can't have null
references.) When we build the assemblies the same way but don't
strong-name them, the problems go away. It's very weird.

We've worked around it by building two sets of assemblies, strong-named ones
to be installed in the GAC for production builds, and non-strong-named ones
to be copied directly into virtual directories for developer builds.