When I created a template (posts here and here) that speeds up development of Silverlight Sidebar gadgets, I wanted to offer the smoothest development experience possible. Ironically, that in itself has been a very bumpy ride. The last hurdle I had to cross was to provide the familiar debug experience (F5).

My first attempt at this was just to set appropriate start options for the Web project that is in the template:

• Post build event that installs the gadget (runs a generated .gadget file)
• %ProgramFiles(x86)%\Windows Sidebar\sidebar.exe as the start program

This attempt failed with a very suggestive error:

I ran into this error every time the debugger was attached by the start options (F5, not using the Attach to Process command) and a Silverlight gadget was running in the Sidebar. I even tried to start debugging the sidebar when no Silverlight gadget ran, then added the Silverlight gadget to the Sidebar, but it was no use: same result.

I tried to get help with this error, but I could not find anything on it. The issue also seems like a very isolated corner case that does not affect too many people, so it would be tough to get any help.

While trying to find a workaround for F5 debugging, I wondered if I could run a custom app that manipulates the right Visual Studio instance to run the Attach to Process command and attach to sidebar.exe. Luckily, I was in Michael Leonard’s office at the time, because I got a quick answer: he had done similar things in the past. Half an hour later I had a code snippet about getting the Visual Studio automation object corresponding to a specific VS instance. Many thanks to Michael Leonard and Adam Nathan for getting the wheels turning on this.

The other parts of the solution flowed naturally:

• You can attach to the Visual Studio instance that has a specific solution open (info here).
• You can start the sidebar if it’s not already running (System.Diagnostics.Process.Start)
• You can launch the “Attach to Process” command using the DTE objects (info here).
• You can pass the full solution path as a command line parameter from the Visual Studio project Debug options (though not for all projects; for web projects it won’t work because macros are not supported).
• You can provide a transparent retry logic for COM calls that fail due to the destination being busy (info here; note the part about the single-thread apartment requirement).

I incorporated the custom app and the required build events into a new version of the Silverlight Windows Gadget template, available both in C# and VB flavour.

• In the .vstemplate file, using a CustomParameters section, as described here.
• Using a template wizard in order to specify run-time values in the IWizard.RunStarted method, as described here.

The problem is that these mechanisms don’t work as one would expect in the case of multi-project templates. The parameters specified in the root template are not picked up by the child project templates. I tried to find a workaround online but could not find anything. Finally, I came up with a workaround of my own.

My workaround requires that the root project template and the child project templates have template wizards.

For demonstration purposes, let’s assume that the root template has a RootTemplateWizard class assigned as the template wizard. Let’s also assume that the child project that needs parameters values from the root template has a ChildTemplateWizard class assigned as the template wizard. If your child project template does not already have a template wizard, then you need to add one in order to pick up parameter values from the root template.

The main thing that will allow the two wizard classes to communicate is the fact that for multi-project templates the solution/project creation is done within the same application domain. This means that static members from each of the two classes are viewable in both classes.

Let’s say that ChildTemplateWizard needs to specify a $MyInheritedParam$ value. This is done in the IWizard.RunStarted method by adding the value to the replacementsDictionary method parameter with the key “$MyInheritedParam$”. Because we’re anticipating the value being present in a static field, we use that field as the value in the replacementsDictionary, as indicated in the code below:

The value for the MyInheritedParam static field can be set from the RootTemplateWizard class, from its RunStarted method. The other IWizard methods are not suitable because they get called only after project generation is complete for all child projects. The code below illustrates setting the value for the static field.

It’s worth mentioning that RootTemplateWizard and ChildTemplateWizard don’t have to be placed in separate assemblies. If placed in the same assembly, you only have to install a single assembly in the GAC when installing the multi-project template.

P.S. While writing this post and looking up some links for documentation I stumbled upon a blog post where the same principle is used to transmit custom parameters to child project templates. This post did not appear when I was searching for an already existing solution and for me it was not immediately clear that it solved this issue.

Version 1.8 of the gadget is released for the following Visual Studio/Silverlight version combinations:

