By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,677 Members | 1,877 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,677 IT Pros & Developers. It's quick & easy.

Anybody use Strong Name Signing?

P: n/a
Anybody use Strong Name Signing? I think this is used by default for
Resource files, which is one reason perhaps I can't get my resource
files to work (somehow the public key is messed up, perhaps since I've
installed so many versions of Visual Studio)

RL

http://msdn.microsoft.com/en-us/library/h4fa028b.aspx

Deployment in Visual Studio
Strong-Name Signing for Managed Applications
Updated: November 2007

Strong-name signing, or strong-naming, gives a software component a
globally unique identity that cannot be spoofed by someone else.
Strong names are used to guarantee that component dependencies and
configuration statements map to exactly the correct component and
component version.

A strong name consists of the assembly's identity (simple text name,
version number, and culture information), plus a public key token and
a digital signature.

For Visual C# and Visual Basic projects, Visual Studio enables strong-
naming through the Signing pane in the Project Designer; see Signing
Page, Project Designer.

For Visual C++ projects, you use linker options to sign your assembly;
see Strong Name Assemblies (Assembly Signing).

Reasons to Use Strong-Naming
Strong-naming gives an application or component a unique identity that
other software can use to refer explicitly to it. For example, strong-
naming enables application authors and administrators to specify a
precise servicing version to be used for a shared component. This
enables different applications to specify different versions without
affecting other applications. In addition, you can use the strong name
of a component as security evidence to establish a trust relationship
between two components.

What Can Be Strong-Named
You can strong-name .NET Framework assemblies and XML manifests. These
include the following:

Application Assemblies (.exe)

Application Manifests (.exe.manifest)

Deployment Manifests (.application)

Shared Component Assemblies (.dll)

What Should Be Strong-Named
Shared DLLs should be strong-named. Regardless of whether a DLL will
be deployed to the Global Assembly Cache, a strong name is recommended
when the DLL is not a private implementation detail of the
application, but is a general service that can be used by more than
one application.

What Must Be Strong-Named
You must strong-name the following:

DLLs, if you want to deploy them to the global assembly cache (GAC).

ClickOnce application and deployment manifests. By default, the Visual
Studio project system enables this for ClickOnce-deployed
applications.

Primary interop assemblies, which are used for COM interoperability.
The TLBIMP utility enforces strong-naming when creating a primary
interop assembly from a COM type library.

What Should Not Be Strong-Named
In general, you should avoid strong-naming application EXE assemblies.
A strongly named application or component cannot reference a weak-
named component. Therefore, strong-naming an EXE prevents the EXE from
referencing weak-named DLLs that are deployed with the application.

For this reason, the Visual Studio project system does not strong-name
application EXEs. Instead, it strong-names the Application manifest,
which internally points to the weak-named application EXE.

In addition, you may want to avoid strong-naming components that are
private to your application. In this case, strong-naming can make it
more difficult to manage dependencies and add unnecessary overhead for
private components.

How to Assign a Strong Name
In Visual Studio, you strong-name an application or component by using
the Signing pane of the Project Designer. The Signing pane supports
two methods of strong-naming: using a strong-name key file, or using a
key provider. For information about signing manifests, see How to:
Sign Application and Deployment Manifests; for information about
creating strong-name key (.snk) files, see How to: Create a Public/
Private Key Pair.
Aug 24 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
JDeats wrote:
I'm not sure I understand your question, but I have to ask: have you
purchased a public/private key pair?
You are conflating strong naming with code signing. These are complementary
features. You can sign an assembly without giving it a strong name and vice
versa. In general, code signing gives you more guarantees than strong naming.
Keep in mind Assemblies signed with the the test public/private key pair
generated by makecert.exe will appear to be from an unknown publisher,
which defeats the purpose of strong name/signing.
No, it only defeats the purpose of signing. It's perfectly valid and
sensible to give an assembly a strong name without signing it: it allows you
to make sure that only you can produce versions of an assembly that will
work with existing code bases. Third-party tampering with the assembly will
prevent it from loading. It does not give you the strong guarantee that the
publisher is who they say they are that code signing gives you, though, only
that it's the same publisher as the one who originally supplied the
assembly. This is enough for many developers.

--
J.
Aug 24 '08 #2

P: n/a
On Aug 24, 12:44 pm, Jeroen Mostert <jmost...@xs4all.nlwrote:
JDeats wrote:
I'm not sure I understand your question, but I have to ask: have you
purchased a public/private key pair?

