How to get to the start button in Windows Server 2012

How do you access the 'start button' in windows server 2012?

Good luck!

This photo has the hover spots clearly marked with bright red to make it easier.   In order to get to the 'start screen' you have to hover in one of these areas.

What?  You missed it?  Can't find it?  They are only a couple of pixels wide!  I circled them with  yellow quarter circles, the actual hover areas are still in red:

I'm an avid microsoft user, and a fan of many of their products.  However, this is just about the dumbest thing I have run across yet, and it crosses a line to absolute stupidity.  This is a SERVER OS!  I access it from virtual consoles across networks!  It probably isn't even a real machine, but is a virtualized host in a datacenter somewhere.  You might say, you can press the 'start button' on your keyboard right?  NOT on a virtual host, the start button works on your local PC only.  It isn't that big of a deal you might say, just hover on those spots, now that you know where they are, right?  Again, this is a VIRTUAL MACHINE which means it is accessed through a virtual screen on my desktop.  It doesn't have edges that your mouse stops at.  You have to very carefully line up the mouse with the exact 2 pixel wide spots and play with it until you get it right.  What is wrong with MS?  Does anyone in Redmond actually use this?  Once you finally get the start 'screen' up, the fun really begins, because everything has been moved and hidden and you get to start over with finding anything.  Note that the locations haven't been IMPROVED, they have just been MOVED for the sake of moving them.  Once you find the ones you need, you better pin them to your start bar, or you'll get to do this rediculous operation day in and day out.  Microsoft: Why the start button HATE?  What did the start button ever do to you?  You still put the stupid TRASH CAN on the main screen, and I don't even want it!

Microsoft should take a lesson from the auto industry:  DONT MOVE CRITICAL CONTROLS.  Imagine if they did this with cars, and they just randomly moved the turn signals, headlights, gas pedal and brakes around.  Each car you got into would have them in different places.  When you took it in for service, they'd re-arrange them just 'because' and if you didn't like it, it would be your own fault.

Break anywhere in Javascript from Firebug

Developing client side code can be challenging, often you need to be able to break at very specific place in the code to debug an issue, check a variable value or troubleshoot a non operational point.

Firebug has a very useful feature, 'Break on Next' which can be used to break on the next line of javascript that executes.  However, most pages have mouseover effects, click events and other things that may fire before you can ever get to the thing that you want to break on.  What if you want to break on a sub menu that can only be reached by clicking on it's parent? 

Firebug 1.10a8 introdcued a short cut key to enable 'Break on Next'. This allows you to get your mouse lined up on the exact position in your app that you want to break on, hit CTRL-ALT-B on your keyboard and then click.  This allows you to get past all the mouseover, onclick and other issues and break on exactly the click you want to break on.

Using an F5 iRule to solve cross domain ajax calls instead of CORS or JSONP

As a web developer at some point you will likely face a requirement to make cross-domain calls from a client side web page.  To prevent data from being loaded from multiple sites and presented as all belonging to the same site, browsers have a form of security built in that prevents scripts from being able to load data from other sites.

I recently worked with a situation that required deployment of a new RESTful web service layer that worked in concert with an existing ASP.Net application.  A process of refactoring required the projects to be treated separately and to be deployed on different URLs.  Both URLs were owned by the same organization and browser version compatibility requirements were well defined.  The browser support requirement included IE7 and newer, Firefox, Chrome and Safari.

Due to browser support issues, it was not ideal to use either CORS or JSONP to meet the requirements as both have various issues with certain browsers.  After reviewing the F5 documentation a solution was created using an iRule on the switch to represent the RESTful web site as a 'virtual folder' under the main web site.  This hides the real location of the REST service layer from the client and the client browser is not aware of the switch happening behind the scenes.  The client sees the RESTful service site on the same URL as the ASP.net site and nothing special is needed to make ajax calls.

when HTTP_REQUEST {
  if { [HTTP::uri] starts_with "/restservice" } {
    if {([string tolower [HTTP::host]] contains "aspapp.example.com")}{
      HTTP::header replace "Host" "restsvc.example.com"
 HTTP::uri [substr [HTTP::uri] 12 ]
    }
  }
}

This iRule traps on URI's that begin with /restservice.  If found it verifies that the host is the ASP.net application URL, and replaces it with the restservice URL replacing the Host from it's original URL (restsvc.example.com). The final command modifies the URI to remove the virtual folder from the call to create the new, proper URL that can be interpreted by the server.

The iRule allows pages at: aspappdomain.example.com to make ajax calls to the rest service at aspappdomain.example.com/restservice even though that URL doesn't actually exist anywhere, except in this iRule.

