While this isn’t exclusive to BizTalk assemblies, I can’t say I’ve had much need for strongly named assemblies prior to working with BizTalk. When a BizTalk assembly is deployed, the assemblies are installed into the GAC. For an assembly to be installed into the GAC, however, the assembly must be strongly named. It’s easy enough to create a .snk file and open up the project properties and browse to the location of the .snk file, though it’s a recommended practice to specify the assembly key file with a relative path rather than using an absolute path. This practice can help reduce any frustrations on a project with multiple developers who may have varying preferences for source code location, etc. There’s another way to share assembly keys among assemblies that might prove useful at some point.
Using the sn.exe to create assembly keys, I’d imagine most are reasonably familiar with the –k option. One of the other options is –i which will install the specified key into a container.
When modifying the project properties to specify an assembly key, you can specify this key container rather than pointing to the assembly key file.
I’ve found this approach useful when there are multiple projects within one solution that share one assembly key – for instance, one BizTalk solution that had different projects for schemas, orchestrations, utilities, etc. Using relative paths you could store the assembly key file in the solution folder and use relative paths, or you could install the assembly key into a container and specify the name of the container.