You are conflating strong naming with code signing. These are complementary
features. You can sign an assembly without giving it a strong name and vice
versa. In general, code signing gives you more guarantees than strong naming.
Keep in mind Assemblies signed with the the test public/private key pair
generated by makecert.exe will appear to be from an unknown publisher,
which defeats the purpose of strong name/signing.

No, it only defeats the purpose of signing. It's perfectly valid and
sensible to give an assembly a strong name without signing it: it allows you
to make sure that only you can produce versions of an assembly that will
work with existing code bases. Third-party tampering with the assembly will
prevent it from loading. It does not give you the strong guarantee that the
publisher is who they say they are that code signing gives you, though, only
that it's the same publisher as the one who originally supplied the
assembly. This is enough for many developers.

--
J.
Thanks for clearing this up and I apologize to the original poster for
any confusion.... I have never used strong naming without signing
(using a key from a CA) but the scenario you describe makes sense.
Aug 24 '08 #3

P: n/a
Just noticed the original poster mentions strong naming and code
signing in his thread topic.... I think we need more clarification on
what he's asking for.

Aug 24 '08 #4

P: n/a
Hi Ray,

You don't have to purchase any keys. You can use sn.exe to generate a key
pair.

Strong names are there to uniquely identify your assembly so that it can be
installed in several different versions and so that your applications or
users of your assemblies can use the right one.

Strong names do not apply to resources although you can strong name
satellite assemblies, is this what you want to do?

The key has nothing to do with visual studio. It seems as though your
understanding of what the keyfile does or how it is generated is erroneous.

--
--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
"raylopez99" <ra********@yahoo.comwrote in message
news:49**********************************@b1g2000h sg.googlegroups.com...
Anybody use Strong Name Signing? I think this is used by default for
Resource files, which is one reason perhaps I can't get my resource
files to work (somehow the public key is messed up, perhaps since I've
installed so many versions of Visual Studio)

RL

http://msdn.microsoft.com/en-us/library/h4fa028b.aspx

Deployment in Visual Studio
Strong-Name Signing for Managed Applications
Updated: November 2007

Strong-name signing, or strong-naming, gives a software component a
globally unique identity that cannot be spoofed by someone else.
Strong names are used to guarantee that component dependencies and
configuration statements map to exactly the correct component and
component version.

A strong name consists of the assembly's identity (simple text name,
version number, and culture information), plus a public key token and
a digital signature.

For Visual C# and Visual Basic projects, Visual Studio enables strong-
naming through the Signing pane in the Project Designer; see Signing
Page, Project Designer.

For Visual C++ projects, you use linker options to sign your assembly;
see Strong Name Assemblies (Assembly Signing).

Reasons to Use Strong-Naming
Strong-naming gives an application or component a unique identity that
other software can use to refer explicitly to it. For example, strong-
naming enables application authors and administrators to specify a
precise servicing version to be used for a shared component. This
enables different applications to specify different versions without
affecting other applications. In addition, you can use the strong name
of a component as security evidence to establish a trust relationship
between two components.

What Can Be Strong-Named
You can strong-name .NET Framework assemblies and XML manifests. These
include the following:

Application Assemblies (.exe)

Application Manifests (.exe.manifest)

Deployment Manifests (.application)

Shared Component Assemblies (.dll)

What Should Be Strong-Named
Shared DLLs should be strong-named. Regardless of whether a DLL will
be deployed to the Global Assembly Cache, a strong name is recommended
when the DLL is not a private implementation detail of the
application, but is a general service that can be used by more than
one application.

What Must Be Strong-Named
You must strong-name the following:

DLLs, if you want to deploy them to the global assembly cache (GAC).

ClickOnce application and deployment manifests. By default, the Visual
Studio project system enables this for ClickOnce-deployed
applications.

Primary interop assemblies, which are used for COM interoperability.
The TLBIMP utility enforces strong-naming when creating a primary
interop assembly from a COM type library.

What Should Not Be Strong-Named
In general, you should avoid strong-naming application EXE assemblies.
A strongly named application or component cannot reference a weak-
named component. Therefore, strong-naming an EXE prevents the EXE from
referencing weak-named DLLs that are deployed with the application.

For this reason, the Visual Studio project system does not strong-name
application EXEs. Instead, it strong-names the Application manifest,
which internally points to the weak-named application EXE.

In addition, you may want to avoid strong-naming components that are
private to your application. In this case, strong-naming can make it
more difficult to manage dependencies and add unnecessary overhead for
private components.

