Oddballs like us cannot rely on the code-generation that comes with Visual Studio.  So when we write a new ASP.NET application, and we want to use the .NET 3.5 goodies in that app - things like var types, and LINQ - we need to explicitly specify that we want .NET 3.5 compilation.  Same is true if you are writing a WCF service and want to use REST or any of the var types or LINQ.

I've done this twice now and had to search for the way to do it both times.  I'm putting here as a "note to self" and also as a reference for anyone else.  These are the custom magic incantations for web.config, if you want to enable .NET 3.5 in your ASP.NET app, or in your WCF Service - eg, the cool REST stuff from .NET 3.5.

<?xml version="1.0" encoding="utf-8"?>
<configuration>

  <system.web>
    <compilation debug="false">  
      <assemblies>  
        <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
        <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>  
        <add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
        <add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
      </assemblies>  
    </compilation>  
  </system.web>


  <system.codedom>  
    <compilers>  
      <compiler language="c#;cs;csharp" extension=".cs"   
                type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"   
                warningLevel="4">  
        <providerOption name="CompilerVersion" value="v3.5"/>  
        <providerOption name="WarnAsError" value="false"/>  
      </compiler>  
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"   
                type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"   
                warningLevel="4">  
        <providerOption name="CompilerVersion" value="v3.5"/>  
        <providerOption name="OptionInfer" value="true"/>  
        <providerOption name="WarnAsError" value="false"/>  
      </compiler>  
    </compilers>  
  </system.codedom> 

</configuration>

Last week at the PDC 2008, Microsoft released the public beta of “Geneva”. 

“Geneva” is three things:

Geneva Server.  This is a security token service (STS), as defined in the OASIS WS-Trust specification.  This thing issues and transforms claims, manages user access, and enables automated federation.

Geneva Framework.  This is a managed (.NET) Framework that helps developers build claims-aware applications and services, that connect to the STS.  You can use it to process claims on either side of an authorization transaction (requestor or responder).

Windows CardSpace Geneva.  This is just an extension of the CardSpace thing in Windows you know and love today.  chances are, you've seen it, but you don't use it. In a nutshell - CardSpace is a set of Windows features and user-interface that lets users navigate access decisions and control how personal information is used. Everyone has multiple claims as part of their identity: you are a student at UW, you are an employee of BigCorp, you are a member in good standing of a particular club, you have received a particular security clearance, You have a bank account with number 4444-444-44 at BigBank, etc. CardSpace lets you decide which of the many claims you can make about your identity, to disclose to a particular service or server. Rather than disclosing "everything" about you to every server or service, you disclose only what you need to disclose for the particular transaction. That is one aspect of the identity model, and CardSpace is the thing in Windows that makes that possible.

CardSpace technology, and actually, the Identity Metasystem concept, is pretty cool. If you haven't looked at it, you should.   The problem with CardSpace and more generally, using claims-based access control (CBAC) in an application, has always been that it was impractical. Microsoft delivered a client (CardSpace), but we didn't deliver an STS! And we didn't deliver an easy way for the server to evaluate and verify claims. Therefore developers didn't have an easy way to employ CBAC in their apps. Geneva will change this.

Now, some of you are thinking, "ok, this sounds interesting but I don't know what you are talking about with this WS-Trust thing and 'claims based access control'. And I can understand that. Here's the thing - instead of hand-crafting access-control logic into your application, instead of managing your own user list and access control list, you can "outsource" this job to an STS. The Authorization Manager (sometimes called AzMan) is similar in philosophy, so if you understand the utility of AzMan, then you will get the idea of CBAC. But AzMan is not standards based, not federated, not truly claims-based (it is role based, which is less general than claims-based), and not usable in Web services transactions. Imagine generalizing AzMan and federating it and using only standard protocols, and that's where we're headed with Geneva. You're gonna want to use this.

I said "Geneva is standards based." The key to standards is support by the vendors, in tools, frameworks, servers, and so on. Currently, WCF from Microsoft supports WS-Trust, as does the WSIT from Sun. WebSphere App Server v7.0 announced support for WS-Trust just last month, but I haven't had the time to test it with Geneva. Not sure of other frameworks. The key is, with Geneva, the server is now here, and people can and will start building on this. I think with the release of the Geneva CTP, we'll start to see broader adoption of WS-Trust and standards-based CBAC among frameworks. 

