The Sherpa Project

Here are the steps that you need to go through to get a WCF service hosted in IIS7. I’ve had to track down this information a few different times, so I thought it was worth posting. The documentation for all of this exists, it’s just scattered and you can find multiple sets of instructions for hosting .svc files due to the changes in the earlier builds of Vista.

The first thing you need to do is install IIS7. To do this, go to Control Panel > Programs > “Turn Windows features on or off”

Select “Internet Information Services” and then drill down and make sure that ASP.Net is checked.

The next thing you need to do is install the other bits and pieces that WCF need to have to run in IIS. You can do this by running the command prompt (be sure to run as Administrator) and run ServiceModelReg.exe -i.

Now you should be good to go.

1. Open Word Document
2. Ctrl+A, Del
3. Type “See: http://msdn2.microsoft.com/en-us/library/ms229002.aspx”
4. Ctrl+S

If you have a chance to make it to Nashville this Friday, you should check out devLink. Attendance is free and there is a great lineup of speakers that are set to be presenting. I’ll be up in Nashville on Thursday night and will be around all day on Friday for the conference.

The last I heard, registration is still open and there are already a ton of individuals that have registered to attend.

I don’t have the exact details yet, but I’ll be doing two chalk talks during the event. I’m looking forward to the event and I’m excited to see that the conference is covering some great topics and has the support of so many individuals.

I’ll post more details about my talks later this week as the details are ironed out.

I look foward to seeing everyone there.

If you haven’t seen this yet, the VSTSPlugins project allows using Team Foundation Server with CCNet. You can find the documentation on the CCNet Confluence site and the VSTSPlugins project on SourceForge.

If you have publicly-facing web services, it's likely that you don't want to expose the inner workings of your application to the consumers of the application. In the application that I'm currently working on, there are times we want return a generic "An unexpected exception has occurred." message and times that we want to return the actual exception to the client (for validation / policy-related exceptions). In both of these scenarios, we do not want to return the stack trace that indicates where the exception occurred.

There are many ways to implement this functionality, but the good news is that this is the provided behavior (by default) of a .Net web services project. The bad news is that it's probably not immediately obvious that this behavior is occurring because it is only the default behavior if the request is coming from another machine. If you consume the service from a client on the same machine (more than likely, this is the case when you are testing) then the stacktrace will be visible.

The secret to controlling this behavior is the customErrors tag (and the mode attribute) in your web.config file. A customErrors tag with mode="On" will remove the stacktrace from the soap fault (even on the local machine), a tag with mode="Off" will add the stacktrace to the soap fault (even for remote clients), and a value of mode="RemoteOnly" will add the stacktrace for local requests and remove it for remote clients (this is the default).

It was a big surprise to me that this tag controlled the stacktrace of web services. This is a common configuration tag, but I had never seen it used with web services.

The code to remove the stack trace (for both local and remote clients) is:

1:  <configuration>

2:    <system.web>

3:      <customErrors mode="On" />

4:    </system.web>

5:  </configuration>

For more information on working with soap faults, take a look at the Using Soap Faults article on MSDN.

You can find it here.

A while back, I was looking for an answer to a Javascript question and I ended up finding the answer in this Javascript reference. More important than finding the answer to my question, I was intrigued by how clear the reference was with minimal text and the fact that the reference was put together as a list of assertions. It came down to the code being self-documenting and being very easy to understand.

Ever since I saw the Visibone references (all of which are very good), I have tried to learn new languages taking a test-driven approach to learning the legend. Usually, the first thing I learn about is a test runner that I can use for the language and then I play with the language by using the test runner and creating a bunch of tests. Everything is self-documenting and I can go back and tweak examples when I want to expand on my knowledge or find out how certain scenarios work. Best of all, I have a record of my learning and when I switch versions of the language or library, I can simply run my tests to see if anything I know has changed since the last time I used the language or library.

I recently started playing with the prototype library, and this approach has been a great asset. I can learn a little at a time and review my progress at any time. The prototype library is a Javascript library and I started out by using the script.aculo.us unit testing library (which is built on top of prototype).

My approach was to create a new .Net website, create a master page with all of the javascript references, and then adding new content placeholders for each logical area that I'm learning about.

My test page looks like this…

…and the tests look something like this…

This has been a great way to learn prototype and I think I'm probably going to do this more and more moving forward. Just about every language seems to have a unit testing framework and I like the idea of having code that I can go back and execute.

Jim Holmes has put together a list of ReSharper shortcuts for the current 2.0 EAP build.

The EAP isn't quite ready for primetime yet, but it's getting a lot closer. 

Thank you Jim!

The March 21st edition of .Net Rocks was my favorite show so far. The topic was Test Driven Development with Jean Paul Boodhoo and the show was very good. Jean Paul Boodhoo provided some great insights into TDD, Mock objects, and agile approaches to software development. 

Whether you're a devoted TDD advocate or not, the show is worth checking out. I can also recommend checkingout Jean-Paul Boodhoo's blog.

I’ve been playing more and more with Ruby On Rails lately and it has been a very mind-opening experience with regards to many of my ideas around application architecture. There are many wonderful things about Rails, but the idea (and implemenations) of “convention over configuration” is demonstrated beautifully within Rails.

My development experience has been primarily centered around .Net since the early betas of .Net 1.0. I’ve completed dozens of production systems with .Net and there are many ideas and thought processes that repeat themselves over and over throughout each project. In some of my earlier projects, I played with the idea of convention and decided that there was too much “magic” in many of the convention-based implementations that I participated in. After a few different attempts, I finally gave up on convention and fell back to the typical .Net configuration as the norm for my projects.

I have to say that Ruby On Rails has completely changed my views on the power of convention. From my (limited) experience with Rails, I would have to say that the conventions that are built into Rails provide provide a ton of acceleration in producing working web applications. I love the idea that almost everything is based on convention.

The way Rails encourages convention provides for rapid development, prototyping, and results in cheaper applications. Convention is encouraged throughout Rails by assuming that you are following convention (plural table names, primary keys named id, urls indicating actions, etc.) while still allowing the flexibility to deviate from the conventions when necessary.

I’m still not sure that one-off conventions are extremely valuable in .Net because they would not be standard conventions and would likely widely differ between projects and across companies. I think that the potential is there, but some type of framework would need to be established to (at least partially) encourge common conventions across projects. As an idea, convention is a very powerful concept, especially when it’s built into a framework (or an acceleration platform). I’m hoping that something is on the horizon that will provide this concept to .Net and that it gains traction soon. I would love to be able to write .Net applications at the speed that I can implement Rails applications.