In this post I would like to briefly describe the topic of software licensing and present few solutions I found on the internet. Licensing topic is highly connected with application security and piracyproof so to speak. We generally provide licensing mechanism when we want to assure that nobody who did not paid for the application can not access this application. We want to protect our intellectual property and give the access to the application only those people who paid us for that.
Signing is a bit more tricky than strong naming. I didn’t want to use delay signing, because that requires additional configuration on development stations, so just like with strong naming – plain old simple build on the development machine and the fancy stuff on the build server.
This is another bit that will be helpful with our next tfs build script modification.
To use a certificate for either strong naming or signing code, you need to place it in the certificate store of the user asking for it (e.g. if you’re executing an automated build, the user in whose context the build is executed)
But there are also ways to create a csr without installing any software. There's the easy way (for those who have IIS installed) and the bit more complicated way (for those who like command line tools – that would be me)
Information like product name, file version, copyright, etc are stored in the assembly manifest. In this post I would like to present how these informations can be read from an assembly and showed in the UI.
Recently I needed to write a simple database application. I chose the Entity Framework Code First (Code Only) as a Object Relational Mapper (ORM) because its simplicity and quick development process. If you did not yet heard about EF Code First then this is a good place to start. Entity framework is a very powerful technology. It totally makes the whole dirty work which in the …
Today we’re going to look at another build script adjustment – strong naming assemblies.
The scenario we are aiming for is that during development, the assemblies are not signed (so developers don’t need to have the a certificate file - a little bit more on that later), but during a build on the build server they are. This can be handled by providing additional parameters to msbuild.
The assembly version is a number in the form of <Major>.<Minor>.<Build>.<Revision>. What value the placeholders are assigned to is totally up to you, we chose to set the first three numbers manually and set the last one to the change set that the source was built from. At the same time, I didn’t want to limit the options, so by examining the “Build Number Format” input in the default template, I decided to merge the parameters available there with a custom parameter set (the build number format provides a couple of params, but doesn’t provide access to the change set number).