Dirty Words

Exposing the Global Assembly Cache

2010-09-08T17:35:00.000+08:00

If you're familiar with the Global Assembly Cache (GAC) you're probably aware there's a special file system viewer thingy (technical term) sitting over top of the GAC contents at c:\windows\assembly; this is a nice convenience when it comes to registering assemblies in the GAC—simply drag and drop, avoiding a trip to the command line and gacutil –i

More often than not, this is all good. When you need to dive into the real GAC, to extract an assembly, drop in debugging symbols, or whatever, you'll quickly realise the viewer is somewhat limiting.

To get past the GAC's outer facade, you've got a few options:

From a command line, browse to c:\windows\assembly\gac_msil
Map a network drive to \\machine-name\c$\windows\assembly\gac_msil
Create a virtual drive: subst z: c:\windows\assembly\gac_msil where 'z:' is any unmapped drive letter
Start –> Run c:\windows\assembly\gac_msil
Turn off the viewer altogether to browse the GAC directory structure normally within Windows Explorer: create a new DWORD named DisableCacheViewer with a value of 1 below the HKLM\Software\Microsoft\Fusion key

Five ways to do the same thing? Well this is Windows after all—and there are probably more!!! ;)

If you drop the gac_msil bit you'll find there are other directories that make up the GAC proper to explorer but most of what you'll be after resides below gac_msil. Each assembly is represented in by name as a folder with different versions represented as sub folders named as the version number with a GUID appended; the assembly proper will live in one of these folders.

If you found this post helpful, please support my advertisers.

Changing a VS2010 SharePoint package name

2010-09-08T17:12:00.000+08:00

The SharePoint development tooling built into Visual Studio 2010 does a pretty good job at hiding some of the ugly bits involved in creating a SharePoint solution file. No longer must we deal with ddf files (hooray!) but we also lose some control (or, at the very least, have to dig a bit further to change some things that were previously "easy" in the broader context of "really painful").

One of those things that we previously had full control over was the name of the solution file (.wsp) that results from our ddf file and the mighty makecab.exe. While the file name is now set from within Visual Studio, you have to open the package designer before being presented with the package properties:

Simply clicking on the Package.package file will present you with the file properties which is not what you want—you have to double-click/open the package designer.

