dotnet o rama

Until now, I used to debug SharePoint feature activation by using the Attach Debugger feature to launch the debugger from inside the IIS worker process my SharePoint site was using.  After some tinkering, I was able to determine that you can also debug by configuring your SharePoint feature product to start STSADM.EXE and supply the command line options to activate the feature.

See this screenshot for details:

If you don't already know the location of STSADM.EXE, it is located at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.EXE.

Once your project is configured, you can set a breakpoint in the FeatureActivated method of your feature receiver and debug the project.

In a past project, I needed to be able to create an audience in MOSS that would apply only to anonymous users in an SharePoint site configured to use forms-based authentication.  Additionally, anonymous users could not access a page in SharePoint if the page contained a web part that was configured with an audience.

I noticed that the RuntimeFilter tag in the web.config file referenced the AudienceManager class: 

<RuntimeFilter Assembly="Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Class="Microsoft.Office.Server.Audience.AudienceManager" BuilderURL="audience_chooser.aspx" />

Using Reflector, I was able to determine that this class was responsible for both supplying the audience controls in the tool part window and for determining whether or not the user was in the audience configured for the web part. 

Normally, these controls are displayed when a web part is edited:

But after writing a wrapper for the AudienceManager class, I was able to add an additional checkbox to allow the user to specify that only anonymous users should see the webpart:

Now, when the user checks the check box, only anonymous users will see the web part.  I also made an additional change to workaround the problem of anonymous users not being able to see pages that had web parts configured with audiences.

To implement the same functionality, you will need two classes:  one that implements the Microsoft.SharePoint.WebPartPages.IRuntimeFilter2 interface and one that implements the Microsoft.SharePoint.WebPartPages.IToolPaneControl interface.  The IRuntimeFilter2 interface is used to determine if the current user is in a particular audience when the web page is rendering and the class you create will need to be configured in the RuntimeFilter tag in the web.config file.  The IToolPaneControl interface is used to display the audience control in the tool pane when the web part is edited.

You can download the code I used here.

You may get the following exception when calling SharePoint web services:

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> Attempted to perform an unauthorized operation.

In my case, the problem was that the URL I used did not map to a site collection in SharePoint since I had previously deleted that site collection and forgot to recreate it.  Once I recreated the site collection, the error went away.

If you get this error message in SharePoint Designer when you are detaching a page from its page layout, reopen the site using the original public URL for the zone you configured for Windows Auth.  If you don't know the URL, open Central Administration, click the Operations tab, and click the Alternate Access Mappings link.  Then, select the web application from the Alternate Access Mapping Collection dropdown.  The URL you need to use will be in the Public URL for Zone column.

If you have data connections that are unused on the view you are displaying, be aware that the data returned by the data connections is still transfered from the server to the browser during post backs. This will cause any business logic or custom code to be slow since so much data is returned after the code on the server runs.

File attachments in InfoPath browser-based forms will not work unless the form tag of the master page is modified to include the encoding type. Ex: <form enctype="multipart/form-data" .... >

If you try to view a saved form using a different alternate access path than the one used to save it, you will get an error message. The problem stems from the fact that the saved form XML has a fully-qualified, hard-coded path to the site collection where it was saved and it is not being translated to another other alternate access path.

If you promote a new property in a form that has already been published, it will not update the form's content type until you deactivate and reactivate it to the site collection where it is deployed.

If you display a view in the XmlFormView web part that does not reference ALL of the secondary data connections, it will cause an exception inside Form Server when the form posts back to the server. To workaround this, modify your main data source to include a group named "Workarounds" and under the group, create one element for each secondary data connection. Next, right-click the "Workarounds" group and select "Section with Controls". Modify the properties of the section and uncheck the display checkbox to make it invisible in production. Afterwards, right-click each textbox in the section and convert it to a drop down list. Finally, bind each drop down list to its matching secondary data connection. These steps only need to be done of the first view. Subsequent views can be updated by copying and pasting the entire section into each view.

Having spent a *lot* of time troubleshooting the implementation of Form Server without much help from others, I have compiled a list of the errors I ran into along with the causes and fixes I used to resolve them.  The MOST important thing to do when using InfoPath Form Server is to mentally or literally track your steps carefully so that when you run into one of these vague errors, you will be able to retrace your steps.  Otherwise, you could easily spend a day trying to figure out why something broke.

Here is my list.  If you want me to include your additions, let me know.

As you may know, sometimes cut and paste stops working between the host OS and the guest OS in a Virtual PC.  If you don't already know, this functionality is actually provided by the Virtual Machine Additions, specifically the Virtual Machine Additions Services Application windows service.  So the next time the clipboard stops working, try restarting this windows service and it should start working again.  If not, you may have a program on the host OS or the guest OS that is keeping the keyboard locked.  A simple test for this is to copy and paste between programs in the host OS and between programs in the guest OS.  If one of these tests fails, you may have to close programs on that OS or reboot it.