I modified the CSS for the HTML page that hosts the flyout and the gadget itself in order to eliminate all margins and padding. You can set these from the Silverlight controls.

I fixed the issue with docking/undocking the gadget. Aside from a JS bug I had, there was also some weird Silverlight behaviour that cause the freeze on some machines.

I exposed the SettingsClosed event for both the docked and undocked Silverlight controls and fixed an issue related to saving settings values.

I added build events for the SilverlightGadgetWeb project that create a .gadget file that can be used to install/update the gadget. I also added code to actually install/update the gadget on each build. I did this in order to provide an easy way of trying out code changes.

I tried to fix the Silverlight application references in the SilverlightGadgetWeb project, but the only way that can be achieved is by providing a custom wizard for the project template that requires installation in the GAC. For now I think this requirement would be too strong for the template installation process. Aside from re-adding the Silverlight project references I also recommend setting the project dependencies manually to make sure that the project is the last one to be built in the solution. You can do this by right clicking the web project, choosing “Project Dependencies…” and then selecting all the Silverlight projects. (see below for details)

I also tried to arrange for “F5 debugging” in Visual Studio, but it was not possible. I managed to set the sidebar as the start program for the web project, but the debugger failed to attach to the process if the Silverlight gadget was running. Even if attaching succeeds at start-up (when no Silverlight gadget runs), when I added a Silverlight gadget the debugger crashed. In conclusion, Debug->Attach to Process is still the best way to debug gadgets.

I will be adding more versions of the template as soon as I get around to it, so stay tuned if your development configuration is not available yet.

UPDATE: In version 1.5 of the template I created a project template wizard to properly create Silverlight application references for the SilverlightGadgetWeb project and to establish a correct build order. This wizard also prompts for the Silverlight version to use when creating the projects.

UPDATE: In version 1.6 of the template I fixed the F5 debugging scenario by providing a fake SilverlightGadgetDebugger project in the template that runs a custom app which attaches the Visual Studio instance to the Sidebar process (more info on the workaround here). Starting with this version, I’m also providing a Visual Basic.NET flavour of the template. For the download link, check the table above.

UPDATE: Version 1.7 of the template offers a fully automated debug experience within Visual Studio 2010 for the gadgets. In short, the SilverlightGadgetDebugger  project will close any running version of the Sidebar and start a new one containing only the gadget to be debugged. When debugging/running is done, the original Sidebar (if it was running) is restored. Also, a bug involving detection of the 32 bit Program Files folder (which was used to detect installed Silverlight versions and locate the 32 bit Sidebar) has been fixed.

UPDATE: Version 1.8 of the template offers support for debugging 64 bit gadgets. This can be done by setting the Target Platform to “x64” for the SilverlightGadgetDebugger. Changes to the Target Platform require a reload of the SilverlightGadgetDebugger project, because Visual Studio does not update the values of the parameters used in command line parameters for debugging.

I have a service contract with about 40 operations. After adding a new method to the contract, I get an error from the WCF Test Client:

Error: Cannot obtain Metadata from http://localhost:8731/Design_Time_Addresses/CDA.Services/ApplicationService/mex If this is a Windows (R) Communication Foundation service to which you have access, please check that you have enabled metadata publishing at the specified address.  For help enabling metadata publishing, please refer to the MSDN documentation at http://go.microsoft.com/fwlink/?LinkId=65455.WS-Metadata Exchange Error    URI: http://localhost:8731/Design_Time_Addresses/CDA.Services/ApplicationService/mex    Metadata contains a reference that cannot be resolved: 'http://localhost:8731/Design_Time_Addresses/CDA.Services/ApplicationService/mex'.    There is an error in XML document (1, 110009).    The value for the 'base' attribute is invalid - 'q1:EntityObject' is an invalid value for the 'base' attribute..HTTP GET Error    URI: http://localhost:8731/Design_Time_Addresses/CDA.Services/ApplicationService/mex    There was an error downloading 'http://localhost:8731/Design_Time_Addresses/CDA.Services/ApplicationService/mex'.    The request failed with HTTP status 400: Bad Request.

