• The ArcGIS API for Microsoft Silverlight/WPF version 1.1 is available!

    Version 1.1 of the ArcGIS API for Microsoft Silverlight/WPF is now available for download on the ArcGIS Server Resource Center.   The API includes a set of feature, functionality, and integration enhancments.  One notable difference; you'll download a setup executable which will install and configure Silverlight and WPF assemblies, components, and templates with Expression Blend and Visual Studio.  Here are a few highlights of what's new:

    • Silverlight 3 is now required with version 1.1.  Silverlight 2 is no longer supported. 
    • Silverlight 3 supports element binding, which means you can bind the Map property of a Navigation control to a Map using XAML - no code behind.
    • A complete, interactive design-time experience in Expression Blend 3.  You can drag, drop, and configure ArcGIS Silverlight and WPF controls on the artboard.
    • A set of Silverlight templates are integrated with Expression Blend 3 and Visual Studio 2008.  The templates provide a pre-configured, pre-styled, customizable architecture that enables you to create production worthy mapping applications quickly and easily.
    • Expression Blend 3 introduced behaviors, which are reusable pieces of packaged code that define interactive relationships between controls using XAML.  A new ArcGIS Silverlight and WPF library, ESRI.ArcGIS.Client.Behaviors.dll, includes a set of behaviors and actions to define interactive relationships between user input and Map behavior and content. 

    We invite you to try the new Interactive SDK to see the new features and functionality in action.  In addition, we've created an interactive Symbol Gallery for you to peruse and copy marker, line, and fill symbols for use in your application.  

    Enjoy!

    The ArcGIS Silverlight/WPF Development Team

  • Deep linking to map extents

    With the Silverlight 3 release, we get a new Navigation API that allows you to deep-link into your Silverlight controls, as well as enable the back/forward buttons in the browser. This blog post will show you how you can use the navigation API to link to specific extents in the map, and allow the user to go back and forward in the extent history user the browser history.

    The Navigation API allows you to use parts of the URI in the browser to load specific user controls in your project. To do this, let's first link to a specific user control in our a new default Silverlight + website application. First add a reference to the navigation assembly "System.Windows.Controls.Navigation".

    In our main page control, we create a Frame element, which maps to another "page", in this case Map.xaml. Map.xaml will be the page that holds our map. The MainPage.xaml should look something like this:

    <UserControl x:Class="MapNavigation.MainPage"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:navigationCtrl="clr-namespace:System.Windows.Controls;
    assembly=System.Windows.Controls.Navigation"
        xmlns:navigation="clr-namespace:System.Windows.Navigation;
    assembly=System.Windows.Controls.Navigation" >
      <Grid>
           <navigationCtrl:Frame>
                  <navigationCtrl:Frame.UriMapper>
                       <navigation:UriMapper>
                            <navigation:UriMapping Uri="" MappedUri="/Map.xaml" /> 
                       </navigation:UriMapper>
                  </navigationCtrl:Frame.UriMapper>
           </navigationCtrl:Frame>
      </Grid>
    </UserControl>


    The Frame uses the UriMapping entry to map the empty (root) URI to the user control "/Map.xaml".  Since the Frame’s Source property is not set, the Map.xaml associated with the empty URI is loaded by a default at runtime.    

    Next, right-click your Silverlight project in Visual Studio, and select to add a new User Control. Name it Map.xaml. This will be the sub-page that will be hosted by MainPage. This must be a of type System.Windows.Controls.Page, so the first step is to change the superclass. Go to Map.xaml's header and change the UserControl tag to navigation:Page and add the navigation prefix. While we are at it we also add the ESRI namespace and a simple map control:

    <navigation:Page x:Class="MapNavigation.Map"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:esri="clr-namespace:ESRI.ArcGIS.Client;assembly=ESRI.ArcGIS.Client"
        xmlns:navigation="clr-namespace:System.Windows.Controls;
    assembly=System.Windows.Controls.Navigation">
           <Grid x:Name="LayoutRoot">
                  <esri:Map x:Name="myMap">
                         <esri:ArcGISTiledMapServiceLayer ID="StreetMap"
           Url="http://server.arcgisonline.com/ArcGIS/rest/services/
    ESRI_StreetMap_World_2D/MapServer" />
                  </esri:Map>
           </Grid>
    </navigation:Page>

    In the code-behind of Map.xaml.cs, change the class declaration to inherit from "Page" instead of "UserControl" :  public partial class Map : Page

    If you run the application now, the application should load up Map.xaml. Notice the browser URI does not contain any parameters and the back button in the browser is disabled.

    So far so good. So now to allow the users to go back and forth when they zoom in/out we first need to tell the navigation service that the state has changed and provide it with a the link to the current extent that changed. We do this by listening to the ExtentChanged event of the map, and in the event handler call NavigationService.Navigate:

    <esri:Map x:Name="myMap" ExtentChanged="myMap_ExtentChanged" >

    private void myMap_ExtentChanged(object sender, ESRI.ArcGIS.Client.ExtentEventArgs e)
    {
           NavigationService.Navigate(new Uri(String.Format(CultureInfo.InvariantCulture,
         "#extent={0},{1},{2},{3}", e.NewExtent.XMin, e.NewExtent.YMin,
    e.NewExtent.XMax, e.NewExtent.YMax), UriKind.Relative));
    }

    The format we use can be anything, but we prefix it with "#" to tell the service that this is a "fragment" within the Map URI. If we didn't do this, the service would try and load a new instance of Map.xaml causing the map to reset. If we run the application now, everytime you change the extent, the browser URI will update:

    Notice the "$" symbol which signifies a fragment that contains extent parameters.  The fragment is handled by the Map page which is mapped to the default or root URI. 

    The back and forward buttons now work, but nothing happens when we click them. We still need to handle when the fragment changes and set the map extent according. We do this by overriding Page.OnFragmentNavigation. This method is called every time the browser fragment after "#$" has changed. In this method we will parse out the extent and set the extent of the map. Notice that we check if the extent really has changed. This is because the code in myMap_ExtentChanged also causes this method to get called, but in those cases there is no need to update the extent, since it already happened. Doing that could cause an infinite loop. Similar we ignore the code in the extent changed handler if we update the extent in OnFragmentNavigation using a simple boolean flag:

    protected override void OnFragmentNavigation(FragmentNavigationEventArgs e)
    {
           if(e.Fragment.StartsWith("extent="))
           {
                  try
                  {
                         string[] vals = e.Fragment.Substring(7).Split(new char[] { ',' });
                         double xmin = Double.Parse(vals[0]);
                         double ymin = Double.Parse(vals[1]);
                         double xmax = Double.Parse(vals[2]);
                         double ymax = Double.Parse(vals[3]);

                         Envelope mapExtent = myMap.Extent;
                         Envelope newExtent = new Envelope(xmin, ymin, xmax, ymax);

                         if (mapExtent==null || !AreEqual(mapExtent, newExtent, 0.000000001))
                         {
                               flag = true;
                               myMap.Extent = newExtent;
                         }
                  }
                  catch { }
           }
           base.OnFragmentNavigation(e);
    }

    bool flag = true;
    private void myMap_ExtentChanged(object sender, ESRI.ArcGIS.Client.ExtentEventArgs e)
    {
           if (flag) flag = false;
           else
                NavigationService.Navigate(new Uri(String.Format(CultureInfo.InvariantCulture,
         "#extent={0},{1},{2},{3}", e.NewExtent.XMin, e.NewExtent.YMin,
    e.NewExtent.XMax, e.NewExtent.YMax), UriKind.Relative));
    }


    Now when you run the application, you can use the back and forward buttons to visit previous extents, you can copy/paste the URL into a different browser or email it, and the map will start up at the same location.

    Download a sample from our development server - view the sample live to see it in action.

    You can learn more about the navigation framework on the following links:
    Silverlight Navigation framework screencast
    Tim Heuer's blog on the Navigation framework
    Tim Heuer's blog on Navigation behavior 
     

    Morten Nielsen
    Senior Software Engineer
    ArcGIS Server.NET, Silverlight/WPF, MapIt

  • Using services across schemes

    A number of questions have surfaced recently regarding support for ArcGIS Server services over a scheme different than a host application that uses the ArcGIS API for Microsoft Silverlight.  For example, when hosting an ArcGIS Silverlight API application on https that accesses ArcGIS Server services over http, the service fails to display as a layer in the map.  In this post I'll discuss a set of common issues encountered with cross scheme restrictions that explain this behavior - and present a few expectations for what should work.  Before we dive into this topic though, let's cover some background.  For security reasons, the Silverlight runtime restricts access to data and services for specific classes across schemes, domains and zones.   These restrictions may impact your use of data and services in the ArcGIS Silverlight API.  Scheme defines the protocol by which you access a resource.   This includes http, https, file, ftp, etc.   From the Silverlight perspective, scheme applies to the host application and resources it will use.  Usually Silverlight applications are hosted in a Web page, thus the host scheme is http or https.   Likewise, resources such as services and images are usually exposed over http or https.  

    The ArcGIS Silverlight API requires that applications be hosted on a Web server, thus the host scheme will be either http or https.  Resources used by components of the ArcGIS Silverlight API are often consumed as services or images on a Web server, so they share the same scheme requirements (http or https).  The use of services and images in the ArcGIS Silverlight API is impacted by cross-scheme restrictions in two ways:  1) when using services to retrieve metadata about a layer to display in a map or query and 2) when displaying map service layers in a map requires retrieving a dynamic map image or a set of map image tiles.  In short, when working across different schemes #1 is possible, #2 is not.       

    Since cross-scheme access to a service is allowed, how do you enable it?
     
    The solution is specific to the Silverlight platform.  You need to create a client access policy file on the services Web server that enables full access.  For example, the client access policy file on ArcGIS Online allows full access to http and https services on ArcGIS Online from Silverlight applications hosted on http or https. You can view the file in a browser via the url:  http://services.arcgisonline.com/clientaccesspolicy.xml



    The file contains two lines that affect scheme support.  The following line in the client access policy file allows access from http hosted apps to http services -and- allows access from https hosted apps to http and https services:

    domain uri="*"
    It does not allow access from http hosted apps to https services. This is handled by the next line:
    domain uri="http://*" 

    Both entries work together to allow full access.

    Note, the Silverlight 3 runtime will recognize a domain uri equal to "https://*".   This is only necessary if you want to restrict access to Silverlight applications hosted on https.  See the Network Security Access Restrictions in Silverlight topic on MSDN for more information.

    Even with cross-scheme access to services enabled, you cannot load an image across schemes in a Silverlight application.  It is a limitation imposed by the Silverlight platform.  Take a look at the document URL Access Restrictions in Silverlight on MSDN for more details.  Note the cross-scheme entry for the Image class is "Not Allowed".  This restriction is often to blame when a layer, accessed across schemes, fails to display in the ArcGIS Silverlight API Map control.   

    So, with this in mind, if the client access policy file allows complete access to site resources (as the ArcGIS Online and serverapps.esri.com do), what should you expect to work in the ArcGIS Silverlight API?  

    Silverlight Hosted
    Scheme

    Service
    Scheme

    Service
    access

    Image
    access

    HTTP

    HTTP

    Yes

    Yes

    HTTP

    HTTPS

    Yes

    No

    HTTPS

    HTTP

    Yes

    No

    HTTPS

    HTTPS

    Yes

    Yes

    The problematic combinations are clear - cross scheme access to map images (dynamic or tile) are not accessible. So how can you resolve this?  For ArcGIS Server services the solution involves changes on the server.   

    For dynamic (non-cached) map services the ArcGIS Silverlight API sends a request to export a map image to the Url defined on an ArcGISDynamicMapServiceLayer. The response format is JSON, which includes a url to the output image. The output virtual directory, which includes the scheme, is defined by the service. Unfortunately you cannot have multiple output virtual directories or define the scheme for the output image url.

    So how can you solve this on the server? Create two services from the same map config file (mxd, msd): one that generates output in a virtual directory accessible via https and another for http. For example, two services are available on http://serverapps.esri.com: California - which outputs to an http directory; California_SSLOUT - which outputs to an https directory.  The following table highlights the results of different scheme combinations for the host and service:

    Silverlight Hosted Scheme

    Scheme and Service access

    Result

    HTTP

    HTTP - California

    Works

    HTTP

    HTTP - California_SSLOUT

    Does not work (cross scheme image request)

    HTTP

    HTTPS - California

    Works

    HTTP

    HTTPS - California_SSLOUT

    Does not work (cross scheme image request)

    HTTPS

    HTTP - California

    Does not work (cross scheme image request)

    HTTPS

    HTTP - California_SSLOUT

    Works (prompt to display mixed content - http service request)

    HTTPS

    HTTPS - California

    Does not work (cross scheme image request)

    HTTPS

    HTTPS - California_SSLOUT

    Works

    For tiled (cached) map services, the ArcGIS Silverlight API constructs requests for tiles. The scheme in the tile requests is defined by the scheme in the Url for the ArcGISTiledMapServiceLayer.  In this case the service cannot be modified to return a url with a specific scheme, thus the REST endpoint must be available via a scheme that matches the host application.  This limitation is frequently encountered when working with "free" ArcGIS Online tiled map services.   If you need to host your ArcGIS Silverlight API application over https, thus far you've been unable to access ArcGIS Online free services directly because they were not available over https.  This will change - very soon ArcGIS Online will provide access to "free" services over https.

    Rex Hansen
    ESRI Product Engineer
    ArcGIS Server .NET, Silverlight/WPF, MapIt

  • Troubleshooting blank layers

    The Silverlight API is a client application dependent on services that might fail or be unavailable. In general, the Map control will not throw an exception if one service fails. This means that if one service is down, the application will continue to run and access the remaining layers. However, it also means that you don’t automatically get any error reporting, and if all your services fail, you will just end up with a blank map.

    When looking at the ESRI Silverlight forums, several users have reported issues with getting their layers to display or encountering blank maps. This blog post tries to outline the common reasons why a service does not display in the map, and how to remedy it.

    Most of the problems with a missing layer are related to browser security issues, so to trouble shoot client applications, there is one tool that I will recommend anyone to get familiar with: Fiddler. This is a free HTTP tracing tool that tracks the requests and responses between the browser and the web server, and logs if any requests failed. You can download this tool from http://www.fiddler2.com/.

    Once installed and launched, any network traffic initiated by Internet Explorer will be tracked by Fiddler. Note that any traffic to http://localhost/ is not tracked by default, and requires extra configuration. Other browsers might also require explicit configuration to work with Fiddler. I will be using Fiddler several times in this blogpost to track down issues you may experience.

    Cross-domain limitations

    Let’s for sake of argument say you installed ArcGIS Server on your own server, and you are trying to use one of its services. You first navigate to a service at your REST endpoint and copy/paste the URL to a layer in your Silverlight application, but the layer never shows. Let’s see what happens in Fiddler:

    We see two requests. Both are highlighted in red, meaning an error occurred, and from the result code "404" we can see that none of these files were found. So what are these files it tries to get from the root of my map server?

    Silverlight does not allow you to make requests to servers hosted on a different host than your web application. In this case I was running my application on http://localhost/, and trying to access a service on http://myserver/.  Silverlight will first verify that the server allows other applications to perform requests against that server. It does this by trying to download a clientaccesspolicy.xml file from the domain. This is a Silverlight access configuration file telling the client who can call the server and which parts it can request. Flex has a similar pattern in place using a crossdomain.xml file. If it fails to find the clientaccesspolicy.xml file, Silverlight will try and search for Flex’s crossdomain.xml file and use that instead. If both fail, services on the server will be unavailable, the layer will not be able to initialize itself, and it will not render in the map. You can read more about this Silverlight security feature here, and you can look at the policy file that ArcGIS Online uses here.  If your services and application are hosted on the same domain AND port number, this should not be an issue. It’s worth noting the port constraint, since Visual Studio by default will run the autogenerated test-website on a different port on localhost than your ArcGIS REST services (not to mention that you shouldn’t be using localhost in the Url for layer since ‘localhost’ would mean something different to each client hitting your Silverlight application).

    The cross domain restriction is by far the number one reason for a service failing to load.

    Cross-scheme access

    Another security feature in Silverlight is one preventing you from requesting data across different schemes, like http:// https:// and file://.  If you try to run a Silverlight application with a Map control using file:// in your browser URL, you might see this in your Map control:

     

    This is because the Map control will need to be in an application hosted on a http or https website, but you are running the application from the file system (scheme).  To resolve this, make sure your Silverlight application hosted by a Web server and make sure the Web site is set as the startup project in Visual Studio. When you start a new Silverlight application project in Visual Studio, make sure you say yes to create a Web site to host your application in:



    Restrictions also apply to http and https schemes. If your application is hosted on https and your service is hosted on http, or visa versa, you can access the service if explicitly permitted by the clientaccesspolicy.xml.  You cannot access images across schemes though, so while a request for service metadata may succeed, the request for a dynamic map image or cache tile will fail.   An upcoming blog post will cover this scenario in more detail. 

    Hopefully at this point you’re able to see your map, and Fiddler will show something like:

    In sequence you will see one successful request for clientaccesspolicy.xml, then a request for the service metadata, next a request for an image url, and lastly for the actual map image that was generated. Depending on which service type you are using, the last two requests may be different. The above example is using a dynamic map service.

    Service output folder configuration

    If you still have problems displaying the map service and you see something like below in Fiddler, you might have a configuration issue on your server end:

    Notice how it requests images from "myserver", but in the end tries to request an image from "localhost" (or some other domain/website unknown to the Silverlight client). If this is the case, the output folder of your ArcGIS Server service is not set up correctly.  Use Manager or Catalog to define the appropriate url to the output folder

    Unsupported file format (GIF)

    Silverlight does not support the GIF image format. If you are using a tiled service that has the tiles cached as GIF, it will not work with the ArcGIS Silverlight API.

    Tiled layers - Wrong spatial reference

    ArcGISTiledMapServiceLayer does not support re-projecting on the fly. This means that if you try and mix cached layers of different spatial reference, one or more services will not display. The first layer in the ESRI Map Control that has a spatial reference set will define the spatial reference for the entire map*, and any cached layer not matching this spatial reference will not load. You will see a request for the service metadata in Fiddler, but no requests for any image tiles. 

    *Note that you can override the default map projection by explicitly setting a startup extent with a spatial reference set. See the sample in the Interactive SDK. 

    Handling service errors

    In the beginning I mentioned that some servers might be unavailable, and the Map control will continue to run with the remaining layers. If this is the case, you may want to let the user know that there was a problem loading a layer.  All layers have an "InitializationFailed" event you can subscribe to, that will fire in the event of a layer failing to initialize. You can also use this yourself to track down any initialization issues as well.
    To listen for it, add the highlighted code to your layer definition:

    <esri:ArcGISDynamicMapServiceLayer
     ID="StreetMap"
     InitializationFailed="layer_InitializationFailed"
     Url="http://myserver/ArcGIS/rest/services/StreetMapUSA/MapServer" />

    In the event handler you can check the InitializationFailure exception to determine what the problem was, and display a message to the user. Example:

    private void layer_InitializationFailed(object sender, EventArgs e)
    {
      Layer layer = sender as Layer;
      MessageBox.Show(string.Format("Layer '{0}' is currently unavailable. Error: {1}",
         layer.ID, layer.InitializationFailure.Message));
    }

    Morten Nielsen
    Senior Software Engineer
    ArcGIS Server.NET, Silverlight/WPF, MapIt

  • Using Behaviors to enable MouseWheel in Full Screen and Out-of-browser

    With Silverlight 3.0 we now have a new MouseWheel event on all UIElements. Prior to v3, we had to rely on javascript in the browser to respond to mousewheel events in Silverlight. The problem with this is that there are several cases where the DOM bridge required to execute javascript is disabled. This includes full-screen mode, cross-domain hosting of the .xap file, out-of-browser installs and if the developer explicitly disabled the DOM bridge. Since the Silverlight Map Control is currently built for Silverlight 2.0 (but runs fine with Silverlight3) the user can't use the mousewheel to zoom in and out when in any of these modes. However, if you build your own application against the Silverlight 3 API, a little bit of custom code can enable the mouse wheel in these cases. This blog post will demonstrate a custom "Behavior" you can attach to your map, which will enable the mousewheel for zoom in these modes.

    Behaviors, triggers and actions are new Silverlight 3 features included in an assembly installed with Expression Blend SDK. They allow you to add a lot of functionality to your application using drag'n'drop in Blend, or with some simple XAML in Visual Studio's XAML editor.

    First of all, to create your own custom behaviors, you will need to add a reference to the following assembly: System.Windows.Interactivity.dll. This assembly is usually located in:

    "c:\Program Files\Microsoft SDKs\Expression\Blend 3\Interactivity\Libraries\Silverlight\System.Windows.Interactivity.dll"

    When the assembly reference is added, download the zip file included with this post, extract the contents to a location of your choice, and add the following file to your project: [WheelZoom.cs]

    Next go to your .xaml page that contains your map control, and in the header register the following two namespaces. One for the Interactivity assembly we just added a reference to and the other for the WheelZoom class:

    xmlns:i="clr-namespace:System.Windows.Interactivity;
       assembly=System.Windows.Interactivity" 
    xmlns:behaviors="clr-namespace:ESRI.ArcGIS.Samples.Behaviors"

    Lastly, inside your map control add the following highlighted code:

    <esri:Map x:Name="map">
         <i:Interaction.Behaviors>
              <behaviors:WheelZoom />
         </i:Interaction.Behaviors>
         ...
    </esri:Map>

    That's it! Now you have mousewheel zoom support when you are in full-screen mode or running your application out of browser.

    If you are not interested in the details of how this worked, you can stop here, but personally I think triggers, actions and behaviors are some of the really cool stuff in Silverlight 3.0 that allows you to much better structure, separate and reuse your code.

    So how did this work?

    First we create a new behavior class that inherits from Behavior<Map>. We specify Map as the generic parameter to signify that this behavior only works with the ESRI map control.

    Next there are two methods on the base class that you must override: "OnAttached" and "OnDetaching". Basically the first method is called when the behavior is added to the map, and the other when it is removed again. So in OnAttached we add an event listener for the MouseWheel event on the map control, and remove it again in OnDetaching:

    protected override void OnAttached()
    {
         base.OnAttached();
         this.AssociatedObject.MouseWheel += AssociatedObject_MouseWheel;
    }
    
    protected override void OnDetaching()
    {
         base.OnDetaching();
         this.AssociatedObject.MouseWheel -= AssociatedObject_MouseWheel;
    }

    The "AssociatedObject" is in this case the Map control that the behavior is attached to.

    In the mousewheel event handler we will simply zoom the map around the mouse pointer, using the ZoomToResolution method which allows us to specify a point to zoom about:

    private void AssociatedObject_MouseWheel(object sender, MouseWheelEventArgs e)
    {
         double factor = e.Delta < 1 ? 
         this.AssociatedObject.ZoomFactor : 1 / this.AssociatedObject.ZoomFactor;
         MapPoint center = AssociatedObject.ScreenToMap(e.GetPosition(AssociatedObject));
         double res = this.AssociatedObject.Resolution * factor;
         this.AssociatedObject.ZoomToResolution(res, center);
    }

    The code you can download here adds a little extra logic to better match what the javascript-based mousewheel zoom does, but this is the general idea.

    To round this off, here's another type of behavior you can add to your map: [MaintainExtentBehavior.cs]

    This behavior will maintain the current extent of the map when the map (browser) is resized. Change to the Silverlight application to display full screen -or- grab a corner of the browser and resize it.  The extent of the map will be maintained.  Add it in the Interaction.Behaviors collection like we earlier did with the MouseWheel using the following syntax:

    <i:Interaction.Behaviors>
        <behaviors:WheelZoom />         
        <behaviors:MaintainExtentBehavior /> </i:Interaction.Behaviors>

    The behavior works much the same way, but uses a set of events on the map to store the current extent (ExtentChanging, ExtentChanged) and set the map extent (SizeChanged).  If you want to see more examples how also actions and triggers can be used, take a look at the Showcase application in the resource center.

    Download a sample from our development server - view the sample live to see it in action.

    Morten Nielsen
    Senior Software Engineer
    ArcGIS Server.NET, Silverlight/WPF, MapIt

  • Welcome to the Silverlight/WPF Blog!

    I would like to take some time and welcome you to the Silverlight blog and cover some initial thoughts.  First a quick status of where things are...  

    Overall, the Silverlight/WPF API has been received extremely well within the community.  So far, we have logged over 2000 downloads since we went final (UC 2009) and it does not show any signs of slowing down.  The forums are very active with the community using the Silverlight API and the Silverlight team members answering a lot of the forum postings directly. The  Code Gallery is very active as well, which is where we are posting some additional work that the team thought would interest you, like the Silverlight Showcase app, KML, WMS, GeoRSS and Heat Map layers not to mention a host of user samples also posted on the code gallery.  One notable achievement by the team is the ESRI ArcGIS Silverlight Toolkit CodePlex site.  This is a first for any development team at ESRI and we hope to keep the trend moving forward.  

    We were also able to build a small, light weight product on top of the V1.0 Silverlight/WPF API called ESRI MapIt.  This is a cool product, light weight, easy to use and install, very fast and of course, support for both x86 and x64. Keep an eye on the MapIt blog for more info. 

    As a team, we are small, agile, and very passionate about our work with Silverlight and WPF and hope to keep you happy along the way. 

    The obvious question is: What’s next?

    Well, the team is actively working on a v1.1, which we will make available soon.  It will include a number of bug fixes, Design time support for both Visual Studio and Expression 3, and a move up to Silverlight 3.  Yes, we are moving up to Silverlight 3; and based on the latest ArcGIS Developer Poll, most of you are too.  Of course, there are a few more things happening with v1.1, but that is for another post.  

    Back to Silverlight 3 for a moment, there so many benefits to working with SL3 that Microsoft made it very difficult for us not to make the move.  Things like element binding, enhanced graphics, the new Bitmap API and offline application support.  Tim Heuer has a good blog entitled "A guide to Silverlight 3 new features".  In this post Tim helps you understand some of the new features and benefits of SL3.    

    The WPF API is also going strong.  I continue to hear how people are using the WPF API in some real cool apps.  Apps like Surface Apps developed by the Application Prototype lab and WPF API based apps that use ArcGIS Engine for advanced disconnected scenarios and analysis.  One notable piece of feedback that we received from the community was to also have a WPF specific SDK.  Well, we heard you and in the next couple of weeks, we will make this available for download from the Resource Center.  

    With all that said, we would also like to ask you, the ESRI Silverlight community, to help us along the way and provide the feedback we need to help you get your job(s) done.  As we have said time and time again at conferences and such, we are adhering to a concept of "less is more".  This means that the core API will stay as small and tight as possible only adding features that the users are asking for.  Use the forums, send us emails, talk with your regional reps; however you want to do it, but get us the information we need to help you.

    E
    njoy the API’s!  We look forward to seeing all the cool things you are and will be building with them.

    Art Haddad
    ESRI Development Lead and Architect
    ArcGIS Server .NET, Silverlight/WPF, MapIt