Last April, I blogged about using a detour library to prevent Visual Studio from locking files.  Visual Studio 2003 and 2005 tend to lock files when the size any of the compiled projects in a solution get too big or when the number of projects in a solution gets over 10.  In the former case, you could see problems when the assemblies grew over 64K in size.  In the latter case, the chance of the problem occurring increased with the number of projects in the solution and the number of interdependencies between the projects themselves.  However, with my hack, I was able to have a solution with over 20 projects (mostly C# class libraries) and virtually unlimited assembly size.  The size of our assemblies was due to localization of the application for 7 languages not including English.  Since that original post, several people have requested the code so here it is.  This code is NOT supported by anyone so use it at your own risk.

The code I added is in the detours\samples\fakecreatefile folder.  The OpenVisualStudio.bat file calls one of the detours utilities which loads devenv.exe into memory and rewrites the calls to the CreateFile Win32 functions to call my functions instead.  My functions are in the fakecreatefile.cpp file.

Download the zipped code including old version of detours library from here.

If you create an audience whose rules are based on user profile properties, make sure that those properties don't have their Default Privacy Setting set to "Only Me".  Otherwise, the audience compiler will not "see" the values for those properties.  Unfortunately, the audience editor allows you to create properties on private properties without giving you any warning.  :-(

I have found that Vista seems to be able to run older games that XP would not.  This includes older adventure games that were targeted at Win 95/98.  There are two important hurdles to overcome when running these games:  getting the game to load without errors and keeping the game in the foreground when the game reduces the screen resolution.

To get the game to load without errors, try these steps:

1. To be able to save your save, you will mostly likely need to either run the game using "Run as Administrator" or add your account to the NTFS permissions for the installation folder and all subfolders and files.
2. Changing the compatibility level of the game's exe to an operating system supported by the game.

Once you are able to get the game to load and you can see some video, you may be dumped to the desktop with the game still running.  The problem is that programs like Windows Sidebar that appear always on top interfer with the game.  So if you have this problem, close Windows Sidebar and other applications like it and try again. (I had to close XBoxStat.exe, the resident program for the XBox 360 Controller driver, since it also interfers with the game.)

One caveat is that for games that are purely DOS based, I always use DOSBox which emulates DOS and is still fast enough to provide a good gaming experience.

These are some games that I have been able to load even with the UAC enabled:

• All Nancy Drew games
• Most Sierra adventure games

I plan on keeping this list up to date so if you have any additions, let me know.

If you have the UAC enabled in Vista, MSI packages may fail if they require administrative priviledges to install correctly.  If you run into this situation, you can work around this by running the command line console (cmd.exe) as administrator and installing the MSI from the command line.  Since the command line is running with administrative priviledges, any process it starts will also run with administrative priviledges.

If you are thinking of using InfoPath Form Services for a project, read this post before you make the jump.  I have had many problems of the problems that Rob addresses in his blog post.  In future posts, I will share some of the workarounds and hacks I have used to tame many of the problems with InfoPath's browser-based forms.

You may get this error when trying to activate an uploaded InfoPath form to a site collection.  I was able to fix the problem by deactivating and re-activating the "Office SharePoint Server Enterprise" features at the site collection and site levels.

If you get this message and you edited your SharePoint server's WSS.ACTIONS file to add custom activities to SharePoint, then you put invalid XML in the WSS.ACTIONS file.  This happened to me when I edited the file in Notepad and caused the XML to be invalid because of some missing whitespace.  If you can't edit the file in a real XML editor, you can still use Internet Explorer to open the XML and make sure that the XML is valid before you do any testing.  In order to do this, make a copy of the file and give it the .xml file extension.  Otherwise, Internet Explorer won't know what to do with it.

If you upload a large application definition file (ADF) to the Microsoft Office SharePoint Server 2007 (MOSS) Business Data Catalog, you may get this error message:

Parameter '@Value' exceeds the size limit for the sql_variant datatype.

This error occurs when one of the elements in the ADF file exceeds SQL Server's limit of 8,000 bytes.  The error message will give you a line number and position which you can use to determine which element is too large.

I used to have a problem with Visual Studio locking files.  Apparently, the IDE would lock the assemblies compiled by your solution under various circumstances including:

• Too many projects in a single solution.
• Assemblies larger than 64K (which the Intellisense engine locks forcing you to restart the IDE).
• Creating a Visual Studio Add-In or Visual Studio Integration Partner (VSIP) Package.
• Deploying files to the PrivateAssemblies folder in order to debug them in the context of Visual Studio (in this case you start an instance of Visual Studio to debug another instance of Visual Studio that loads your assembly)

Whatever the case, the problem is annoying.  After dealing with the problem for a couple of months, I got fed up and started looking for a way to permanently fix the problem.  That lead me back to the Detours project at http://research.microsoft.com .  I had encountered the Detours library before when I was trying to learn some of the unusual features of unmanaged C++ code.  The idea of Detours is to provide a mechanism to safely and simply intercept standard library calls to an API.  In other words, it allows you to shim any Win32 API function that is called using DllImport (including using the DllImport attribute in a managed .Net assembly).  When you intercept such a call, you have the ability to pass the call to the API without modification, modify the parameters and pass the call to the API, call the API and modify the return results, or completely replace the functionality with your own.  The name of this technique is named "trampoline".

In order for me to exploit this functionality in Visual Studio, I would need to determine which Win32 function is used to open files.  As I was already familiar with the Win32 API, I knew that I needed to intercept the CreateFile function which is actually implemented as CreateFileA (ANSI) and CreateFileW (Unicode).  I also knew that I needed to change the Share Mode parameter to allow other processes and threads to overwrite the file.  I chose to change the parameter to FILE_SHARE_DELETE which allows anybody to do anything to the file including delete it. 

Once I had my trampoline compiled into a DLL, I used the Detours sample application withdll.exe to start the Visual Studio IDE, load my DLL into its memory space and patch in memory the IDE's calls to CreateFile.  The end result is that it worked and I never had another file locking problem again. 

Note:  There was one small side effect of doing this.  The IDE "appeared" to speed up overall which I could hardly complain about.

In CodeSmith templates and any other .Net assembly, you can programmatically set a breakpoint by adding Debugger.Break() to your code.  If you already have a debugger attached, the debugger will stop at your breakpoint.  Otherwise, you will get the JIT debugger dialog asking which debugger to attach to your process.

However on Vista, you will get this message instead:

"SomeProcess.exe has encountered a user-defined breakpoint."

If you wait for the dialog to finish, you will be able to click the Debug button to display the JIT debugger dialog.  Unfortunately, once you have stopped debugging, CodeSmith Studio will hang and must be terminated using Task Manager.

However, there is a registry value named DbgJITDebugLaunchSetting with a default value of 16 that will fix the problem when you change it to 2.  This registry setting is located at [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework].

Once set, the JIT debugger dialog will be displayed immediately when your code hits a breakpoint.

If you get this error, one of three things could be the culprit:

1. You don't have permissions to create the key.
2. The parent key is considered volatile by the operating system.
3. A process has the parent key locked.  (The same way processes can lock files.)

To troubleshoot your problem, check the permissions of the parent key by right-clicking it and selecting Properties.  Click the Effective Permissions tab and use the Select button to choose the account with the problem.  It will then display the effective permissions for the account which you should examine for anything conflicting with creating a key.  Basically, see if any deny checkboxes are checked or any allow checkboxes are unchecked.

You can check for problem #2 by looking at the registry section of the Windows Server 2003 documentation which lists information about keys and their volatility.  If the key is volatile, you simply won't be able to modify it.

To check for problem #3, download Process Explorer from www.sysinternals.com and use the Find Handle functionality to search for part of the name key that you are trying to modify.  If it returns any results, close the program locking the key if you can.  If you cannot close the program, you can *try* closing the program's handle to the key which will release the lock, but beware.  Forcing handles closed on core system processes *WILL* cause a BSOD so make sure you save any unfinished work before attempting this.

In my case, I had the MDAC Component Checker open when I tried to modify one of the ADO keys and the problem went away when I closed it.

If you double-click a solution file (.sln) in Vista, nothing happens.  The reason is that the vslauncher.exe (Visual Studio Selector program) requires administrative privileges to run.  Even if you check the box for "Run as Administrator" on the compatibility tab of the vslauncher's property page, nothing happens.  Even if you proceed to edit the vslauncher's manifest file, nothing happens.  So if you just use Visual Studio 2005 or don't mind opening old projects using File->Open, you can fix this problem by following these steps:

1.  Navigate to the devenv.exe executable, right-click it and select properties.  (The executable file is usually located in the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE folder.)

2.  Click the compatibility tab and check the "Run as Administrator" box.  Click OK to close the dialog.

3.  Open the Registry Editor (regedit.exe) and navigate to the HKEY_CLASSES_ROOT\VisualStudio.Launcher.sln\Shell\Open\Command key.

4.  Change the value for (default) from

"C:\Program Files\Common Files\Microsoft Shared\MSEnv\VSLauncher.exe" "%1"

to

"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe" "%1"

You can follow these steps other Visual Studio files (projects, etc...) by finding the correct key.  First, look for a key under HKEY_CLASSES_ROOT named .fileext where fileext is the file extension (vcproj or vbproj for example).  Click on the child subkey named OpenWithProgids and make a note of the name of the only non-default value there.  With that value name, look up the key with the same name under HKEY_CLASSES_ROOT.  Generally speaking, the naming convention follows the format of VisualStudio.fileext.8.0 or VisualStudio.Launcher.fileext where fileext is the file extension.

"The process cannot access the file because it is being used by another process."

If you get this error using gacutil to remove an assembly from the GAC, make sure you run cmd.exe as administrator beforehand.  Otherwise, you will get this cryptic error.