The one thing I used to do with the ol' ddf file was specify the extension as .cab instead of .wsp. This was a convenience thing—SharePoint doesn't care about the extension (or at least doesn't object to .cab files)—but a .cab file will open in Windows Explorer on machines where you don't have a better archive tool installed like my favourite, 7zip. Essentially, it just saved me having to rename the file by hand.

Unfortunately I have yet to find a way to do this with VS2010; the package name is only that—Visual Studio appends ".wsp" to the end of whatever name you supply and I can't find a way to override that behaviour. In truth I'll probably just start using .wsp like everyone else but it may be possible to tweak the file name in one of the pre/post events.

If you found this post helpful, please support my advertisers.

.NET 4.0 application compatibility

2010-09-06T16:51:00.000+08:00

Looks like those of us running SharePoint may be stuck on .NET 3.5 SP1 for a while longer but that's no excuse not to have .NET 4.0 installed side-by-side for use by other apps. One of the guys on the team, for instance, recently updated the custom crawler we run and needed pull in some of the Entity Framework features only made available in the 4.0 release; of course Microsoft will tell you the various .NET runtimes can be installed to run side-by-side and we managed to get away with a lot during the whole 2.0/3.0/3.5 onion thing.

Of course this all gets interesting very quickly when you've got a console application built against 4.0 that references assemblies (i.e. the SharePoint assemblies) built against version 2.0. Naturally everything worked fine in dev but as soon as we hit UAT, this exception cropped up:

An error has occured: Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information. [sic]

To address this, a simple .config element was added:

<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>
…

Notably, the useLegacyV2RuntimeActivationPolicy="true" attribute was required and we found this out the hard way by not having in place initially (dodgy internet code most likely!).

If you found this post helpful, please support my advertisers.

Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM', component '{1C12B6E6-898C-4D58-9774-AAAFBDFE273C}' failed

2010-09-03T18:19:00.001+08:00

After sorting out a problem with the FIM Service not starting automatically after a reboot and several resultant application event log errors, there was one more thing to clean up: running a user profile sync would spit a couple of MsiInstaller warnings about product detection failing (see below).

Various users in the forums suggested granting the Network Service account read access to the C:\Program Files\Microsoft Office Servers\14.0\Service directory and/or the C:\Program Files\Microsoft Office Servers\14.0\Sql directory; I initially found only the latter was required (this directory currently has Read & execute, List folder contents, and Read) but on reboot, the same warnings were logged again. Granting the same access to \Services had the same result and I've found starting a crawl produces these warnings but they go away with subsequent crawls. Reboot and they're back :-(

This change relates to the following warnings logged as a crawl is initialised:

Log Name:      Application
Source:        MsiInstaller
Date:          2/09/2010 3:40:24 PM
Event ID:      1004
Task Category: None
Level:         Warning
Keywords:      Classic
User:          NETWORK SERVICE
Computer:      dev-sps2010-01.dev.mediawhole.com
Description:
Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM', component '{1C12B6E6-898C-4D58-9774-AAAFBDFE273C}' failed. The resource 'C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe' does not exist.

Log Name:      Application
Source:        MsiInstaller
Date:          2/09/2010 3:40:24 PM
Event ID:      1001
Task Category: None
Level:         Warning
Keywords:      Classic
User:          NETWORK SERVICE
Computer:      dev-sps2010-01.dev.mediawhole.com
Description:
Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM' failed during request for component '{9AE4D8E0-D3F6-47A8-8FAE-38496FE32FF5}'

Log Name:      Application
Source:        MsiInstaller
Date:          2/09/2010 3:40:24 PM
Event ID:      1015
Task Category: None
Level:         Warning
Keywords:      Classic
User:          NETWORK SERVICE
Computer:      dev-sps2010-01.dev.mediawhole.com
Description:
Failed to connect to server. Error: 0x80070005

If you found this post helpful, please support my advertisers.

Forefront Identity Manager Service fails to start after reboot

2010-09-03T15:05:00.001+08:00

After following Spence Harbar's Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization, I was able to not only get the UPS service started but I was also able to run a sync on my first attempt. I probably got lucky ;-)

The one small hiccup I had along the way was getting the Forefront Identity Manager Service to start following a reboot; the service simply refused to start automatically despite being configured by SharePoint/FIM to do so. Interestingly, both the User Profile Service and the User Profile Synchronization Service items listed in Central Admin's Services on Server page listed the services as running. Starting the FIM Service manually from the Windows Services snapin succeeded (I didn't try directly through CA) but felt hacky and annoying.

What to do? Since the Synchronization Service was starting successfully and I could manually start the service after logging in, I assume this has to be some kind of dependency issue between the services themselves or SQL Server (some of the event log error message listed below definitely take issue with SQL).

My solution was to therefore set both services to start automatically at boot time after a delay by reconfiguring the startup type of BOTH services and Automatic (Delayed Start) in the Windows Services snapin:

Interestingly, I found the FIM Service starts before the FIM Sync Service, fwiw. I also still have one error remaining stating The Forefront Identity Manager Service cannot connect to the SQL Database Server but it doesn't prevent the services from starting or a sync from running.

So is this an inappropriate change to make? I can't say, especially with everyone and their dog saying "let SharePoint manage these services, don't start 'em manually!" I know for certain both services now start automatically after a minute or so (once all other services set to just Automatic have started) and I can still run a profile sync; the following errors are also no longer present:

Log Name:      Application
Source:        Forefront Identity Manager
Date:          3/09/2010 12:37:17 PM
Event ID:      3
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      dev-sps2010-01.dev.mediawhole.com
Description:
.Net SqlClient Data Provider: System.Data.SqlClient.SqlException: Cannot open database "Sync DB" requested by the login. The login failed.
Login failed for user 'DEV\SVC_SPFARM'.
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at System.Data.SqlClient.SqlInternalConnectionTds.CompleteLogin(Boolean enlistOK)
   at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject)
   at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart)
   at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
   at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
   at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
   at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options)
   at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject)
   at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)
   at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
   at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
   at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
   at System.Data.SqlClient.SqlConnection.Open()
   at Microsoft.ResourceManagement.Data.DatabaseConnection.Open(SqlConnection connection)

Log Name:      Application
Source:        Microsoft.ResourceManagement.ServiceHealthSource
Date:          3/09/2010 12:37:17 PM
Event ID:      26
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      dev-sps2010-01.dev.mediawhole.com
Description:
The Forefront Identity Manager Service was not able to initialize a timer necessary for supporting the execution of workflows.

Upon startup, the Forefront Identity Manager Service must initialize and set a timer to support workflow execution. If this timer fails to get created, workflows will not run successfully and there is no recovery other than to stop and start the Forefront Identity Manager Service.

Restart the Forefront Identity Manager Service.

Log Name:      Application
Source:        Microsoft.ResourceManagement.ServiceHealthSource
Date:          3/09/2010 12:37:17 PM
Event ID:      2
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      dev-sps2010-01.dev.mediawhole.com
Description:
The Forefront Identity Manager Service could not bind to its endpoints. This failure prevents clients from communicating with the Web services.

A most likely cause for the failure is another service, possibly another instance of Forefront Identity Manager Service, has already bound to the endpoint. Another, less likely cause, is that the account under which the service runs does not have permission to bind to endpoints.

Ensure that no other processes have bound to that endpoint and that the service account has permission to bind endpoints. Further, check the application configuration file to ensure the Forefront Identity Manager Service is binding to the correct endpoints.

Log Name:      Application
Source:        Microsoft Resource Management Service
Date:          3/09/2010 12:37:17 PM
Event ID:      0
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      dev-sps2010-01.dev.mediawhole.com
Description:
Service cannot be started. System.Data.SqlClient.SqlException: Cannot open database "Sync DB" requested by the login. The login failed.
Login failed for user 'DEV\SVC_SPFARM'.
   at Microsoft.ResourceManagement.WindowsHostService.OnStart(String[] args)
   at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)

If you found this post helpful, please support my advertisers.

Troubleshooting user profile sync via FIM

2010-09-03T14:38:00.001+08:00