The key to making this work is that both sites must be serviced on the same IP address and be using host header names to serve the proper content.  If the sites are on different IPs the iRule will have no effect.

These few lines of code saved a lot of work on the client side and ensured support accross all browsers quickly and easily.

Returning raw data using WCF Rest 4

Sometimes you need full control over the content your are delivering to your http client.  You want to set the headers, you want to stream data from a disk or a database, or maybe you just want to send out data that doesn't get mangled by serializers.  This is easy to do with WCF REST projects.

        [WebGet(UriTemplate = "/SomeXmlThing")]
        public Stream OutputXmlData(string someInputParameter)
        {
            WebOperationContext.Current.OutgoingResponse.ContentType = "application/xml";

            string someXml = "<xmlData><notfullyFormedXML /></xmlData>";
            byte[] resultsBytes = Encoding.UTF8.GetBytes(someXml);
            return new MemoryStream(resultsBytes);
        }

By returning Stream, any data can be sent over the http channel.  With the proper content type set you can easily return any form of data using the stream such as images, raw xml, text, binaries, etc...  In this particular code sample the raw xml is returned without being touched by the XML serializer, which allows the raw xml to be passed directly to the client.  If this was done by returning string, the string would be passed through the XML serializer and encoded as text.

To var or not to var?

I have recently started using Resharper in Visual Studio 2010.  I enjoy using the tool and mostly agree with the suggestions it makes and rules it has for syntax and styling.  However, I find the rules around the var keyword to be going against my sense of code style.  Take the following code snippet:

int x = 12;

Resharper would have me use the var keyword here, per the rule "use 'var' keyword whenever possible".  So according to the resharper rule, this line should be written as:

var x = 12;

To me, this is less readable than the previous version.  Did I mean for x to be an int?  Maybe I needed an int16, or possibly a uint64?  Possibly I was mistaken altogether and needed a float.  For me, I would like the opposite rule, "use 'var' keyword only when required".

This is a big debate in the C# world.  More dicussion can be found at:

http://www.infoq.com/news/2008/05/CSharp-var

Personally, I come down on the side of minimal var usage.  When I want to use var everywhere and implicit type inference, I will go write some JavaScript.

Dynamic Response Formats with WCF REST 4

I recently had a need to return data from a RESTful service in more than one format.  The consumers of the service had varying needs, some preferred XML, others wanted JSON.  WCF REST 4 provides both types of output serialization very simply by decorating your exposed method with the ResponseFormat attribute:

[WebGet(UriTemplate = "/SomeData/?dataId={categoryId}", ResponseFormat = WebMessageFormat.Json)]

However, what do you do if you want to set the output type based on the consumer's preference?  The key is to modify the OutgoingResponse.Format property of the WebOperationContext object per the caller's preferences.