Same error if i attempt to add this service to a project. The message seems to change depending on which method I leave out, or put in. It seems to be getting hilarious, but it’s not. Accidentally, i got this error(truncated):

There is an error in XML document The maximum nametable character count quota (16384) has been exceeded while reading XML data.

After a bit of searching online, I found out that this is a recognized issue with the default metadata exchange binding, here. The workarounds didn’t look good at all to me, so I continued searching. Then, I came across this, which looks a lot more promising.

I created a custom wsHttpBinding that I used for the meta data contract. Now the task was to get the Visual Studio IDE and the WCF Test Client to use this binding when adding or updating a service reference. In order for this, corresponding bindings must be configured for each tool, in its .exe.config file. The binding must be identical with the one on the service side, and it must have a name that corresponds to the protocol used by it (http, https, net.tcp).

There are 3 places(files) that need to be updated: devenv.exe.config, WcfTestClient.exe.config and SvcUtil.exe.config. Actually, if you have several versions of the Windows SDK installed, you might have more than 3 places to modify. My advice is to do a search for each of the config file names and change as many of them as required in order to get your work back on track.

I would have thought that the mexHttp(s)Binding would allow for custom quotas for the reader. Perhaps in .NET 4.0? (vote here if it hurts)

The role of the Communication Broker is to cover the communication with the Streaming Service. By doing so, the code required of client applications is simplified, and less duplicate code will be generated for each application using the system. the broker also caches all variable changes and periodically sends all changes accumulated to the service, thus reducing the number of calls per second required by a single client to a predictable amount.

The broker uses a synchronized queue to accumulate changes and a timer to periodically clear the queue and send the resulting TimeSlice to the Streaming service. A receive background worker is used to reconstruct changes received from the Streaming service and raise appropriate UpdateProperty events.

The main operations provided by the broker are:

Start: used to start the processing of the broker by registering with the Streaming service. If the game is run in broadcast mode, this method starts the timer for the periodical TimeSlice send. If in observer mode, the broker requests the whole state from the Streaming service and raises the UpdateGameState event, to allow the application to initialize its state.

Stop: used to stop broker processing and to unregister from the Streaming service.

The events exposed by the broker are UpdateProperty, UpdateGameState and OutOfSynch. The first two events are to be sued by the application to change the value of a single property, or of all properties controlled by the XNA Streaming system. The OutOfSynch event is raised whenever the intervals between two consecutive slices do not match. The application can decide what to do at this point; for example, it could ask for the whole state of the game from the broker, which in turn would make the request to the Streaming service.

The application has to implement the GetCurrentState method of the IObservableGame interface in order to provide the broker with the current state of the application when needed.

Considerations for Writing Applications

There are some aspects that have to be taken into account when writing or adapting applications that use the XNA Streaming system.

User input has to be converted to changes of values. For example, mouse movement in a 3D environment can be translated into a set of 3 camera angles that completely define the way the camera is pointing. Pressing a button can be translated into a boolean flag set to true.

For simplicity, (most) user input should be ignored when in observe mode in order to avoid conflicts in UI commands that could have unpredictable effects.

One should take into careful consideration whether a piece of information is a “user input” variable, or a result of a law being applied to an initial value. Variables that are not broadcast have a high chance of being out of synch between the broadcaster and the observers. If the effect of such a variable is not critical (e.g. hit/miss decision) then it can be left out of the TimeSlice. Otherwise, one might discover that it is possible to miss a target, but hit it at the replay.

Results

The resulting prototype of the XNA Streaming system was presented at the 2008 edition of the Romanian Microsoft Community Bootcamp.

Conclusion

The XNA Streaming system is a good first prototype or toy, but it is by no means a decent communication framework. Aspects such as security, collaboration, dynamic send permissions, multicast, unicast and data conflict resolution have to be solved in order to obtain a communication framework.

