I'm looking for some "policy guidance" on when I should strong name assemblies.

All of my NET libraries are intended to be private assemblies, not installed in the GAC. I've read in various places that even in
that situation using strong names can be "useful" because doing so "ensures" the assembly is coming, unchanged, from the party that
authored it.

However, in experimenting with strong naming private assemblies, I've run across a lot of little gotchas consuming the assemblies
which make me wonder if the purported benefits of strong naming are worth the costs.

I'd be interested in other developers' views on this subject, or links to articles on the topic (I didn't find anything relevant
when I searched on MSDN).

- Mark

What gotchas are you referring to ?

Regards,

Cerebrus.

<zorg***@sify.com>

Hi Mark,

As for strong-named assemblies, the main benefit is still the security,
strong-name provide an identifier for the assembly. And when the
strong-named assembly is referenced by another assembly, that assembly
contains the public key token info of the strong-named one, this can help
make sure the referenced assembly is the correct one and hasn't been
corrupted. this resolve the DLL HELL issue in WIN32 world. Also, when
applied strong-name, we can put our assembly into GAC to make them as
shared component that can serve at machine scope. 

However, as you mentioned, there does has some cases strong-named assembly
will make work harder. e.g, for globalizable/lobalizable application, after
we create the main assembly(strong-named) and some culture specific
satellite assembies. If someone else(maybe vendor or end user) want to
create some additional locallized culture specific satellite resource
assembly, they must have the key pair of the strong-name which is not
possible in most cases. 

Also, for ASP.NET application, there is an existing limitation that
strong-named assemblies used in ASP.NET application must be installed into
GAC, not supported in private bin dir.

In addition, when use strong-named, we can configure some .NET Code Access
rules in policy file or code according to the strong-name identity.

So I think you can consider whether to use strong-name from the above
factors. Generally, for client-side desktop application, whether to use
strong-named assembly or not is not quite critical.

Hope this helps a little.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks Steven, it helps quite a bit.

- Mark

My pleasure :).

Good luck!

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

Steven Cheng[MSFT] wrote:
Excuse me?  I've been using strong-named assemblies in the bin directory of
an ASP.NET site for 3 years with no problems.  What exactly is not
supported?

-cd

Thank you for your inputs Carl,

Yes, the problem is not always occuring and depend on the decent
environment. e.g when there is indexing service running or any other
anti-virus software that may also access temporary assemblies periodly. And
strong-named assembly doesn't quite utlize the shadow-copy ASP.NET use for
release private assemlies in bin dir. This is a potential problem. And
there does exists some kb article mentioned this:

http://support.microsoft.com/kb/813833/en-us

http://support.microsoft.com/kb/813830/en-us

Thanks,

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

I don't recall them all that well. I just remember having to add a bunch of code and restructure a number of patterns that I
frequently use to create Types and instances of classes in order to get them to work.

- Mark

FW 1.1 problem
.NET Frame work 1.1 install problem
compare byte[]
Monitor.Wait problem
BUG: Strongly-typed DataTable GetSchemaSerializable method