How to Assign a Strong Name
In Visual Studio, you strong-name an application or component by using
the Signing pane of the Project Designer. The Signing pane supports
two methods of strong-naming: using a strong-name key file, or using a
key provider. For information about signing manifests, see How to:
Sign Application and Deployment Manifests; for information about
creating strong-name key (.snk) files, see How to: Create a Public/
Private Key Pair.
Aug 24 '08 #5

P: n/a
In the previous thread/discussion did not sign the assembly when putting the
..wav file as an embedded resource.

"raylopez99" <ra********@yahoo.comwrote in message
news:49**********************************@b1g2000h sg.googlegroups.com...
Anybody use Strong Name Signing? I think this is used by default for
Resource files, which is one reason perhaps I can't get my resource
files to work (somehow the public key is messed up, perhaps since I've
installed so many versions of Visual Studio)

RL

http://msdn.microsoft.com/en-us/library/h4fa028b.aspx

Deployment in Visual Studio
Strong-Name Signing for Managed Applications
Updated: November 2007

Strong-name signing, or strong-naming, gives a software component a
globally unique identity that cannot be spoofed by someone else.
Strong names are used to guarantee that component dependencies and
configuration statements map to exactly the correct component and
component version.

A strong name consists of the assembly's identity (simple text name,
version number, and culture information), plus a public key token and
a digital signature.

For Visual C# and Visual Basic projects, Visual Studio enables strong-
naming through the Signing pane in the Project Designer; see Signing
Page, Project Designer.

For Visual C++ projects, you use linker options to sign your assembly;
see Strong Name Assemblies (Assembly Signing).

Reasons to Use Strong-Naming
Strong-naming gives an application or component a unique identity that
other software can use to refer explicitly to it. For example, strong-
naming enables application authors and administrators to specify a
precise servicing version to be used for a shared component. This
enables different applications to specify different versions without
affecting other applications. In addition, you can use the strong name
of a component as security evidence to establish a trust relationship
between two components.

What Can Be Strong-Named
You can strong-name .NET Framework assemblies and XML manifests. These
include the following:

Application Assemblies (.exe)

Application Manifests (.exe.manifest)

Deployment Manifests (.application)

Shared Component Assemblies (.dll)

What Should Be Strong-Named
Shared DLLs should be strong-named. Regardless of whether a DLL will
be deployed to the Global Assembly Cache, a strong name is recommended
when the DLL is not a private implementation detail of the
application, but is a general service that can be used by more than
one application.

What Must Be Strong-Named
You must strong-name the following:

DLLs, if you want to deploy them to the global assembly cache (GAC).

ClickOnce application and deployment manifests. By default, the Visual
Studio project system enables this for ClickOnce-deployed
applications.

Primary interop assemblies, which are used for COM interoperability.
The TLBIMP utility enforces strong-naming when creating a primary
interop assembly from a COM type library.

What Should Not Be Strong-Named
In general, you should avoid strong-naming application EXE assemblies.
A strongly named application or component cannot reference a weak-
named component. Therefore, strong-naming an EXE prevents the EXE from
referencing weak-named DLLs that are deployed with the application.

For this reason, the Visual Studio project system does not strong-name
application EXEs. Instead, it strong-names the Application manifest,
which internally points to the weak-named application EXE.

In addition, you may want to avoid strong-naming components that are
private to your application. In this case, strong-naming can make it
more difficult to manage dependencies and add unnecessary overhead for
private components.

How to Assign a Strong Name
In Visual Studio, you strong-name an application or component by using
the Signing pane of the Project Designer. The Signing pane supports
two methods of strong-naming: using a strong-name key file, or using a
key provider. For information about signing manifests, see How to:
Sign Application and Deployment Manifests; for information about
creating strong-name key (.snk) files, see How to: Create a Public/
Private Key Pair.
Aug 24 '08 #6

P: n/a
On Aug 24, 11:06*am, JDeats <Jeremy.De...@gmail.comwrote:
Just noticed the original poster mentions strong naming and code
signing in his thread topic.... I think we need more clarification on
what he's asking for.
Thanks JDeats and the rest of the respondents. I did not purchase
anything so it can't apply to me--the public key, private key node
entries I saw in XML type resource file (.resx) must be placeholders
for something (though I did see some strange hexdecimal values in
them, so maybe they are filled for wahtever reason with some key that
is activated when you pay CA or some party a fee).

In any event, as an aside, I've given up on making resource files
work, but am making steady progress just using non-embedded files in
lieu of embedded resource files.

RL
Aug 24 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.