What I need is something hosted through IIS and is RESTFul for simplicity.

Three things you need.

• 1. Any web application.
• 2. WebGetAttribute found in System.ServiceModel.Web.
• Used as follows
  [OperationContract]
[WebGet(UriTemplate="*")]
string CheckStatus();
• So basically in the case where you simply access http://…/Service.svc, it would access CheckStatus()
• Using the WebInvoke method you can access post requests as well.
• UriTemplate is also very important as that allows you do define more descriptive routes or requests.
• Consider the following piece code.[WebGet(UriTemplate="/User/{userName}")]
string GetUserInfo(string userName)
• Now accessing the following resource http://…/Service.svc/User/Evan will route to GetUserInfo passing in “Evan” as userName
• Now so assuming that you can just have httpWebBinding and its hosted through IIS you can skip the web.config changes access the markup in Service.svc and add the attribute Factory=”System.ServiceModel.Activation.WebServiceHostFactory” into node in there. (Note .NET 3.5 intellisense doesn’t appear to acknowledge this attribute)
• One other note is if you are adding this service into an MVC web application, you’ll might want to tell your app to ignore routes which access your service.svc. public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.IgnoreRoute("{resource}.svc/{*pathInfo}");


http://www.simplynoise.com/

I’ve only been sidetracked at this time to writing this post.

In the meantime, I wrote a couple macros for VS2005 to help my testing workflow.  I like TestDriven.Net as an add-in to the VS IDE, I just don’t like constant checks to check on what needs to be rebuilt.  Generally, I know the dependencies myself and would like to go right into debugging oppose to these checks.  So I created a macro to automatically attach and debug to a current “nunit.exe” process.

Here’s the code below, I think a nice little enhancement would be a listbox asking which one to debug (assuming you have multiple projects currently with NUnit guis up).

Afterwards export the file to where you put all your macros and then you can add them to your IDE.

   1:  Imports System

   2:  Imports EnvDTE

   3:  Imports EnvDTE80

   4:  Imports System.Diagnostics

   5:   

   6:  Public Module AttachToNUnitGui

   7:      Sub AttachToNUnitGui()

   8:          Dim ps As EnvDTE.Processes = DTE.Debugger.LocalProcesses()

   9:          Dim process As EnvDTE.Process

  10:          Dim p As EnvDTE.Process

  11:          Dim found As Boolean = False

  12:   

  13:          For Each p In ps

  14:              If p.Name.EndsWith("nunit.exe") = True Then

  15:                  found = True

  16:                  process = p

  17:              End If

  18:          Next

  19:   

  20:   

  21:          If (found) Then

  22:              p.Attach()

  23:          Else

  24:              MsgBox("No nunit consoles running")

  25:          End If

  26:      End Sub

  27:  End Module

Currently listening to Tapes N' Tapes - Insistor

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Though even for personal usage I think source control can be a total advantage in other areas.  Namely prototyping ideas.  It reduces the risk and time to attempt some different design or attempted refactor on the current solution.  Without some type of source management, you run the risk to have a sort “safe” working solution with an opportunity to attempt a “ground-breaking, change the world” design.  Attempting this change is the risk paid in time and chance that you fubar your solution to where you can’t get it back to the glory it once was.

I had the idea of writing a plugin which wouldn’t be as full-blown as a real version control system, all I need is a little snapshot I can get back to.  I wanted to be able to take a specific solution as argument and parse through the projects and zip them with directory to a location, sounds useful?  Too useful that it has already been done? correct again… This plugin saves me weekly.

This really had nothing to do with the super bowl, but more to do with my thumb killing me the last week so I chose not to play in a vball tournament this week. Team Haeg-ah still won. But because of this I’ve been shelling out code to this project like crazy. Good code or bad code?… still in the air on that one.

Anyways, this screen shot is technically not “in-game” but more of a performance test of 24-26 guys on the field at once running in place and also swapping in and out sprites assembled into a particular sequence. Looking promising so far, I hit a performance issue when adding the actual field. Field texture was too large and added a large difference in fps. Put in a tiling engine which I found on here by Kurt Jaegers, pretty quality – straightforward. Anyways I’m working on refactoring this into the TecmoBowl solution and looking at the performance differences then, we’ll see this week..

Anyways continuing to focus some of the common library functionality for this XNA toy project, getting closer by the day. The design process has been a little backwards at this point (tons of refactoring err… rewriting). Lot of proof of concept projects, testing some ideas, trying to be creative, borrowing others code to see what I can leverage. Can kind of be expected with the concurrent refactoring done with the XNA framework as well. They changed things on their side which have all made great sense, causing me to refactor on my side because of the new way of thinking. I think I’ve ironed out most of the kinks at this point, and have a pretty good understanding for what I’ll be able to work with on the next level up. More to come soon.

Came across this from Carmack on Slashdot interesting read on the differences between the PS3 and 360 SDKs.

I think thats enough random stream of consciousness for one night.