One last thing to point out: In the cloud, the Microsoft Services Connector and the .NET Access Control Service, both announced at PDC as well, are built on “Geneva” technology and share the same claims architecture.

More Information:
Kim Cameron’s blog
Vittorio Bertocci’s blog
Get the Geneva beta
Single stop resource on Geneva

A list of “Geneva” sessions recordings at PDC:

From the IBM Announcement for WebSphere Application Server v7.0: 

WebSphere Application Server V7.0 does not include the WebSphere Connect JDBC driver that had been provided in WebSphere Application Server V6.1. To replace the functionality provided by the WebSphere Connect JDBC driver, WebSphere Application Server V7.0 is tested with the DataDirect Connect for JDBC driver and the Microsoft SQL Server JDBC Driver, which may be obtained from DataDirect Technologies or Microsoft.

Connect your WebSphere/Java apps to SQL Server with this driver.  Actually, you can connect *any* Java application to SQL this way - it doesn't have to be running in WebSphere.  If you develop in Jetty or Tomcat or JBoss or Geronimo, the MS JDBC Driver will work fine for you. 

If you have .NET applications, or Office apps, of course you can connect them to SQL Server also. In this way, SQL Server can serve as a nice interop point between Java and .NET applications, or between Java and MS Office (Let's say... an Excel spreadsheet).

Some notes:

• the MS JDBC Driver is a free download.  
  
• It is a full type-4 (100% Java) JDBC 3.0 driver, fully tested and compliant with Sun's verification suite.
  
• It connects to SQL Server 2000, 2005 or 2008
• It works from any JVM on any OS platform, including Linux
  
• It works with the Express version of SQL Server (which is also a free download) and it works with the Standard and Enterprise versions, too.
• There is forum support available for the driver
• There's a tech preview of a JDBC 4.0 compliant driver, here.
  

This program gives ISV startup with less than USD$1m in annual revenue (lower amounts for some other countries - for example it's just USD$250k for Egypt) free access to MSDN subscriptions. Nice. You get Visual Studio, Expression, VSTS, SQL Server, BizTalk Server, SharePoint Server, Windows Server - all you need to build a software app on the Microsoft application platform. 

There are some requirements:  you have to be a software startup, privately held, and there's the revenue limit.  If you don't qualify for that deal, there are others that may work for you. Here's a summary :

• BizSpark - Free development software for ISVs.
• Empower for ISVs - Accelerates ISVs development on the Microsoft platform with software, support, and other resources.
• DreamSpark -  like BizSpark, but for Students. Download Microsoft developer and design tools at no charge.
• Free software - Free software and trial software.

Damian's used the same WCF extensibility points I used to produce some boilerplate that varies the response content type from JSON to XML, based on the Accept or Content-Type header of the GET request.  He extends WebHttpBehavior to return an IDispatchMessageFormatter that does either JSON or XML.

And then in the DynamicFormatter code, he just picks the formatter as appropriate:

It's pretty nifty and it requires no changes to the app logic.  You need to use a custom ServiceHost and use a custom attribute on each Operation.  Because it uses the HTTP headers and not the URI itself to determine content-type of the response, I think it has some nice benefits over the approach I described in April.

Damian's got a full VS2008 solution will all the boilerplate code.

check it out.

The WCF REST Starter Kit is a set of features, Visual Studio templates, samples and guidance that help people build REST apps using WCF.  WCF, part of the .NET Framework, got some enhancements for REST support in the .NET 3.5 release.  This starter kit is a bunch of blueprints and supporting material to make it easier to use what is in the Framework for REST.

Like, blueprints and guidelines for how to do caching, security, error handling, help page support, conditional PUT, push style streaming, type based dispatch and semi-structured XML support.  Whoa!

The WCF REST Starter Kit also provides Visual Studio templates for creating REST style services such as an Atom feed service, a REST-RPC hybrid service, Resource singleton and collection services and an Atom Publishing Protocol service. In addition, there are samples, documentation and other guidance that help to use these new capabilities.

The goal is to provide a toolset that simplifies building RESTful services today, and to take feedback from the developer community on the features provided in the WCF REST Starter Kit that will shape future REST capabilities in WCF 4.0.

It's very good to see this. For those that don't know, AMQP is the Advanced Message Queuing Protocol, a nascent middleware standard that describes an interoperable protocol for application messaging systems. Driven primarily by companies, and not by vendors, AMQP aims to introduce new innovation, more competition, and better interop between messaging subsystems. 

If you've read any of my other blog postings you know that interop and messaging systems are near and dear to my heart.  This is very good indeed for customers who build and run enterprise information systems with a great deal of heterogeneity. Imagine if MSMQ and the messaging infrastructure on RedHat Enterprise Linux used the same on-the-wire protocol, and supported the same service semantics.  This would mean your messaging clients could talk to either message service with full interoperability and switchability. 

Some nice possibilities here. Great to see it being driven so much by the companies themselves.

IIRF is Ionic's Isapi Rewrite Filter.  It is a small, cheap, easy to use, URL rewriting ISAPI filter that combines a good price (free!) with good features. It is fast and powerful. It works on IIS 5.0, 5.1, 6.0, and 7.0.

You may have heard about the Rewriting Module for IIS7 from Microsoft.  This is not that thing.  This is a rewriter for IIS6 or 7. 

It works with regular expressions. It's fast.  It's written in C. It's open source.  It does not require the .NET Framework.  It works with PHP, Ruby, ColdFusion, JSP, ASP.NET, and anything else you can run on IIS.

Check it out.

Major new features:

• Unicode support, as well as support for arbitrary code pages. Now you can build zip files that have names with Unicode characters.
• Large file support.  Full streaming architecture means you can zip large files without loading them into memory all at one time.
• Partial Trust  - for running on shared hosetd ASP.NET servers 

DotNetZip is still small, fast, and the easiest .NET zip library to use. Check this sample code:

      using (var zip = new ZipFile())
      {
        zip.AddDirectory(directory);
        zip.Save(targetZip);
      }

It is 100% managed code. People love it:

DotNetZip is powerful, too: it does password-protected zip files, zip comments, self-extracting zips, zip-to-stream, stream-to-zip, and more.  You can use it in any .NET app - WinForms, console app, ASP.NET page, etc.  In ASP.NET, you can write a zip archive directly to Response.OutputStream as a download to the browser client. On the codeplex site, there are lots of examples and the documentation is solid.

DotNetZip is free, but is donationware. For those who are happy with DotNetZip, I am accepting donations on behalf of my favorite charity.

For those of you who have day jobs and find it hard to keep up with all the code-names and product names coming out of Microsoft, Silverlight is the name a cross-browser, cross-platform, and cross-device plug-in for rich interactive applications for the Web. Huh?  Break it down:

1. Silverlight is a browser plug-in: Runs in IE, Firefix, Opera, and more. 
2. As a plug-in, Silverlight provides a runtime, which is at it's core, .NET based.  It is a lightweight version (subset) of the .NET Framework. When you write declarative code, you'll be using a .NET langauge   
3. Silverlight is cross-platform: Microsoft produces versions to run on Windows and Mac and the Mono project is doing Moonlight for Linux. 
4. Silverlight is for Rich Interactive apps.  This means high-def video, audio, hypertext, dynamic data.   

Bottom line, Silverlight is like Adobe's Flash, but built on a broad platform (.NET and the CLR) with mainstream language support (C# and VB) as opposed to a relatively narrow platform and runtime requiring ActionScript.

Because Silverlight uses a lightweight NET runtime, if the Eclipse4SL project succeeds, developers will be able to use Eclipse tools to create .NET applications. How about that!  You will be able to edit XAML and C# in Eclipse!  

Milestone 1 for Eclipse4SL is set for this week: October 14th there'll be a CTP of the tools. Feature complete in December.  Nice!  I love to see this. Love it, love it, love it.

From the Eclipse4SL website, Interop is a key criterion for success:  Increased Interoperability: Eclipse will contain functionality that will help Java Developers build Silverlight applications that work better with Java Web Services using REST, SOAP, JSON and other standards.    There's a company called Soyatec, a longtime Eclipse Foundation member, doing the analysis and development work.

For my part, I'm so glad we're getting to the point where we all can work together collaboratively to produce interesting stuff for customers.   Next milestone:  when a proejct like this doesn't warrant blog posts entitled "interesting times indeed." 

:)