Delay's Blog is the blog of David Anson, a Microsoft developer who works with C#, XAML, HTML, and Azure.
With today's release of the Silverlight 1.0 RC and 1.1 Refresh, I've updated the Silverlight samples I own to run on the new bits. Specifically, I've uploaded the migrated source code and recompiled binaries for the team's Silverlight Airlines Demo, my Simple XPS Viewer Demo, and my Silverlight Surface Demo. Because the Silverlight 1.1 Refresh replaces the earlier 1.1 Alpha, the existing source and demo URLs remain the same and simply point to the new content.
The 1.1 Refresh's breaking changes from the 1.1 Alpha build we've all been using before today are documented in the SDK. The migration of the these samples was pretty simple and required very little code change. For the benefit of others migrating Silverlight apps, here are the specific incompatibilities I encountered along with the fix for each:
Additionally, a security-related change to the Downloader object now blocks access to file:// URLs. This means that the XPS Viewer and Surface demos will only be able to access their resources (images, files, etc.) when the host page is loaded from a web server. Specifically, loading Default.html from Explorer or by hitting F5 to run the project in Visual Studio will now result in an error message like the following:
Silverlight error message
To re-enable debugging for the XPS Viewer and Surface demos, I recommend the following steps which add a web site project to Visual Studio and access the demo page via the included Visual Studio Development Web Server (which uses http:// URLs and works fine). While there are other ways to work around the file:// restriction, I'm suggesting this approach because it automatically references the project files, doesn't require creating additional directories or copies of project files, and doesn't require getting involved with IIS. To enable debugging:
Okay, enough with the boring details - go get the Silverlight 1.1 Refresh and have some fun with it! :)
Earlier today Microsoft announced Beta 2 of Visual Studio 2008 and the .NET Framework 3.5. As usual, Scott Guthrie has a bunch of reasons why the new stuff is cool. My team has one more reason to add to the list:
We've just updated the 10618 Toolkit release with Beta 2 versions of the AJAX Control Toolkit that work seamlessly with VS 2008 and .NET 3.5!
The Toolkit's new "Framework3.5" downloads contain the latest 10618 Toolkit code in a VS 2008 Beta 2 solution/project. What we've done is make a handful of tweaks to better integrate with the new VS 2008 web designer enhancements for ASP.NET AJAX extenders. As you'd expect, the Toolkit controls work the same as before - but the development experience with VS 2008 is better than ever.
Download Visual Studio 2008 with the .NET Framework 3.5, the .NET 3.5 Beta 2 Toolkit, and find out for yourself!
And if you have any feedback, please share it with us on the support forum.
I wrote WindowPlacementTool in December of 2000 to solve a problem I had after beginning to use Terminal Services/Remote Desktop regularly. I made WindowPlacementTool available internally in 2001. Last week someone asked about getting access the source code to make some customizations and I figured I'd post the tool and its source here for anyone to use.
Download WindowPlacementTool and its source code by clicking here.
If you're picky about the layout of the windows on your desktop or if you
connect to your machine with Terminal Services at differing resolutions, you're
probably annoyed by having to re-layout your windows on a regular basis. It
seems like something (or someone!) is always coming along and messing with your
layout. But now that's a problem of the past; WindowPlacementTool can do all
the work for you! Just run it once to capture the layout you like, and then
run it again whenever you need to restore that layout. And because you can
save multiple layouts, switching resolutions is a breeze. Yep, it's that easy!
Command Line Help
Copyright (c) 2000 by David Anson (DavidAns@Microsoft.com)
[-h | -help | -?]
This help screen
[-c | -capture] [Capture_file_name.txt]
Capture the current window positions to a file (or standard output if
no file name is given)
[Restore_file_name_1.txt] [Restore_file_name_2.txt] ...
Restore the window positions from the data previously captured in the
specified file(s) (or standard input if no file name is given)
[Layout your windows however you'd like them]
[Capture the current layout to a file]
C:\Temp>WindowPlacementTool.exe -c 800x600.txt
[Optional: Edit the file to remove any programs you don't care about]
[Optional: Create a shortcut on your desktop for easy access to this layout]
[Here, the shortcut would run "WindowPlacementTool.exe C:\Temp\800x600.txt"]
[Run the shortcut you created above or run WindowPlacementTool manually]
* WindowPlacementTool saves the RESTORED locations of windows. If a window is
currently maximized or minimized, its restored location will be adjusted, but
the window will not be un-maximized or un-minimized by WindowPlacementTool.
* I have placed a shortcut to a layout for each resolution I use on my taskbar
so that it's always available when I need it.
WindowPlacementTool has served me well over the years - I hope others find it useful and/or educational!