The information is encoded in (<property name>, <value>) pairs. All serializable data types are supported for values. Users register with the Stream Service either as Broadcaster or as Observer. After this step, the Broadcaster uses the service to send updates for information (property-value pairs). Observers get notified by the service of the updated information via a IXNAStreamCallback callback contract, a feature of WCF services.

Updates for a certain variable can occur at a very high frequency (camera angle in a 3D application). If a separate call to the service would be generated every few milliseconds, then the service would easily become overwhelmed by the calls. The solution chosen is to “buffer” several information changes and send them all at time, at set time intervals. We name this “buffer” a TimeSlice. A time slice has a Duration and several time slice entries. A TimeSliceEntry has a PropertyName, a Value and a SliceOffset, used to express the time since the beginning of the TimeSlice when the value change has occurred. This way we gain control over the number of calls made to the service.

The Stream Service provides the following operations:

RegisterCallback: used to register with an application (given by name) for a role (given as a member of a GameMode enumeration). Only one Broadcaster can exist. This operation involves storing a user’s callback interface instance in a dictionary that has the application’s name as key and a list of callback interfaces (IXNAStreamCallback) instances.

UnregisterCallback: used to safely end a registration with an application (if a client does not unregister, sending updates or requesting the overall state would fail).

UpdateStateVariables: used to send a TimeSlice to all subscribers of an application. This is the actual method that performs the broadcast. It uses a method defined in the callback contract to broadcast the TimeSlice to all registered clients except the broadcaster.

GetCurrentState: to be used by an Observer in order to resynchronize with the broadcaster. This method should be called right after registering with an application. The GameState returned is a collection of game state entries. Each GameStateEntry contains a Key (the name of the variable) and a Value. The Stream Service request the current GameState from the Broadcaster via the callback contract.

The IXNAStreamCallback contract contains the following operations:

StateVariablesChanged: service calls this method for Observers whenever it receives a TimeSlice from the Broadcaster. It is up to the client to reconstruct the information changes in the TimeSlice with proper timing.

GetCurrentState: service calls this method for the Broadcaster whenever it receives a corresponding request from an Observer. The method returns the current GameState.

The Stream Service does not provide complex functionality, in order to make the actual information broadcast as fast as possible. The more complex functionality is implemented in the Communication Broker, that will be described in the next part of the series.

The main responsibility of the File Transfer Service is to provide access to streamable games. The service stores the game files in a database table, together with their relative file paths. This way the file system structure can be recreated when downloading the game. The game’s name, author and a short description are also stored in another table.

The operations that the File Transfer Service supports are:

• Create a game with no files: This operation simply creates a game entity with the game’s name, author and description with no files.
• Upload a file for an already created game: This operation stores a file together with it’s relative path to the game’s folder for a previously created game. This operation gets invoked for each file in a game’s folder.
• Delete a game: Removes a game from the database together with its files.
• Get all uploaded games: This operation returns a collection of general information about uploaded games (game name, uploader and description).
• Get all relative file paths for a game: This operation returns a collection containing the relative paths for all the files of a game. This list can be used to download each file and save locally.
• Download a file from a game: This operation downloads a file specified by the game to which it belongs and its relative path to the game folder.
• Get start up information for a game: This operation returns the game’s name, which is used to identify the streamed game at runtime, the address and endpoint name for the Streaming service. This information is used to start a game, both in observe or in broadcast mode.

The download/upload of each file takes place through streaming. This limits the in memory portion of a potentially large file at any moment to the size of the buffer of the stream. Stream parameters and return values are a feature of WCF services.

The File Streaming Service has as UI an XBAP that helps in uploading, downloading and starting a game.

As I mentioned in my previous post, at this year's Microsoft Community Bootcamp I entered in the demo competition together with Adi. We've had some issues in the past with (cheap) broadcasting of presentations. There are plenty of professional tools out there that accomplish this goal, but that's not my point. My point is that I have not yet found a cheap (free) utility that will allow me to give a presentation to several viewers that may not be in the same room (or the screen isn't big enough for the whole audience).

