Finding the public key and public key token of an assembly for use with InternalsVisibleTo

It seems like one of the most common problems out there when it comes to testing and dealing with strongly-named assemblies is getting the public key and the public key token of a CLR assembly when you want to create test projects for that assembly. The quick and easy way: 1. Ensure that 'sn.exe' is in your path. If it's not, it's usually in the Windows SDK directory, typically in a folder like : C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\sn.exe 2. Open up a command window, and navigate to the directory containing the snk you're signing your assemblies with. 3. sn -p my.snk Public.snk 4. sn -tp Public.snk ...and voila, the program will print out the public key and public key token to the screen for you. The reminder I found this at was here. After you've found the public key, you'll want to paste a line similar to the following in the AssemblyInfo.cs file of the project whose internals you wish to expose:

[assembly: InternalsVisibleTo("MyCompany.ProjectName.Tests,
PublicKey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX")]

Changing the default URI of a WCF web service

I recently returned to one of my previous employers since they lured me away with a better employment offer than I was currently receiving. I'm now placed on a large scale project to revamp our equipment and our software, and improve our software services to the point where we have absolute control and communication with our software out in the field. To that end, I'm presently writing a service that our field personnel's laptops will use to communicate with our home office. I've decided to implement the service in WCF since I've got experience with it and it will be the quickest route to getting a working service deployed. There are other reasons for the choice, but we won't go into those at the moment. One of the things I had forgotten about was the best practice of changing the default namespace of the service away from tempuri.org. I found an article here to remind me of how to do it, so hopefully others will be able to find it as well.