5

I have a single solution that consists of the following:

Custom Timer Job (WebApplication scoped)

Custom Content Type and List (Web scoped)

Custom Logging Area (Web scoped)

These features are set to not automatically activate on anything but Central Administration. When debugging, if I retract the solution and attempt to redeploy it, I get:

Failed to load receiver assembly "Nauplius.ADLDS.UserProfiles, Version=1.1.0.1, Culture=neutral, PublicKeyToken=6234e7e34f29e39a" 
for feature "Nauplius.ADLDS.UserProfiles_LoggingFeature" (ID: 0b1ba53c-8664-42fc-a01d-de60cb3e32b7).: 
System.IO.FileNotFoundException: 
Could not load file or assembly 'Nauplius.ADLDS.UserProfiles, Version=1.1.0.1, Culture=neutral, PublicKeyToken=6234e7e34f29e39a' or one of its dependencies.     
The system cannot find the file specified.
File name: 'Nauplius.ADLDS.UserProfiles, Version=1.1.0.1, Culture=neutral, PublicKeyToken=6234e7e34f29e39a'

My understanding is that this is due to the OWSTIMER service needing to be restarted. Is there a work around here? For what its worth, the assembly is still in the GAC. Once debugging is stopped, the assembly is removed (but not the assembly's folder, which is interesting).

However, let's say I'm done with debugging, package the solution, the GAC is empty. If I then deploy it via PowerShell, I get the same error about the missing assembly. Even recycling the OWSTIMER service at this point will not resolve the issue. Instead the only solution I've found is to increment the assembly version and redeploy (not very practical).

When it partially deploys, it unfortunately leaves some of the other features behind. Because the solution deployment is in an error state, I have to use Feature Admin to forcefully remove the List feature of my solution.

How can I resolve this deployment issue for my custom timer job?

Current source code.

Fusion log on assembly bind failure:

*** Assembly Binder Log Entry  (5/7/2012 @ 7:19:52 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll
Running under executable  C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\OWSTIMER.EXE
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = NAUPLIUS\s-sp2010farm
LOG: DisplayName = Nauplius.ADLDS.UserProfiles, Version=1.1.0.1, Culture=neutral, PublicKeyToken=6234e7e34f29e39a
 (Fully-specified)
LOG: Appbase = file:///C:/Program Files/Common Files/Microsoft Shared/Web Server Extensions/14/BIN/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\OWSTIMER.EXE.Config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Nauplius.ADLDS.UserProfiles, Version=1.1.0.1, Culture=neutral, PublicKeyToken=6234e7e34f29e39a
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).
Improve this question
0

4 Answers 4

Reset to default
1

Try to remove/retract everything, even the assembly folder you mentioned. Instead of using the SharePoint tokens in VS (receiverAssembly="$SharePoint.Project.AssemblyFullName$" receiverClass="$SharePoint.Type.48312723-bcb8-45ab-8701-8800016a158a.FullName$") make them 'hard coded', just to make sure you have the correct fully qualified name, namespace, class, etc.

Also, verify your references - maybe it's due to a dependent assembly you're missing (Could not load file or assembly... or one of its dependencies.

Redeploy your package, recycle OWSTimer service / IISReset on all web front ends.

Improve this answer
1
  • So I've hard coded them, but I'm still getting assembly bind failures. I've updated my post with the fusion log.
    – Trevor Seward ♦
    May 8, 2012 at 2:20
1

And the solution was...

The assembly name was too long, or so it appears. After shortening the output assembly name, I'm not having any assembly binding issues.

Improve this answer
6
  • Well, never mind, that wasn't it either. It worked for quite some time, but when I finally switched from Debug to Release mode, it fails again.
    – Trevor Seward ♦
    May 8, 2012 at 4:22
  • It could be NOT the assembly name, but rather the filepath on disk. If your project is within a directory - like your 'My documents' or whatever - the filepath can be too long. Try moving it to C:\ or shorten it's name by an additional couple of characters. (Length('Release') > Length('Debug')) Also, it might be the FEATURE name length, rather than the assembly. I've had similar a couple of times.
    – Andy Burns
    May 8, 2012 at 17:28
  • This is when deploying from a packaged solution, not from Visual Studio. I typically copy my solution (wsp) to my desktop and deploy it via PowerShell there. What is strange is that the Debug copy of the solution appears to work while the Release copy does not. I'll check on the Feature name length. They are fairly long.
    – Trevor Seward ♦
    May 8, 2012 at 19:06
  • 1
    That is weird. Okay, random maybe, but how about taking both WSPs, unzipping them (I think they're CAB files) and running a diff over their contents. I mean, you'd expect the assemblies to be different, but everything else should be the same, right?
    – Andy Burns
    May 10, 2012 at 8:24
  • 1
    I think I got it, the DEFINE Trace was disabled. Re-enabled it, and perhaps with the addition of shortening the class names, it is consistently working now.
    – Trevor Seward ♦
    May 11, 2012 at 20:04
0

Have you tried your script to do net stop sptimerv4, run the deploy/retract/update/whatever then net start sptimerv4 afterwards? If you just recycle OWSTIMER, it will most likely latch itself back onto the assembly when it loads backup.

As good as VS2010 is, it's still not up to the task of improving the experience of developing custom timer jobs, unfortunately.

Improve this answer
1
  • Unfortunately that doesn't fix the issue either. If I stop SPTimerV4, add the solution, install the solution, start SPTimerV4, the same issue will occur with the FileNotFoundException.
    – Trevor Seward ♦
    May 6, 2012 at 6:12
0

Every time you deploy a solution containing an assembly used by the owstimer.exe you need to restart it after the deploy is completed. It has happened to me several times both in 2007 and 2010, and restarting the service does the trick. Remember this stuff should be done on every farm's node. Here's a little discussion about the subject on msdn forums : http://social.technet.microsoft.com/Forums/nl/sharepoint2010setup/thread/ad412c64-ae82-4f56-9fa0-1dadd0d59d15 Hope this helps

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.