R
raylopez99
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.
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.