Building servicestack

I’ve been following the thread

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. :+1:

1 Like

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.

ok thanks, follow up and sorry if this is a noob question but…

why *.Signed projects, is it just a convenience to reference the dll’s with PublicKeyToken or output dll name?

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.

We only maintain the main .csproj, the .Signed and .PCL projects are generated by running /build/codegen-projs.js.

We need them locally as we sometimes need to debug them. After VS supports wildcards we wont need to run the code gen script anymore.