For the past few weeks I’ve been working on fixing a number of bugs signalled about the Silverlight Gadget Template I created a while ago. I’ve had to work around some strange issues and try everything I could to make the gadget development experience as pleasant as possible. I’d like to thank Kiran Bachu for his valuable support in finding bugs and testing the gadget template.
Version 1.8 of the gadget is released for the following Visual Studio/Silverlight version combinations:
|Silverlight 3.0 RTW||Silverlight 4.0 RTW or Newer|
|Visual Studio 2008||Ver. 1.0 available here||N/A (not supported)|
|Visual Studio 2010||Available for C# and VB||Available for C# and VB|
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.