[WebGet(UriTemplate = "/SomeData/?dataId={categoryId}&format={format}"
public class DataObjects SomeData(int dataId, string format)
{
if (format == "json")
   WebOperationContext.Current.OutgoingResponse.Format = WebMessageFormat.Json;
...

Now your consumer can specify which output formatter is appropriate for their situation.  This wreaks havoc with the auto generated WSDL and may not be appropriate for public APIs but works well on services with known target audiences.

Debugging WCF REST Services

Recently I was working with a WCF Rest Service based on the WCF Rest 4 template. Not far removed from the original project template, I was working towards returning data from an underlying database using entity framework models and ran into some issues. There are known issues with attempting to do what I was doing, but that is for another post. In this case, I had an action returning results in Json. The method was using the inbuilt JSON serializer decorated as:

        [WebGet(UriTemplate = "", ResponseFormat = WebMessageFormat.Json)]
        public List<SampleItem> GetCollection()
        {
            return new List<SampleItem>() { new SampleItem() { Id = 1, StringValue = "Hello" } };
        }

This method is very simple and is the out of the box implementation of a default GET action in the Rest 4 Template. The decorator ResponseFormat = WebMessageFormat.Json instructs the framework to utilize the DataContractJsonSerializer class to format your function's results into Json format, ready for consumption by some caller.

Under the covers the WCF Runtime is calling your method, obtaining the results, and then formatting the results into Json and return it to the client. If you want to go deep into the details of this implementation, Carlos Figuiera has a post on his blog detailing implementation of your own formatter: http://blogs.msdn.com/b/carlosfigueira/archive/2011/05/03/wcf-extensibility-message-formatters.aspx

Now lets throw something at it that the JsonDataContractSerializer can't handle:

    [EdmEntityTypeAttribute(NamespaceName="DatabaseModel", Name="CUSTOMER")]
    [Serializable()]
    [DataContractAttribute(IsReference=true)]
    public partial class CUSTOMER : EntityObject
    {

If we change our webmethod to return type CUSTOMER like this:

        [WebGet(UriTemplate = "", ResponseFormat = WebMessageFormat.Json)]
        public List<CUSTOMER> GetCollection()
        {
            return new List<CUSTOMER>() { new CUSTOMER() { Id = 1, FirstName = "Hello" } };
        }

The DataContractAttribue(IsReference=true) decoration on the CUSTOMER class causes an error in the JsonDataContract serializer.  However, our implementation of the web service is not exposed to the error within the context of the method call being evaluated.  This is shown when we execute the method from Fiddler:

Instead of an exception encoded in the HTML on the page, the web server returns a 504 error, no response returned for this request.  How do we see what happened, why did the call fail, how do we troubleshoot this?

We need to use WCF tracing in order to see the errors occuring here.  We must enable diagnostic tracing by adding a configuration block to our Web.config:

  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel"
              switchValue="All"
              propagateActivity="true" >
        <listeners>
          <add name="traceListener"
              type="System.Diagnostics.XmlWriterTraceListener"
              initializeData= "c:\log\Traces.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>

With this tracing enabled, a file is written containing a tracelog of all activity that is traceable.  The level of tracing is set with the switchValue setting.  You will need to ensure that your executing process has write permissions to the file location specified.  The tracelog can be opened with the Microsoft Service Trace Viewer and we can step through each trace item and look at the details.  This reveals the real error:

The trace log gives us the error message within WCF and we can now troubleshoot the issue from there.  For more details on WCF Tracing see MSDN at: http://msdn.microsoft.com/en-us/library/ms733025.aspx

Process explorer

The Sysinternals team at Microsoft just released a new version of the process explorer with some great new features. I’m sure you have used it before, but this is a great debugging and analysis tool, if you haven’t used it before, the SysInternals group of tools allow you to graphically get under the hood of windows in some very powerful ways. Process explorer in particular allows you to see executing processes, what files they have open, what resources they are using, memory usage, threads, etc… extremely powerful! Do you know what your .Net app really does? Check it out at: Process Explorer

MVC.Net 3 and Team Foundation Build

A lot has been written about bin deployments of MVC.Net 3 and seperately about building MVC.Net 3 projects on Team Foundation Build.  I haven't seen anyone put the whole package together in a step by step format, so this post is inteded to do just that.  The issue here is that TFS Build by default does not copy required MVC.Net 3 dependencies to the output folder.  When you install your MVC.Net 3 application from the build server's output on a server that doesn't have MVC.Net 3 installed from the Microsoft MSI your app won't run because the required dependencies aren't there.  This article shows you step by step how to fix that.  You'll need Visual Studio 2010 SP1 for this to work.

1. From your project, right click on your project and select 'Add Deployable Dependencies'
2. Choose 'ASP.Net Web Pages with Razor Syntax' (You are using razor right?) and click OK.
3. Visual Studio will add a folder called _bin_deployableAssemblies and put the proper .dlls in there for you
4. Now, edit your .csproj file and add the following XML inside of the <Project></Project> tag: 

  <Target Name="CopyBinDeployableAssemblies" AfterTargets="CopyFilesToOutputDirectory" Condition="Exists('$(MSBuildProjectDirectory)\_bin_deployableAssemblies')">
     <ItemGroup>
         <_binDeployableAssemblies Include="$(MSBuildProjectDirectory)\_bin_deployableAssemblies\**\*.*" />
         <FilesForPackagingFromProject Include="%(_binDeployableAssemblies.Identity)">
                         <DestinationRelativePath>bin\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
         </FilesForPackagingFromProject>
     </ItemGroup>

     <Copy SourceFiles="@(_binDeployableAssemblies)" DestinationFolder="$(OutDir)%(RecursiveDir)" SkipUnchangedFiles="true" />
     <Copy Condition="'$(WebProjectOutputDir)' != ''" SourceFiles="@(_binDeployableAssemblies)"             DestinationFolder="$(WebProjectOutputDir)\bin\%(RecursiveDir)" SkipUnchangedFiles="true"/>
  </Target>

This XML will instruct the build server to copy the contents  of the folder created by Visual Studio to the output folder.  Check in your changes and check your drop folder for success.

Dark theme for Visual Studio 11

I love this theme for Visual Studio 11: http://blogs.msdn.com/b/visualstudio/archive/2012/05/29/visual-studio-dark-theme.aspx

Its good for your eyes and easier on your pixels.  Go dark!