Some great news, the latest version of the Silverlight Toolkit (November 08) has been made available to download on CodePlex. This release includes a host of new controls for Silverlight including TreeView, AutoCompleteBox, DockPanel and one I've been eagerly awaiting - WrapPanel.
Once you've downloaded the toolkit you'll probably want to add the controls to the Visual Studio toolbox. This can be achieved by the following steps:
(Note: I'm doing this on an installation of Visual Studio 2008 SP1 with the latest Silverlight Tools RTW installed)
- Extract the Toolkit zip file to a location on your computer
- Open up a Silverlight project in Visual Studio 2008 SP1
- Open up a XAML file and ensure that the Visual Studio toolbox is visible (if not it can be turned on via View > Toolbox or Ctrl+Alt+X)
- Right click on one of the toolbox headings and select Choose Items... (Note: The dialog took quite a while to load up on my machine)
- From the Choose Toolbox Items dialog, click on the Silverlight Components tab and then click Browse. Navigate to the folder where you extracted the Silverlight Toolkit and open the Binaries folder and select one of the assemblies and click Open. In this example I selected Microsoft.Windows.Controls.dll. Then on the Choose Toolbox Items dialog you should see that new controls have been added to the list and preselected (AutoCompleteBox, DockPanel etc.)
- Click OK and you should then see the new controls available in the toolbox.
- Repeat these steps for the other assemblies included with the Toolkit and you're good to go :)
I saw this handy little helper function being used on a MOSS
screencast by Todd Bleeker and decided to figure out how he did it :).
Basically it allows you to view the public key token of an assembly
from within Visual Studio's output window, which saves time when you
need to grab the key for use with the safe control entries in the
web.config for example.
First step, fire up your copy of Visual Studio 2005 and open up a webpart class library project. Then from the Tools menu select External Tools. This will bring up the following dialog:
From the options, click Add and then give your utility a title. Now all we're doing here is essentially grabbing the output from the sn.exe command, so you will need to provide the path to your local sn.exe file. Mine was located in the following folder:
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sn.exe
Now, just like if we were running the strong name utility from the command line, we're going to need to pass in the correct arguments. Firstly we'll need to pass the -Tp argument, as we want to get the token for the public key, together with the public key itself. Then we need to specify the target assembly, which can be done by clicking on the button to the right of the Arguments field and selecting 'Target Path'. This basically gets the full qualified path to item which is being built, in our case a webpart assembly. Lastly just tick the 'Use Output Window' checkbox and then click ok and you're good to go :)
The new utility you've just created should now show up in the Tools menu, you can go ahead and click it and you should now see the output window popup with the details of the public key. This is a really nice feature of Visual Studio and I'm sure this can be tailored for many other uses.
"Where are my alert emails!" I hear you cry. I've been repeating these same words for a number of days now and I've finally managed to get them working so I thought I'd share my solution.
I've been working with a MOSS site which has three environments; development, staging and live. We have a number of custom workflows which were created using Workflow Foundation and InfoPath for the forms. Each of the workflow tasks should automatically send out a task notification email whenever the task is reassigned to a different person. This has always worked fine on staging and live environments, but I've never seen them working in the development environment. Interestingly all the standard scheduled alert emails were working fine (ie. if you were to subscribe to a list), it was just the task notifications from the workflows which were not.
First thing I did was go through the usual process of checking the log files and windows event viewer for errors which yielded no significant results. Next thing I checked were the email settings for the site in Central Admin which again all looked fine. The development site is using local SMTP, so I checked if the emails were getting generated in the 'DROP' folder in the mailroot. The scheduled alert emails were getting generated in here fine, but the task notifications were not. I also checked that the Timer service was running correctly and under the right account in the windows Services, which it was.
Next thing I checked were the database tables, after I read about the same problem in this newsgroup posting. The following four tables in the content database contain entries related to the alert emails:
ImmedSubscriptions (Stores the alerts for emails that are sent immediately when changes occur)
SchedSubscriptions (Stores daily or weekly scheduled alerts)
EventLog (This table contains events for which only non-immediate alerts exist)
EventCache (This table contains a list of site events for which users have requested alerts. WSS inserts events into this table as they occur)
I checked in these table to see if information about the alerts were being inserted and discovered that in the ImmedSubscriptions and EventLog tables there were actually entries which were related to the live server, as I believe the content database had been restored from a live copy a while ago, and the references obviously had not been updated automatically. So I cleared out each each one of these tables and re-tested the workflow. This made a bit of progress as I could now see that the alert information was getting inserted correctly into the EventCache and EventLog tables. However the ImmedSubscriptions table was still not receiving information about the alert.
After some frustrated iisresets and restarts of the timer job service, I was still having no luck whatsoever at getting these alert emails working so I reverted back to trusty Google for some more answers. I found this blog, which although not directly related, provided the winning answer. Updating the alert templates. After running the following stsadm command on the development machine, the task notification alert emails automagically started working again woohoo!
stsadm -o updatealerttemplates -url http://testserver -f "c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\alerttemplates.xml" -LCID 2057
So I can assume that the problem transpired from a restore of the content databased from a different server which somewhere along the line maintained some references to the original server. A clear out of the relevant databases and re-registering the alert templates seemed to solve the problem for me.
Hopefully this comes in handy for somebody else, as I spent many a frustrated hour over this one :)
This is the first post to my newly created weblog hosted at www.asp.net (many thanks to Joe Stagner for setting this up for me), which I'm migrating from my existing site www.multividea.com. So I'll start with an introduction; I'm Mel, I've been working with various Microsoft web technologies over the years including classic ASP, ASP.NET and have most recently started working with Sharepoint 2007 and Windows Sharepoint Services. I mostly make posts to share problems and solutions I encounter whilst working on projects for my current employer.
I also recently got inspired to start getting stuck in with some SilverLight 1.0 after attending Microsoft Mix: UK 07 and listening to various seminars by Scott Guthrie, so this is also something I would like to start blogging about regularly as I get further into it.
So thanks for reading, hopefully you will find this site a valuable resource and I'm happy to answer any comments on the upcoming posts.