Given this background, Adi proposed we create a way in which several people can see the same thing that a broadcaster transmits. Further, the "thing" that everyone sees is actually an XNA game, that could might as well be an interactive presentation in 3D.

Description

The main idea is that, given an XNA game (possibly a game that did not take into consideration broadcasting though our "system"), produce a mechanism such that a broadcaster can transmit the content on the screen to any number of observers. As infrastructure for communication a WCF service was chosen. The reason for this is because it is relatively quick to implement and set up, it supports binary protocols and also bidirectional, asynchronous communication via service callbacks.

The first idea that comes to mind when deciding what to broadcast is whole images, pixel by pixel. The trouble with this is that if we have an application with resolution of 800x600 pixels, 32 bit color depth, at 60 frames/second, then we would require at least 109 MBytes/second/observer. This is totally unacceptable. Even with video compression, it would still require substantial bandwidth.

Instead, we decided that we could reduce the whole state of a game to a few state variables and a few "laws" that govern how these state variables evolve in time. Transmitting only some state variables proves to require much less bandwidth than transmitting the whole image. To further reduce the size of the messages transmitted, we identified 2 categories of state variables: the ones that are directly influenced by a user (through keyboard input for example), and the ones that have an initial value, and a law that dictates it's evolution in time. The state variables that evolve independent of user input can be left out of the "frame-by-frame" transmissions, and just the initial value has to be transmitted.

XNA Streaming Components

Given the initial description of the system proposed, we decided initially on three components:

The Streaming Service, that would receive calls from the broadcaster when state variables change and then transmit those changes through callbacks to all the subscribed observers. Aside from this main communication channel, the Streaming Service also provides initial synchronization for observers, meaning the service prompts the broadcaster (through a callback) to send the whole game state each time a new observer connects.

The File Transfer Service is responsible for storing all "broadcastable" game binaries,  delivering them to clients and providing startup information for each game (Streaming Service address).

The actual game, which has to be able to run in two modes: broadcast and observer. The game makes service calls to transmit/request state variables and responds to the callbacks of the Streaming Service.

At this point we analysed the communication between the game and the Streaming Service. Everything seemed fine, except for one detail: if we have a camera component that provides tens if not hundreds of new values every second, and we take into consideration that we have more than just the camera in a game, we can see that the number of service method calls performed by the broadcaster to transmit state variable changes is in the order of hundreds (at least) per second. This will cripple the service, regardless of the hardware it runs on (provided we stick to the "cheap" area...). A way to seriously cut down the number of service method calls was needed.

One way to reduce the service calls is to buffer the state variable changes, i.e. store each value together with the time at which the change occurred, and after a specific amount of time, send all buffered variable changes to the service, which in turn redistributes them to the observers, which reconstruct the sequence of state variable changes using the information received and timers. We call each such buffer a TimeSlice, and a touple of the form <VarName, VarValue, TimeSpan> a SliceEntry, where the TimeSpan is the time interval passed since the beginning of the current TimeSlice.

At this point we decided to call the new component a CommunicationBroker. It became clear that all code that would involve the Streaming Service would now be placed in the CommunicationBroker, and that sending calls/responding to the Streaming Service can be abstracted through this broker. In fact we now obtained an XNA Streaming Framework. This significantly reduces the complexity of the code that is necessary in the streamed game. Further more, now we had an actual streaming part, we stream the variable changes.

This is the end of part one of the article. In subsequent parts, I will describe each component in more detail and present some preliminary test results.

We all received a book on blogging and one on how to overcome disadvantages that prevent you from continuing your path on the road to (more) success (yes, it sounds a bit cheesy, but the book might be insightful). Keeping the inspirational note, the event's T-shirt featured Microsoft's Blue Monster, and the attached slogan: "Change the world or go home".

The first day was dedicated to MSP presentations. We started with some laughs as each university team lead stepped up and presented last year's achievements in a rather "fashionable" way...

