IIS7 and net.tcp only WAS hosting

I was interested in having net.tcp-only hosting (no HTTP) for a WAS-activated WCF service in IIS7. I found that IIS uses icons that trick you into thinking the site is in an error state when in reality it is not. Here are the steps I took to host my service:


Create the Website

I didn't want to use a virtual directory to host my service, so I created a new web site in IIS Manager (right-click Sites, then Add Web Site). The key here is to select the net.tcp binding type and specify the port in the Binding Information section:



After doing this, IIS7 will show the website in what appears to be an error state (it will have a red 'X' next to the website icon and many of the right-panel Actions menu options (notably the entire Manage Web Site section, containing the restart/start/stop controls and Advanced Settings link) will not appear. THIS SEEMS TO BE A RED HERRING. It will show the red 'X' whenever there are no HTTP bindings for the service. Here is what it looked like on a different site I set up in this manner:



The service will function in spite of the fact that it doesn't show as started. Starting/stopping the service must be done via the controls on the site's application pool (right-clicking it works):




Add Filesystem Components

At a minimum, you need your .svc file, a web.config file, and a bin folder containing the assembly(ies) that implement your service in the website root folder:



The .svc file simply contains the declaration of the class that implements the service:

<%@ServiceHost language="c#" Debug="true" Service="Microsoft.ServiceModel.Samples.CalculatorService" %>

In the web.config, you can omit all references to HTTP bindings, and set up the Metadata Exchange (mex) endpoint to use the net.tcp binding. You can even omit that if you don't need the service to be discoverable, although it helps to retain it:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service
          name="Microsoft.ServiceModel.Samples.CalculatorService"
          behaviorConfiguration="CalculatorServiceBehavior">

        <endpoint    address=""
                    binding="netTcpBinding"
                    contract="Microsoft.ServiceModel.Samples.ICalculator" />
        <endpoint    address="mex"
                    binding="mexTcpBinding"
                    contract="IMetadataExchange" />
      </service>
    </services>

    <!--For debugging purposes set the includeExceptionDetailInFaults attribute to true-->
    <behaviors>
      <serviceBehaviors>
        <behavior name="CalculatorServiceBehavior">
          <serviceMetadata /> <!--You do not need this node if you remove the mex endpoint-->
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Note that I did not specify any port information in the address for the endpoint using netTcpBinding as I wanted it to simply use the binding specified for the website (in the case of the website I showed creating up top, TCP over port 11111).


Create a Client

After this, you should be able to point to the service via net.tcp and generate a proxy. In Visual Studio 2008, you can use the Add Service Reference facility in your client project by specifying the following, substituting your service's TCP port for the '11111':

net.tcp://localhost:11111/service.svc/mex

Error on MOSS list submissions after December 2008 cumulative update

I recently patched my MOSS development environment to the post-SP1 December 2008 cumulative updates. The patch applied successfully (although it did require two reboots, one for the WSS cumulative update and a second for the MOSS one). In testing the site after the update, everything seemed to work well until I tried to add an item to a list. I then got this "Page has been modified since you opened it" error:



I followed the "refresh page" link and re-attempted my submission, and it succeeded the second time. I then tried a different list and received the same results. It seems that each list needs to be touched once before new list submissions will succeed.

** UPDATE: Perhaps there is a timer job that is fixing the lists. I tried another test after waiting a bit, and this time, I did not get the above refresh error upon making the first list submission. Patience may be the applicable virtue here.

Visual Studio 2008 x64: The Project Location is Not Trusted

Aargh... here's hoping I can save someone else some time on this. I raised a new Windows Server 2008 x64 .NET build machine and loaded up Visual Studio 2008 on there. I then tried to open up a project stored on a network share via a UNC path (\\server\share\my.sln) and got the dreaded "project location is not trusted" dialog.

I started looking for the .NET Framework 2.0 Configuration utility in the Administrative Tools area so I could grant FullTrust to my share. It isn't there. Apparently it used to deploy as part of the .NET Framework 2.0 SDK, but the .NET 3.5 (Windows 2008) SDK no longer includes it. This is a shame because the alternative, CasPol.exe, is harder to work with.

At any rate, I fired up a Windows Server 2008 command shell and ran the following command to trust my network share (for those not familiar with CasPol and its syntax, here is an excellent post):

caspol.exe -m -ag 1.2 -url file://\\server/share/* FullTrust

However, upon opening my project, I was continuing to get prompted that the location was not trusted. Finally I noticed that the Windows Server 2008 command shell was an x64 command shell... and Visual Studio 2008 is a 32-bit (x86) application. You have to set the security policy separately for the appropriate version of the .NET Framework.

I then navigated to the x86 version of caspol (%windir%\Microsoft.NET\Framework\v2.0.50727\caspol.exe), issued the same command... and voila, no more prompting!