and am currently trying to understand more about how the SS build process works, mainly as an exercise to get a better understanding of pcl requirements, strong naming and dotnet core stuff for my own evil needs.
I can sign assemblies and update their references using the following task so am wondering if all projects can reference the interfaces dll with a generated key (which the task below can do) but for your own builds the real key is passed in or picked up to ‘correctly’ sign the assemblies either from your local repo’s (excluded by .gitignore?) or by your CI server (TeamCity?)
any insights into the build sausage-factory would be appreciated.
All *.Signed projects are signed with our private signing key.
The only core .dll that is signed is ServiceStack.Interfaces.dll which we then check in at /lib/ServiceStack.Interfaces.dll and is what all projects reference. Likewise all Sub projects (e.g. Text/OrmLite/Redis) are stand-alone and reference all their .dlls from the repo’s /lib folder.
Basically you should ignore trying to build ServiceStack.Interfaces.dll, which you wont need to as all projects reference the built and signed .dll in /lib.
We dislike strong naming .dlls and don’t want to infect our core packages with them but some Customers still can only use Signed .dlls so we’re maintaining Strong named version of core ServiceStack packages in parallel using a .Signed suffix.
sorry, not questioning the rationale (or the dislike!) but more trying to understand the build process mechanics of it.
wondering if instead of maintaining two copies of the project file, could the project file be modified during the build and re-compiled to generate one unsigned and one signed dll, same applies for the nuspec copies too.
