Test user(s) needed for the next VolumeGadget

I wrapped up a new VolumeGadget about a week ago, with added hotkeys and an attempted refresh bugfix. I have not been able to verify that it installs correctly for all users, so I was hoping someone stopping by here would like to give it a shot.

The install procedure would roughly be to

1. Remove the VolumeGadget from the SideBar
2. Close the SideBar completely, by right-clicking its icon in the notification area
3. Restart the SideBar
4. Install the new VolumeGadget, from http://indev.no/VolumeGadget.gadget
5. Open the VolumeGadget settings and define a hotkey for e.g. muting. Save and accept the settings, and try the hotkey.

If you do try this, please do give me some feedback -- good and bad. I was hoping to get some work done with it before I ship it off to the Live Gallery.

Also; I've seen that people are requesting multi-speaker configurations. I'll look into that when I find time. In the meantime, if anyone has any suggestions for how that should look / be configured, feel free to leave a comment.

An open letter to sanity: Please have mercy on our souls

In an ongoing series of challenges with WSS 3.0, and SharePoint in general, I present one frustrating ordeal I face planted in yesterday.

I've got a WSS test environment installed on an x64 box, and it's running just fine. With the release of VS2008, I also installed that on the same box, to do some on-site testing. VS2008 is also, of course, behaving well. Combined, however, x64 + WSS + VS9 proved to be ... tiresome. I started a new web project in VS9; referenced the WSS assemblies from the Web Server Extensions\12 dir; added a few lines of source to connect to the local WSS site; then hit compile. Kablammo! "Attempted to load a 64-bit assembly on a 32-bit platform. Use ReflectionOnlyLoad() instead if trying to load for reflection purposes."

Ok, so apparently there's no x64 WebDev.WebServer.exe. Fine, I'll just copy the x86 WSS binaries from some other test box I've got. Again, no compilation errors, and this time the web site was actually loading... For a second. Kablammo! "FileNotFoundException. The Web application at http://localhost could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application."

"Ehm, well, uh..."

[30 minutes of frenetic, though effortless, searching]

"Sigh..."

So I gave up, and setup a quick site in the local IIS, and connected VS9 to that instead. After adding the same code, and referencing the x64 assemblies: success!

Using Visual Studio 2008, .NET 3.5 and Ajax with Windows SharePoint Services 3.0

With the recent release of Visual Studio 2008, I figured it would be a good idea to start using C# 3.0, .NET 3.5, Ajax and all the other goodies presented by that, when building SharePoint pages. My approach to get things up and running, was as follows.

1. Modify the web.config of the target web application

In configuration -> configSections:

    <sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
      <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
        <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
        <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
          <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="Everywhere" />
          <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
          <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
          <section name="roleService" type="System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication" />
        </sectionGroup>
      </sectionGroup>
    </sectionGroup>

In SharePoint -> SafeControls:

      <SafeControl Assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Web.UI" TypeName="*" Safe="True" />

In system.web -> httpHandlers:

      <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
      <add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
      <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" validate="false" />

In system.web -> httpModules:

      <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

In system.web -> compilation -> assemblies:

        <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

In system.web -> pages:

      <controls>
        <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add tagPrefix="asp" namespace="System.Web.UI.WebControls" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
      </controls>

2. Create an Ajax-enabled web page in Visual Studio 2008, and make sure to target .NET 3.5

To do this, I suggest you read up on Andrew Conells excellent article Using ASP.NET 2.0 Code Behind Files in SharePoint v3 Sites.

Once you've got the basic structure of the solution up and running, you can start adding the ASP.NET and C# code. I'll leave that part to you.

One piece of code you will need to stick in all web pages using Ajax, along with a script manager, is

<script type='text/javascript'>_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;</script>

... otherwise all postbacks after the first will be surpressed. This is part of the a double-submit protection enforced by the default SharePoint form.

You will also have to make sure the page you build doesn't contain its own <form>. Failure to do so will cause your newly added page to crash for no apparent reason ("An unexpected error has occurred").

3. Install the .NET 3.5 runtime on your server

Download available at microsoft.com.

4. Deploy the solution

Use stsadm to install the solution you built in step 2, then open the SharePoint central administration to deploy it to the sites in your farm.

That's all there's to it. Well it was for me, in either case. If you run into trouble; feel free to ask.

Another Vista Sidebar gadget: Volume control

I was originally planning to publish the Volume control gadget in time for the Norwegian Vista gadget competition, but missed the deadline slightly. In retrospect, I should have submitted the Volume control to the compo, rather than the quick launch gadget noted on earlier. SwiftRun is an odd little thing, with many quirks, and a limited audience. C'est la Vie :-)

In either case, I'm pondering whether or not I should give the gadget api another nudge. While it does seem like a slight waste of time, it would be fun to explore exactly how far the sidebar boundaries could be stretched (e.g. embedded DirectX, desktop control, etc.)

A scripted quick launch gadget for the Vista Sidebar

The last few weeks I've been hammering away on a Vista Gadget to quickly launch applications / websites / folders etc. using the keyboard. It's somewhat inspired of the old "Quixecute" application I made a few years ago, only this time the configuration is simpler, and it's all hosted in the Vista Sidebar.

Like other Gadgets, it's built using mostly JavaScript, CSS and HTML. In addition, I've wrapped up an ActiveX which enables the binding of global hotkeys to JavaScript callbacks. This means that you can have any other window focused, hit some key combination, and instantly focus on the Gadget's input box.

A demonstration video: http://screencast.com/t/eDUFuaTe3O5

Among the more nifty features, and also an extension from the old "Quixecute" app; you can now use JavaScript to script the actions. To add a shortcut to a website, you'd e.g. create a new command with the shortcut "mysite", and an action such as "http://www.mysite.com". If you'd like to enable parameters for the "mysite" shortcut, you could expand the action to "http://www.mysite.com/$param1-", or -- using the javascript feature -- "http://www.mysite.com/{{ if(this.params[1] == "foo") return "Whee!"; }}". This last action would add "Whee!" to the url, granted that the first parameter passed to the "mysite" command is "foo".

The Gadget, called (ever so cheezy) "SwiftRun", can be downloaded at http://gallery.live.com in a few days. I'll post the URL here when that happens.

Update: here's the gadget's download page