Your initial foray into SharePoint 2010 user profile sync will likely lead you to the FIM client and, if you're anything like me, your mind will boggle at what FIM is, why it has to be involved at all, and where to start when things to horribly wrong.

I won't attempt to enlighten you on the first two subjects but I do want to point out some interesting and non-intuitive FIM user interface screens you may not be aware of and that will help you determine if your UPS setup is on the right path. By the way, you can run the FIM client as soon as the two FIM services are running on your machine (in other words, as soon as UPS has been provisioned but before you run a sync).

If you've got the UPS service in a running state, the next thing you'll likely want to do is run your first (or 50th) sync; in addition to the dodgy status screen within Central Admin itself, you can fire up the FIM client to watch from the bushes (the Operations view) as SharePoint, FIM, SQL Server, and AD do their magic dance. A successful run includes ten operations in my dev environment and I've previously posted a screen shot of this if you're interested.

If you look carefully, the operations view will reveal the user name involved with each operation and list some partition info as well. To dive in deeper, click the Management Agents button in the top menu; in my case, I'm presented with three MAs (if you've got more because you've been struggling with connections, you may be in trouble):

The first MA named ILMMA connects to the database I specified when setting up UPS ("Sync DB")
The second MA named MOSS-{GUID} connects to the ProfileImportExportService web service
The final MA named MOSSAD-{name of my connection as configured in CA} connects to Active Directory

By viewing the properties for each MA (right-click on an MA and select Properties from the context menu or use the Actions pane to the right of the window) I can also examine specific properties to determine exactly what domain name FIM is configured to use and the accounts used to interact with AD, SQL Server, and the web service:

The attentive reader will note there's a lot of farm account action going on here and that's because both FIM services are configured to log on as the farm account and my understanding is they have to be because of the way the relevant timer job(s), which are also run as the farm account, interact with these services (says Spence). I'll also point out my svc_spups account is the account to which I've granted Replicating Directory Changes in AD.

If you found this post helpful, please support my advertisers.

Testing database connectivity

2010-09-02T15:24:00.001+08:00

Developer that I am, I've gone so far as to write throwaway console apps to test connectivity to a database server as a different user; hopefully I'll never have to do that again after learning about this really cool trick:

Create a new text file and change the extension to .udl
Double-click it
Select a provider, configure the options to connect and hit Test Connection (note the Use a specific user name and password option means SQL authentication; entering an AD account here will fail).
Start a console window as another user and execute the .udl file to connect as someone else using integrated security if necessary
Having ruled a security issue in or out, fix the problem!

A massive shout out to Todd Klindt for sharing this in one of his recent netcasts!!!

Ps. "OK" through to persist the connection details in the form of a connection string to your text file. Kinda helpful!

If you found this post helpful, please support my advertisers.

miisclient.exe success output

2010-09-02T14:18:00.001+08:00

Partly for the glory but more for posterity (my own future reference!), I've screen captured what a successful SharePoint 2010 AD user profile synchronisation looks like in the FIM client:

Will this gain me entry to a special club or something? If so, thanks Spence! Now to work through all the event log errors and warnings… perhaps I ought to call it a day!

If you found this post helpful, please support my advertisers.

Where to find the FIM Client (miisclient.exe)

2010-09-01T15:48:00.001+08:00

Note to self and anyone else who cares… you'll find the FIM client (aka miisclient) at the following location:

C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe

Use it to debug SharePoint 2010 user profile synchronisation.

Moving files in Visual Studio and the SharePointProjectItem.spdata file

2010-08-29T21:14:00.001+08:00

While mucking around the CKS:Development Tools Edition Visual Studio 2010 extension for SharePoint, I inadvertently created a new master page from the Starter Master Page (CKSDev) template in an existing VS module:

Neither VS nor SharePoint seemed to object to this arrangement—likely because the module in question was otherwise empty—but, as an experiment, I decided to move the CKS:Dev master page SPI into the project (and the top-level MasterPages module) nonetheless, making the nested CKS:Dev container obsolete.

This wasn't a good idea because subsequent attempts to build the package failed with the error "Could not find the file 'c:\…PageLayouts\StarterMasterPage1.master". Omg, what to do and why is trying to find these files in the project root?! I briefly pined for the good ol' .ddf file from 2007 days and then slapped some sense back into myself.

To begin fixing the problem, I first had to click the Show All Files button in the Solution Explorer window to reveal the SharePointProjectItem.spdata file in the root-level module (note the CKS:Dev inner master page module has its own .spdata file, which is empty after the move):

This is an XML file and its structure is quite basic; I'd describe it as a mini project file for the module in question as it lists the source files in the module along with their targets, and types.

Interestingly, the Source values specified all started with "..\" but inspecting a similar file from an un-modified module simply listed each file names; I assume Visual Studio helped out during the move to add this additional path information.

Removing the "..\" prefix fixed the problem and suggested to me the SharePoingProjectItem.spdata file may prove fragile during project refactoring. Sure enough, moving the files back to their original home added a spurious MasterPages\ prefix to each file and wreaked havoc all over again.

Moral of the story: manually edit the SharePointProjectItem.data file as required but beware Visual Studio may "fix" any of your changes.