An interesting point was the demo competition. Myself and Adi participated with a project named XNA Streaming (Cata will, again, correct me into saying it's XNA Framework Content Streaming) that uses WCF to transmit a set of data from one XNA Framework application to another one, the aim being to obtain the same "content" on each machine. I'll get back with a post on how we did it (for real this time ). The only competition was Mihai Nadas, with Acoustic Fingerprints. The two ideas were really nice (as nice as the one that won last year's competition), but I was a bit disappointed by the lack of competition. The outcome? Both projects were declared winners, and each won an XBOX 360 for their MSP team.

The rest of the day was filled with more presentations on being a good technology evangelist. No fun in the first day... well, at least not "organized" fun. We managed to spread across the hotel's lobby and use it's wireless network to play some LAN games in the evening.

Saturday morning there was a common session for MSPs and professionals on where Microsoft is going in the next year. After lunch, we had a bit of luck as the rain stopped and we went "out in the open" for some ATV, horseback riding, biking and Tyrolean traverse. Things went ok, considering it got quite cold, I had to ride a 700cc ATV with no helmet and one ATV crashed by tumbling through the air (I'm not kidding) and into someone's yard, but no one got (seriously) hurt.

In the evening, we had a few games of Mafia. It's quite a tradition at the Community Bootcamp, possibly because there's never a shortage in supply of great players. It was my first time playing the game and I enjoyed it.

On the last day, each team had a private talk with the academic program leader, Todi. After that, we had lunch and went home tired, but (at least a bit) happier...

The main attraction for (part) of our university's team were the squirrels in the park near our hotel. Apparently all Romanian squirrels answer to the name of Mariana, and they come to feed if you start making noise by knocking 2 nuts against each other. I can say that the squirrels respond well to food, as for the Mariana part... I'm not so convinced. Or maybe it's (somehow) my fault that they wouldn't answer my calls.

Some while ago I did a post on how to create a Vista Sidebar gadget using JavaScript. I also mentioned that I tried to create the gadget using XBAP or Silverlight, but due to the limitations in those technologies at that time, I decided that I had to give up on too much of the Sidebar gadget specific functionality (flyouts, cross domain data retrieval).

More than 6 months have passed since then and now I am pleased to announce that I've changed my opinion regarding Silverlight Sidebar gadgets. Due to the fact that the Silverlight technology has matured a lot (version 2.0 beta 2 is now available), Sidebar gadgets can be developed using this technology, without sacrificing any Sidebar gadget specific functionality. This is due to the fact that there is full interoperability between Silverlight and the JavaScript code. Also, cross domain calls are now allowed in Silverlight, so retrieving data is no longer an issue. Furthermore, it has been greatly enhanced due to the fact that one can consume WCF services using Silverlight.

Getting Started

The first step is to have a look over the "classic" way of developing Sidebar gadgets. Even though most of the "hard work" can now be done in Silverlight, the "wiring", the guts of the whole gadget are still the classic ones, relying on JavaScript and HTML. Next, if you are not familiar with Silverlight development, I recommend you spend some time getting comfortable with Silverlight. For this you can visit http://www.silverlight.net and try out the tutorials there.

The result of my inquiries in this subject is a Visual Studio project template that can be used to quickly start development for a Silverlight Sidebar gadget. I got inspired by the template Tim Heuer has created for jump starting Sidebar gadget development using just JavaScript/HTML. The requirements for installing and using the template are:

• Microsoft Visual Studio 2008 (Standard or better)
• Microsoft Silverlight 2.0 beta 2
• Silverlight Tools Beta 2 for Visual Studio 2008

After downloading the template installer from here, in order to install it, just run the downloaded file. The Visual Studio Content Installer will handle the rest (click next and ignore security warnings, because I did not sign the template).

After installing the template, in order to create a new Sidebar gadget, in Visual Studio click File->New->Project. You will notice that under the C# node, at the bottom, under "My Templates", a new entry has appeared: "Silverlight Sidebar Gadget". Give the solution a name and then click Ok.

You will notice that 6 projects have been automatically added to the newly created solution: SilverlightSidebarGadgetWeb, SilverlightGadgetDocked, SilverlightGadgetUnDocked, SilverlightGadgetSettings, SilverlightGadgetFlyout and SilverlightGadgetUtilities. In order, these correspond to: the main gadget web site project that will actually end up being deployed (all content and code is added to this site), the Silverlight control that is displayed when the gadget is docked, the Silverlight control that is displayed when the gadget is undocked, the Silverlight control that is displayed on the settings page of the gadget, the Silverlight control that is displayed on the flyout page of the gadget and a utilities library for Silverlight, providing a managed code API for Sidebar gadgets. This API translates to calls in the JavaScript Sidebar Gadget API.

IMPORTANT: Due to limitations in the way the template is built, the Silverlight applications have to be added to the gadget's main project manually. This can be done by going to the Property Pages for the website project, the Silverlight Applications tab and then click add for each additional Silverlight project. Clear the "Add a test page that references the control" checkbox, and make sure the "Enable Silverlight debugging"checkbox is checked if you want debugging capabilities for Silverlight. Silverlight and JavaScript simultaneous debugging is not possible at the current time (Silverlight debugging requires disabling Script debugging from IE).

In a later version of the project template this will no longer be required, but for that I have to add a custom Wizard to the project template that can prepare the projects in the template.

The code is commented, so I'm not going to cover it in detail. Also, for Sidebar gadget development guidance, read my previous post on the topic. The gadget is set up to use Silverlight controls for each page of the gadget. This is not required, and Silverlight controls can be removed from the project (along with their projects form the solution) as needed. There are 2 main classes defined in the SilverlightGadgetUtilities class: SilverlightGadget and SilverlightGadgetEvents. The first is used to access the JavaScript Sidebar Gadget API. The second is used to expose the JavaScript events related to a gadget as managed events in the Silverlight controls.

Known "bumps"

There are some things that will simply not work, no matter how hard you try to get them to work. Usually this is due to the fact that the current Sidebar gadget API or the gadget user experience provided by Microsoft does not allow it. These "hick-ups" are specified in the documentation comments of the classes or directly as comments.

Due to the fact that the Gadget JavaScript object does not allow attaching multiple event handlers for the same event, one must take care what event handler is registered for a particular event. Possible outcomes are: events that do not get triggered at all in the Silverlight controls, events that get triggered only in some Silverlight controls.

Due to the user experience with Sidebar gadgets, some events cannot be triggered in Silverlight controls: the Docked, Undocked events, all gadget events in the flyout, etc.

Some properties from the SilverlightGadget class are read-only even though the Sidebar gadget JavaScript API specifies that they are read-write. This is due to the fact that attempting to set those properties resulted in exceptions at runtime and those exceptions are most probably caused by the JavaScript API itself.

I tried to "discover" all such "bumps" that might appear and document them in the template directly. If there is something I missed or you have a question, please contact me or post a comment and I will try to modify the template to fix or document the issue. Also, any suggestions on improving this project template are welcomed.

I'm looking forward to seeing many Silverlight Sidebar gadgets being developed. If you create such a gadget using this project template, please let me know by posting a comment with a link to the Live Gallery page of the gadget or a link to a page describing it.

Once again, the link for the Visual Studio project template is displayed below.

FILE: SilverlightSidebarGadget.vsi

UPDATE: If you have Microsoft Visual Studio 2008 SP1 installed, you will need the Microsoft Visual Studio Tools Beta 2 for Visual Studio 2008 in order to be able to create Silverlight projects. This also means that you cannot use the provided template without installing the new version of the Silverlight Tools.

UPDATE 2: I’ve upgraded the projects in the template for Silverlight 3 Beta. The corresponding template can be found here.

UPDATE 3: I’ve created a version of the template for Silverlight 2 final. The corresponding template can be found here.

UPDATE 4: I’ve upgraded the projects in the template for Silverlight 3 RTW. The corresponding template can be found here.

UPDATE 5: I’ve created a version of the template using Visual Basic projects. The corresponding template can be found here.

UPDATE 6: I’ve created a version of the template for Visual Studio 2010, using the new extension format. The corresponding template can be found here.