If you need to be more specific about what to sign you can call the console version in your Visual Studio project files to sign assemblies before it gets built.

For example, if you want to strong-name sign and fix references to all the NuGet packages that your project uses, you can add this to you Visual Studio project file:

If you are making use of the NuGet package, you can make the call from the packages directory like this instead (replace with you own packages path):

You can also provide specify a value for the $(StrongNameSignerDirectory) variable to avoid having to update your project files when a new version is released.

Often different packages have dependencies that are not signed, but those assemblies are in different directories. To correctly resolve references to dependent assemblies, all required assemblies and the dependencies they reference need to be processed at the same time. Elmah is a good example of this. Additional Elmah libraries reference Elmah core, but do not include it in the package, they are installed separately. In order to fix the references to Elmah core, it needs to be able to cross check all signed files so you should sign all of them together.

To add multiple directories to process at the same time (similar to how the UI can process a number of assemblies at once in the grid) just pipe | delimit your input directory list.

This way the core library can be signed and the MVC library can have it's reference to the new signed version updated since they will be processed together and each file can be verified against each other after signing. As a rule of thumb, always include all libraries that will be affected by any signing in a single call.

You can also use wildcards for each of your input directories. The above example could also be written using a wildcard that will match all directories and versions.

Wildcards can also be complex and placed anywhere in the path. This is useful if you only want a subset of directories as well as only certain framework specific lib directories to be signed.

Note that any files that are already strong-name signed will not be modified unless they reference a previously unsigned assembly. If you are using NuGet package restore then this works on build servers as well.

Another alternative is to simply call the StrongNameSigner.Console.exe with relevant argument as a pre-build step.

"C:\Program Files\BrutalDev\.NET Assembly Strong-Name Signer\StrongNameSigner.Console.exe" -in "..\packages"

Dealing With Dependencies

To avoid a complicated explanation on how this works, just include ALL assemblies that reference each other whether they are signed or not. As of version 1.4.8, all included file paths are probed for references so they can be fixed without having to copy them into the signed assembly directory.

When dependent assemblies cannot be found and references weren't fixed correctly, the following type of error will occur during a build.

For example, ServiceStack's PostgreSQL NuGet package is not signed but other dependent assemblies are. Furthermore, these dependent assembly versions don't match what is referenced in ServiceStack.OrmLite.PostgreSQL. To correct the reference versions as well as ensuring the correct signed assemblies are referenced, simply include all the files that need to be processed in a single command to the strong-name signer.

Even though ServiceStack.OrmLite.PostgreSQL.dll references the unsigned ServiceStack.Text v4.0.39 and the unsigned ServiceStack.OrmLite.Signed v4.0.40, using the command above will force it to use the included signed versions as references as well as correcting the reference versions to match.

Another very clean approach from Vitaly Chipounov is to use GeneratePathProperty so you can reference the packages easily in a target and inject the paths into the console command.

API Usage

Reference Brutal.Dev.StrongNameSigner.dll in your project or include it in a PowerShell script.

Build

To build the project you need to have the following third party software installed.

• Sandcastle Help File Builder (to build API documentation in Release mode)
• Inno Setup (to compile the installer)

License

Copyright (c) Werner van Deventer (werner@brutaldev.com). All rights reserved.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.