One other thing to note: when I moved my files around, Visual Studio reset the properties on some of them. Most notably, Elements.xml file reverted to a Deployment Type of ElementFile instead of ElementManifest and the Build Action was set to Content. Modifying these properties also added the parent directory prefixes back to my .spdata file. Perhaps removing files from one location and adding them them back through the Add –> Existing Item… dialog is a safer way to approach this long-term if VS is going to continue meddling with things.

And just to add to the joy, one final bit of fun: a page layout added to the module in question was deploying fine; for the sake of producing the screenshot above, I excluded it from the solution, which also removed it from the files listed below the MasterPages module in the visual feature designer. While I assumed the feature designer would automatically update itself when I added the layout back to the module, I was wrong: the designer refused to update to reflect the inclusion of the page layout until I restarted Visual Studio! If this is a VS 2010 bug, it'll be one of several I've already filed with MS! Viva SP1!!!

If you found this post helpful, please support my advertisers.

Setting the Visible property on a webpart throws

2010-08-19T16:55:00.001+08:00

Using myWebPart.Visible = false and getting this?

The Visible property cannot be set on Web Part 'your_web_part'. It can only be set on a standalone Web Part.

Use myWebPart.Hidden = true instead.

If you found this post helpful, please support my advertisers:

Must Have Windows Server 2008 R2 Hyper-V Hotfixes

2010-08-18T11:08:00.001+08:00

Now there's a damning blog post title!

In brief, I've had a few issues since installing Windows Server 2008 R2 and adding the Hyper-V Role on my Dell Precision M6500 Core i7 laptop (if you've landed on this post and you don't care about laptops--i.e. you're an admin--don't stop reading now as this post will likely apply to you too). This post is meant to be a running log of problems and their resolutions while we await the next service pack, I suppose.

Problem #1: Blue Screen of Death/random reboots

Resolution:

Install the http://support.microsoft.com/kb/975530 hotfix on your Hyper-V hosts or use the work around detailed in the KB article.

KB975530: Stop error message on a Windows Server 2008 R2-based computer that has the Hyper-V role installed and that uses one or more Intel CPUs that are code-named Nehalem: "0x00000101 - CLOCK_WATCHDOG_TIMEOUT"

Symptoms, event log entries, and whatnot: Unexpected freezes, BSODs and reboots during periods of high network activity.

Event ID 219, The driver \Driver\WUDFRd failed to load for the device USB\VID_0A5C&PID_5800&MI_01\7&66de6c9&0&0001.
Event ID 41, The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.
Event ID 4, Broadcom NetXtreme 57xx Gigabit Controller: The network link is down. Check to make sure the network cable is properly connected.
Event ID 1001, The computer has rebooted from a bugcheck. The bugcheck was: 0x00000101 (0x0000000000000019, 0x0000000000000000, 0xfffff880020ce180, 0x0000000000000003). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 043010-31168-01.

Apparently this issue is caused by an Intel erratum affecting Nehalem-based processors (i.e. Xeon 5500, Core i7-800, and Core i5-700 series).

Problem #2: Guest VMs freeze, lost connection

Resolution:

Install the http://support.microsoft.com/kb/974909 hotfix
Install the http://support.microsoft.com/kb/981836 hotfix (this KB is specific about Windows Server 2003 but a Microsoft representative suggested it's applicable to all VMs as the hotfix updates the integration services components generally)
Update integration services on all guest VMs

None of this worked for me but changing my host power settings from Balanced to High performance did. In theory you should be able to revert to Balanced after installing and the above.

You may also want to investigate turning off TCP offloading.

Symptoms, event log entries, and whatnot: Hyper-V console freezes in some virtual machines but not others (the only one affected in my case was an XP VM upgraded from Virtual PC 2007 SP1), Hyper-V manager reports the Heartbeat as "Lost connection".

Event ID 5: The miniport 'Microsoft Virtual Machine Bus Network Adapter #3' hung.

...followed by...

Event ID 4: The miniport 'Microsoft Virtual Machine Bus Network Adapter #3' reset.

For additional information about this problem, definitely check out http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2virtualization/thread/0408a28d-6ab8-4c85-8773-4bc42c2df40b

More to come? Hopefully not! ;-)

If you found this post helpful, please support my advertisers:

Configuring the People Picker and No exact match was found

2010-08-12T16:54:00.001+08:00

SharePoint's people picker is generally one of those things that just kind of works—and fairly well no less. There's a gotcha to that statement however: the people picker works well when the the SharePoint farm exists in the same domain as the users you want to match against, or exists in a second domain where a two-way trust has been established with the first domain.

If your SharePoint web frontends exist in another domain with a one-way trust, you've got some extra work to do. This is the case with our dev setup and DMZ setup: our dev VMs are joined to the dev domain which trusts the corporate domain and our production servers are similarly joined to a web domain that also trusts the corporate domain. Both trusts are one-way.

I'll simplify what needs to be done by stating you simply need to tell SharePoint which forests or domains house the users you're after and provide an account from that domain.

Firstly you'll need to provide a key that will be used to encrypt any passwords you plug in during the next step. Run this on every WFE where "key" is a string of your choosing:

STSADM.exe -o setapppassword -password key

Next, set the peoplepicker-searchadforests property:

STSADM.exe -o setproperty-propertyname peoplepicker-searchadforests -propertyvalue <Valid list of forests or domains> -url <URL of the Web application>

where <Valid list of forests or domains> might look like this:

"domain:mydomain.com,mydomain\myuser,mypassword"

Supply the URL of the web application you want to configure (and note you don't need to set this for Central Admin, set it for a specific web application). Multiple domains and forests can be listed if necessary.

For more information, check out these resources:

If you found this post helpful, please support my advertisers:

Data Compare crashes Visual Studio 2010

2010-08-10T14:52:00.001+08:00

Although I'd previously noticed the Data Compare and Schema Compare options on the Data menu in Visual Studio, until today I didn't have a good reason to see what they can do.

Note I'm running VS Ultimate; if you can't see it, I'm not certain in which editions of the product this menu makes an appearance. SQL Server Management Studio 2008 doesn't seem to have a comparable tool that I'm aware of—which seems odd—but please comment if you know something I don't.

So here's the situation: two copies of the same database, one that's been moved to a different server and both of which have data changes. Your mission: find and fix the differences.

Open VS, Data –> Data Compare –> New Data Comparison…

CRASH!

Luckily I was able to work around this problem (feature?) by re-opening VS, Data –> Transact-SQL Editor –> New Query Connection, connecting to any ol' database (or optionally just cancelling out of the connection window) and then launching the compare wizard again.

I'm not sure what this does since you specify a database connection in the compare wizard anyway and cancelling the connection window or closing the new query window after opening the Transact-SQL Editor connection makes the problem go away. I've logged a bug with Microsoft connect.

Update 6 Sept 2010: MSFTConnect just got in touch to tell me this is likely related to the Solution Navigator extension in the Productivity Power Tools. Disabling apparently fixes the problem and the problem should be fixed this month.

If you found this post helpful, please support my advertisers:

Enable Fusion Assembly Binding Logging

2010-08-02T10:59:00.000+08:00

The WRN: Assembly binding logging is turned off message is annoying but assembly binding logging can be extremely helpful when you need to know how .NET is (or isn't) locating the assemblies you've referenced. The message is annoying because, if you're like me, you never have logging enabled and the registry key cited is a bit unusual:

To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.

What does the exclamation mark mean? Presumably EnableLog is a DWORD in the Fusion key but it's all a bit unclear for my liking. Once you've set this DWORD, you need to figure out what to do next and for many people that will likely involve firing up the Fusion Log Viewer fuslogvw.exe or the Windows/.NET SDK. But then what?

Gary Kindel was kind enough to post the following details in response to a related Stack Overflow question:

Add the following values to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

DWORD ForceLog set value to 1
DWORD LogFailures set value to 1
DWORD LogResourceBinds set value to 1
String LogPath set value to folder for logs ie) C:\FusionLog\

Make sure you include the backslash after the folder name. I also found an IISRESET was necessary in a web context.

Since I wanted to enable this logging in an environment without Visual Studio or the Windows SDK installed, the above option was clean and lightweight. Log files were dumped to the expected location in .html format and it was then a case of locating the assembly I was interested in… and, oh yeah, fixing the problem ;-) The issue was also detailed in the ASP.NET error message returned by IIS.

Advanced geeks: because Fusion logging supposedly affects performance, you might want to create a reg file/batch script to toggle logging on and off. Here's a starting point—put this into a file called EnableFusionLogging.reg and double-click to run it:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"ForceLog"=dword:00000001
"LogFailures"=dword:00000001
"LogResourceBinds"=dword:00000001
"LogPath"="C:\\Temp\\FusionLog\\"

I actually call this from a batch script which also resets IIS and I have a mirror reg file that disables logging.

If you found this post helpful, please support my advertisers:

Windows Licensing Details

2010-08-01T11:12:00.000+08:00

Windows will report licensing details if you run the following from an elevated console window:

slmgr.vbs /dlv

The Windows Script Host popup will shortly tell you which edition of Windows you're running, which licensing channel you fall under (retail, OEM, volume), your activation ID, license status, rearm counts, and KMS details.

Visual Studio 2010 Remote Debugger Location

2010-07-28T09:42:00.001+08:00

You'll find the VS 2010 remote debugger a similar location to that of the 2005/2008 debuggers:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger

Note VS2010 is still a 32-bit app so if you're running a 64-bit OS, you'll need to be looking in the Program Files (x86) directory. The debugger itself comes in both x86 and x64 flavours.

To install, I normally just copy the relevant architecture folder to the remote server. Run msvsmon.exe and assuming you're otherwise setup for remote debugging, it should be same as previous versions of Visual Studio!

Ps. You can also download the remote debugger from Microsoft.
Pps. I normally add msvsmon to the Windows Startup folder so it starts whenever I boot my remote dev environment (I've found I previously had to log on to the server, however, and two users can't run the monitor simultaneously on the same server). Apparently the 2010 monitor can be run as a service—not sure if this was the case for previous versions.

PublishingPageLayout doesn't point to current web application

2010-07-23T14:17:00.001+08:00

