Managing assemblies with Powershell

A simple way to access assemblies and see what's in them. Still a work in progress. I hope to add more tricks to this post soon.

Load in the assembly
$assembly = [Reflection.Assembly]::LoadFile($assemblyPath)
or
$assembly = [Reflection.Assembly]::Load($assemblyName)

Get details on a type defined in the assembly
$type = $assembly.DefinedTypes | Where-Object {$_.Name -eq $typeName}
$type.DeclaredConstructors | ForEach-Object {$_.ToString()}
$type.DeclaredMethods | ForEach-Object {$_.ToString()}

To load the assembly for use
Add-Type -Path $assemblyPath #if assembly in file
or
Add-Type -AssemblyName $assemblyName #if assembly in GAC
For some reason $assemblyName must be the full name contrary to the documentation in Add-Type

Get all assemblies in current AppDomain
[AppDomain]::CurrentDomain.GetAssemblies() | Select-Object FullName | Sort-Object FullName

References:
System.Reflection.Assembly class
Add-Type cmdlet
AppDomain class

SharePoint Timer Service not starting up

I recently discovered that on one of my farms my SharePoint Timer Service would continuously start up and crash.
There are numerous entries like the following 2 in the System log:

The SharePoint 2010 Timer service terminated unexpectedly.  It has done this 2965 time(s).  The following corrective action will be taken in 30000 milliseconds: Restart the service.

and

The timer service could not initialize its configuration, please check the configuration database.  Will retry later.

The following is found in ULS:

SPTimerStore.InitializeTimer: SPConfigurationDatabase.RefreshCache returned SPConstants.InvalidRowVersion

and

The timer service could not initialize its configuration, please check the configuration database.  Will retry later.

I verified that my service's user context had the correct username and password.

I also cleared the timer cache (and, yes, I emptied the GUID folder and instead of deleting it).

There were a couple of DCOM 10016 errors which seemed irrelevant to this issue, but I fixed those anyway (as per http://sajiviswam.wordpress.com/2011/04/15/the-machine-default-permission-settings-do-not-grant-local-activation-permission-for-the-com-server-application-with-clsid-000c101c-0000-0000-c000-000000000046-sharepoint-2010/)

I'm still getting the same problem.

I started looking at the Fusion log as described in http://soerennielsen.wordpress.com/2009/01/14/fixing-the-timer-service-when-everything-breaks-down/ but think I'm in too deep.

What's curious is that the Timer Service stopped functioning around the time the web application was extended in order to support HTTPS and there are some new files in C:\windows\assembly\GAC_MSIL. However, I am unable to make any connection. As far as I can tell, my assemblies in the GAC are not corrupted since all other functions appear to be working.

Determining who has an open file handle on DLLs in the GAC

I recently needed to update a solution in my SharePoint farm however:

1. The update required administration and connection permissions to the User Profile Service Application (UPA)
2. Some assemblies in our solution was causing the the UPA to be inaccessible

So, my code is broken and needed update, my update is broken because it can't access UPA, my UPA is broken because of my code ... argh!

Then, I had this idea, figure out which DLLs were breaking the UPA and update those directly in the GAC, hoping that it will at least free up the UPA so the update. I figured my DLLs were reasonably compatible over the different versions. So this is what I did:

1. Grab my updated WSPs
2. Use 7-zip to open the WSPs and extract the DLLs I needed
3. Open up the GAC (C:\Windows\Assembly)
4. Copy the DLLs I need into the GAC
5. Verify, by version number, that my DLLs were indeed copied into the GAC (I have seen cases where the copy seems to work, but nothing actually happens)
6. iisreset
7. restart owstimer
8. Run my installer to update my code as normal.

This worked very well for me, but when a colleague tried it, he found that he was unable to get step 4 working. He kept getting access denied issues. It turns out that he had UAC turned on and some processes (not just iisadmin) had an open file handle on the very DLLs he needed to update. Getting around the UAC issue is just a matter of running things as administrator. To solve the file handle issue, we used Handle from Sysinternals. 

Now it was simply a matter of opening up a command prompt and doing something like this:

Handle.exe c:\Windows\assembly\gac_msil\<your DLL name>

Handle will also recurse into subdirectories for you! Now it's just a matter of stopping those processes and continuing on.