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.

Previews with a DataContext in WPF

Both the company I currently work for and the previous company I worked for use WPF extensively in some of their products. I recently ran across an incredibly helpful bit of functionality that aids in designing controls and forms on this blog. The TL;DR is that it lets you specify the data context that's supposed to be associated with a window / control, and lets you preview the control at design time using design data. This is useful because it lets you get an idea of what the control is going to look like with real data, and can be especially helpful when trying to size controls on a form, or seeing what lists are going to look like, and will be a real time saver because it means you no longer have to compile and start the application in order to view styles on things like DataTemplates.