In the past, we've developed a habit of "birthing" new SharePoint sites in a UAT environment for initial setup and stabilisation before the big move to the production farm; during major site renovations—like the recent www.westernaustralia.com rebrand—we'll implement a quasi-freeze on production (emergency edits only) and conversely pull the content down to UAT for overhaul. At the end of the day, we're moving SharePoint content between farms on a fairly regular basis.

Prior to the release of the April 2009 Cumulative Update packages, Microsoft didn't support moving content databases between farms because "MOSS often stores absolute URLs to the Page Layout in the properties of a Publishing Page." With the April Cu that changes but of course the times they a change too and we've abandoned the stsadm backup/restore commands in favour of restoring SQL Server backups and running the stsadm deletecontentdb/addcontentdb commands (it's not only more reliable but many times faster…).

Until yesterday none of the above was causing us any problems. In fact, we'd even become complacent about it all.

So finding out one of our content editors was unable to publish a page due to a previously unseen exception was not something that would have led us to review the way we handle content databases. After checking out some pages for editing, an attempt to publish the page was met with the following exception:

ArgumentException
Value does not fall within the expected range.

    Stack trace:    at Microsoft.SharePoint.Library.SPRequestInternalClass.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)
   at Microsoft.SharePoint.Library.SPRequest.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)
   at Microsoft.SharePoint.SPWeb.GetMetadataForUrl(String relUrl, Int32 mondoProcHint, Guid& listId, Int32& itemId, Int32& typeOfObject, Object& fileOrFolder)
   at Microsoft.SharePoint.SPWeb.GetFileOrFolderObject(String strUrl)
   at Microsoft.SharePoint.Publishing.CommonUtilities.GetFileFromUrl(String url, SPWeb web)
   at Microsoft.SharePoint.Publishing.PublishingPage.get_Layout()
   at Microsoft.SharePoint.Publishing.PublishingPage.GetEffectivePageCacheProfileId(Boolean anonUserProfile)
   at Microsoft.SharePoint.Publishing.PublishingPage.GetEffectiveAnonymousPageCacheProfileId()
   at Microsoft.SharePoint.Publishing.CachedPage..ctor(PublishingPage page, SPListItem altItem, String id, String parentId, String title, String url, String description, CachedObjectFactory factory, List`1& fieldInfo, Boolean datesInUtc)
   at Microsoft.SharePoint.Publishing.CachedPage.CreateCachedPage(PublishingPage page, SPListItem altItem, CachedObjectFactory factory, List`1& fieldInfo, Boolean datesInUtc)
   at Microsoft.SharePoint.Publishing.CachedPage.CreateCachedPage(PublishingPage page, CachedObjectFactory factory, List`1& fieldInfo, Boolean datesInUtc)
   at Microsoft.SharePoint.Publishing.CachedListItem.CreateCachedListItem(SPListItem item, SPListItem alternateItem, Boolean parentIsWeb, CachedObjectFactory factory, List`1& fieldInfo, Boolean datesInUtc)
   at Microsoft.SharePoint.Publishing.CachedObjectFactory.CreateObject(SPListItem listItem, List`1& fieldInfo, Boolean datesInUtc)
   at Microsoft.SharePoint.Publishing.CachedObjectFactory.CreateObject(PublishingPage page, Boolean datesInUtc)
   at Microsoft.SharePoint.Publishing.CachedObjectFactory.GetPageForCurrentItem()
   at Microsoft.SharePoint.Publishing.TemplateRedirectionPage.ComputeRedirectionVirtualPath(TemplateRedirectionPage basePage)
   at Microsoft.SharePoint.Publishing.Internal.CmsVirtualPathProvider.CombineVirtualPaths(String basePath, String relativePath)
   at System.Web.Hosting.VirtualPathProvider.CombineVirtualPaths(VirtualPath basePath, VirtualPath relativePath)
   at System.Web.UI.DependencyParser.AddDependency(VirtualPath virtualPath)
   at System.Web.UI.DependencyParser.ProcessDirective(String directiveName, IDictionary directive)
   at System.Web.UI.PageDependencyParser.ProcessDirective(String directiveName, IDictionary directive)
   at System.Web.UI.DependencyParser.ParseString(String text)
   at System.Web.UI.DependencyParser.ParseFile(String physicalPath, VirtualPath virtualPath)
   at System.Web.UI.DependencyParser.GetVirtualPathDependencies()
   at Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.CalculateFileDependencies(HttpContext context, SPRequestModuleData basicRequestData, ICollection& directDependencies, ICollection& childDependencies)
   at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureDependencies(HttpContext context, SPRequestModuleData requestData)
   at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureCacheKeyAndViewStateHash(HttpContext context, SPRequestModuleData requestData)
   at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.GetVirtualPathProviderCacheKey(HttpContext context, SPRequestModuleData requestData)
   at Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.GetVirtualPathProviderCacheKey(String virtualPath)
   at Microsoft.SharePoint.ApplicationRuntime.SPVirtualPathProvider.GetCacheKey(String virtualPath)
   at Microsoft.SharePoint.Publishing.Internal.CmsVirtualPathProvider.GetCacheKey(String virtualPath)
   at System.Web.Compilation.BuildManager.GetCacheKeyFromVirtualPath(VirtualPath virtualPath, Boolean& keyFromVPP)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
   at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
   at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
   at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
   at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig)
   at System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Which of course means nothing.

Before long the guys stumbled across one of Stefan Goßner's brilliant posts, which suggests MOSS doesn't update all absolute page layout URLs on each publishing page object when content is shifted between farms; of cours, with the April 2009 CU installed and doing things via backup/restore or import/export, we may have avoided this issue.

You can see the exact problem by examining a page in SharePoint Manager: locate a page in the Pages library, expand the page node to reveal its Properties node, and expand the Properties node so you can inspect the PublishingPageLayout node. This screenshot is from my development environment, a server named dev-moss-mh5 and the wa.com web application configured to run on port 180—so obviously the http://edit.uat.westernaustralia.com value is incorrect:

Interestingly, this problem was only affecting the production edit site… for whatever reason, my dev environment was unaffected. However, running Stefan's FixPageLayout code corrected the problem in production. The application runs through every page in every subsite and fixes the PublishingPageLayout property where required (in addition to reporting any other page instance/layout/master page issues).

Update: Just remembered from a while back Gary Lapointe also has an stsadm command to fix this problem:

http://stsadm.blogspot.com/2007/08/fix-publishing-pages-page-layout-url.html

Subsites, the Pages lists and 302 Redirects in an anonymous environment

2010-07-22T15:51:00.001+08:00

Our network admin recently noticed some unusual errors in the proxy logs: www.rottnestisland.com/en/pages was failing to redirect to the default page. Fiddlering the request revealed a 401 response was being returned by SharePoint and friends.

Naturally our first inclination was to scratch our heads and wonder why such a thing would occur; at first glance both /en and /en/pages share many similarities with regular IIS directories; shouldn't SharePoint just go looking for the default page?!? After all, a request for /en is successfully 302 Redirected to /en/pages/home.aspx and the authenticated site also redirects the /en/pages request.

In the above case, home.aspx is the default page as configured in the Pages list and it is published along with its master page and other supporting resources (in fact the page loads without issue when requested directly).

Our anonymous setup isn't out of the ordinary: a read/write web app running in the default security zone is extended to a second read-only web app running in the internet zone with anonymous access enabled. Most annoyingly, we've got some URL rewriting tricks going on with www.westernaustralia.com so that site (which runs in the same farm as Rottnest) does redirect the /pages directory, as does its sister web site, www.tourism.wa.gov.au… the latter of which should have no tricks applied!

Until this point we assumed those of us in the naughty developer team had broken something on the Rottnest site and those of its sibling sites running the same code base. When I spun up a sanity web app in my dev machine, however, I found I could reproduce the problem in that environment with no customisations applied.

From one point of view this all makes sense: subsites will 302 Redirect to the default page in the Pages library and behave in the "normal IIS way"; the Pages library, being a list, should not do the same and does not—it's not a site. While plausible, this argument falls down when everything just works in the authenticated site.

No deeper understanding or solution to this one as yet…

SharePoint 403 Forbidden and /bin directory read access

2010-07-22T15:29:00.001+08:00

We've run a post-deployment script in our SharePoint environment for many years now to address a 403 Forbidden error that otherwise plagues us; the script grants the Authenticated Users account read access on the web application's bin directory and web.config file (for both the authenticated and anonymous sites).

Someone deemed this necessary back in the day and, until recently, I always assumed it was just some quirk with our crusty environment. That was until I came across the same problem at another client site where custom code (in a SharePoint solution) was being deployed.

With that as motivation, I decided to figure out why we do what we do and determined a .NET 2.0 security update from July 2007 introduced the problem:

The performance of the server may decrease and adding users or uploading files may fail with the error message "403 Forbidden error" after you install a Microsoft .NET Framework 2.0 hotfix.

The security update links to a SharePoint 2007 hotfix:

In SharePoint Server 2007, the performance of the server may decrease, and you cannot upload files or add users. Additionally, you may receive the following error message:

403 Forbidden error

This issue occurs after you install a Microsoft .NET Framework version 2.0 hotfix that is build 2.0.50727.832 or a later build.

In the www.westernaustralia.com context, the problem normally crops up when an anonymous user requests a page that runs custom code; with my second client, the problem occurred in the authenticated site when a content editor with full permission over the site collection attempted to access a SharePoint list. The 403 response seemed to be intermittent but I suspect it was application recycles correcting the problem for a short while. As a user with local admin rights on the WFE, I wasn't seeing the problem myself.

Apparently uninstalling the update may be an option but I wonder if it's been incorporated into .NET 3.5 so that may not be possible in this day and age.

Anyway, the consensus around this problem is that it's caused when a request from an authenticated user without local admin rights results in a failed read of the /bin directory by the impersonating w3wp.exe process (as evidenced by filemon.exe). The solution is to ensure the Authenticated Users group has read access to the /bin directory below C:\inetpub\wwwroot\wss\VirtualDirectories\{your app}

Notably, we've found this permission needs to be reapplied as part of every deployment and often find permissions have reset after touching the Authentication providers settings in Central Admin.

Dumb User

2010-07-15T15:09:00.001+08:00

A web site user rang the support desk to complain a thumbnail image of theirs wasn't displaying on our web site. We asked them to send a screenshot of the problem; this is what we got back (names altered to protect the bright sparks involved):

From: Best Resort [mailto:visit@bestresort.com]
Sent: Thursday, 15 July 2010 12:40 PM
To: 'Carol Belding'
Subject: Best Resort Broken Image

Hi Carol

Printed and scanned page for you.

Regards
Fran
Best Resort

I've been in IT too long…

CSS background-position not applied

2010-07-13T11:04:00.001+08:00

Had a weird issue with a CSS sprite this morning where both IE8 and Firefox ignoring the background-position style. After stripping the component back to bare bones, the style started working as expected; I was momentarily stumped until a co-worker spotted the fact I didn't have any units specified for the x and y coordinates. Adding px to each coordinate resolved the issue.

.addLeg
{
    background-image: url(Buttons.png);
    background-position: -10px -70px;
    width: 143px;
    height: 30px;
}

Doh! That's what I get for copying code from the internet! Maybe something to do with the nesting or inherited styles? Who knows…

In related news, I also noticed the IE Dev Toolbar in IE8 is inclined to display additional styles seemingly appended to the background-image style. This is a minor annoyance in terms of being able to manipulate the appended style but it seems to be a bug with the toolbar, not IE as the styles are applied correctly.

C# Object Initialisers and trailing commas

2010-07-11T11:08:00.001+08:00

C# 3.0 (.NET 3.5) introduced some really handy new features and hidden gems—and I'm still coming across the latter today.

If you've been developing with C# 3.0 for a while, you'll know about object and collection initialisers: they allow you to initialise the members of an object or a collection at instantiation-time, rather than having to declare a variable and then assign values to the members of that variable. It's a convenience thing and makes life easier in a LINQ context (although the debugging experience in VS2008 sucks).

When looking back through a piece of code I written previously, I noticed I'd inadvertently left a trailing comma after the final assignment in the list. I thought this was unusual because the code compiled and the C# is normally anything but lazy when it comes to most language constructs.

StaffMember staffMember = new StaffMember()
{
FirstName = "Michael",
Surname = "Hanes",
};

Sure enough, the ECMA C# Language Specification actually notes the following in the section about Array Initializers: "[…] C# allows a trailing comma at the end of an array-initializer. This syntax provides flexibility in adding or deleting members from such a list […]" (page 363, section 19.7). Interestingly, object and collection initialisers simply inherit this behaviour and the ability to initialise both arrays and enums in this way is not C# 3.0-specific (the specification document actually cites the C language).

In my opinion this is a rational design decision that increases the useability of the C# language by developers. By contrast, I'm forever having to shift SQL select statement commas around when commenting out individual lines and it's a major inconvenience. Development is normally a very fluid, experimental time in the lifecycle of a code artefact and anything that simplifies that exercise and increases maintainability is a good thing.

How to recover permanently deleted files in Outlook

2010-07-08T09:20:00.001+08:00

I receive hundreds of emails a day from various systems and the occasional email from humans; in both cases, most of that email gets deleted straight away. Because my Deleted Items folder clogs up quickly as a result of this barrage, I've become a chronic shift-delete kind of guy over time—in other words, get rid of it, I don't want to ever see it again, goodbye. This generally works quite well for me and I've never had the need to recover something I've permanently deleted. Until today.

Despite it's fancy new ribbon, Outlook 2010 still allows me to delete all email below the Today group (and other groups)—a complete useability flaw, if you ask me but I'm not a Microsoft genius and I suppose the more barbaric users out there may actually use this "feature".

So I accidentally did just that today—my machine was bogged down running a SQL query: my fat fingers accidently moved the highlight to the Date: Today heading at about 2:30pm, I hit the shift-delete combo, said No I don't want to permanently delete when prompted (having realised what I'd done), and everything that I had yet to file from my Inbox and actually wanted to keep got deleted anyway.

Sigh. The IT guys proposed some registry hacks that didn't seem to apply to 2010 until someone finally found the almighty Recover Deleted Items button on the Folder menu:

Clicking this button brings up a list of email messages it can recover from somewhere (Exchange? I don't know and don't care) with details about date, sender, subject, etc. You can recover all files or individual files.

jquery.jsonp addresses issues with beforeSend and timeout

2010-07-05T09:20:00.001+08:00

On the coat-tails of my previous post, I've come across the Google Code jquery-jsonp library and it's a saviour if you're working JSONP requests. Remember a JSONP request dynamically inserts a script tag into the DOM and doesn't use the same XMLHttpRequest as your typical AJAX request.

I ended up here because—much like beforeSend—the timeout parameter wasn't having any effect on my jsonp request: the request simply wouldn't time out despite the value supplied to this parameter.

In addition to supporting both beforeSend and timeout properties, jquery-jsonp adds some really nice caching support—both typical HTTP (aka "browser") caching and page-based caching that leverages the JavaScript VM's memory (apparently). Anyway it seems to work as advertised. Perhaps most importantly, the name of the callback can be changed.

A minified version of the code is available from Google Code and the documentation is concise and well-written with examples.