Archive for category .Net
Another issue when displaying the dialog was that the page that I was displaying contained all the elements of the master page that typical pages display (header, footer, etc). This made the dialog too busy for the simple task it was asked to do. To fix this, I added the MasterPageFile attribute to the Page directive which overrides DynamicMasterPageFile attribute.
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="AnnouncementPage.aspx.cs" Inherits="MyPages.WebParts.Layouts.AnnouncementPage" DynamicMasterPageFile="~masterurl/custom.master" MasterPageFile="~/_layouts/applicationv4.master" %>
In the end, a uncluttered summary list and detailed model dialog:
Code that made it happen:
Within a workflow that I was developing, there was a requirement to notify a group of SharePoint users that a lookup service had failed. This particular activity was within a parallel activity sequence. I chose to use the SendEmail activity to notify the users, but incorrectly set the Correlation Token to a new value. When testing this functionality in the workflow I received an error:
The correct Correlation Token for a SendMail Activity is the “Workflow” token. The reason, which is fairly obvious, is that the SendEmail activity maps to the workflow, not to a task, which would require a Task Token.
Three blogs in One: 1. How to get the PublicKeyToken of your assembly. 2. Where are the .Net utilities for VS 2008 SP1 / Windows Server 2008? and 3. Fixing the WinSDK Configuration Tool
As I was building a custom SharePoint feature in a newly built VM image (consisting of Win Server 2008, MOSS 2007, VS 2008 SP1), I tried to access the PublicKeyToken of an assembly I had just built in order to update the Manifest file of the solution. I typically use the Strong Name tool (SN.EXE ) with the –T (notice the capital T for an assembly) option to display that publickeytoken for the assembly. Generally, the .net utilities are located in the .Net Framework path. But, when I checked that path, there were no files at all.
Little did I know where that small task would lead me…
Initial research suggested installing the Windows SDK for Windows Server 2008 and .NET Framework 3.5, which I did install. It took a little bit of searching on the file system to find the SDK tools, but I found it under C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin. Great, I’ll just run my strong name tool and all will be well. But, when I looked at the new path, I noticed there were two versions: v6.0A and v6.1. Curious about the difference between the two, I looked at the original SDK download page closer and noticed that I had overlooked an important comment on the download page ”Installing the newly released Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1 instead of this release is recommended. If you do go ahead and install this SDK after VS2008 SP1, please ensure the patch described in Knowledge Base 974479 is applied. See Overview section for more information.”
As it turned out, the introduction of the bug really occurred when I installed Visual Studio 2008 Service Pack 1. By installing the Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1, this fixed the problem with the SDK Configuration Tool (which I set to 7.0) and I could now run the sn –T assembly.dll. By the way, the location of the SDK .Net utilities after the correct SDK installation is under C:\Program Files\Microsoft SDKs\Windows\v7.0\bin