I'm working on a WP8 app that uses a ScheduledTaskAgent to update a Live Tile. It's a pretty simple app, really. Problem is that while I've directly copied the code from the WP7 project to the WP8 project, it won't launch the ScheduledTask. Not only that, but I get an error if I'm debugging and I try to launch the scheduled task for testing.
'System.InvalidOperationException' occurred in System.Windows.ni.dll
Not only that, but it doesn't give me any stack to look through, and says that the source is not available, that I can look at the disassembly in the disassembly window, which means nothing to me. So, not a very helpful error, IMO.
I tried putting a break point in the constructor of the scheduled task, and it never makes it there. If I comment out the launch for test, no error. But of course, putting the app in my phone, it never launched, leaving it overnight.
Here's my code:
var taskName = "TileUpdater";
var oldTask = ScheduledActionService.Find(taskName) as PeriodicTask;
if (oldTask != null)
{
ScheduledActionService.Remove(taskName);
}
if (useLiveTile)
{
//GenerateTileInfo();
PeriodicTask task = new PeriodicTask(taskName);
task.Description = AppResources.BackgroundTaskDescription;
oldTask = ScheduledActionService.Find(taskName) as PeriodicTask;
if (oldTask == null)
{
ScheduledActionService.Add(task);
}
#if DEBUG
ScheduledActionService.LaunchForTest(taskName, TimeSpan.FromSeconds(10));
#endif
}
The code works fine in the WP7 version. :/
This is in my WMAppManifest.xml file:
<ExtendedTask Name="BackgroundTask">
<BackgroundServiceAgent Specifier="ScheduledTaskAgent"
Name="xxxScheduledTask"
Source="xxxScheduledTask"
Type="xxxScheduledTask.SecheduledAgent" />
</ExtendedTask>
In my scheduled task, the only thing I'm doing is calling a procedure that generates the tile info, updating the tile, and for the moment, I'm re-running the launch for test, so I can watch to see if it updates again, though I've had this commented out - I uncommented it to paste here, but that was commented out. Here is my OnInvoke method:
GenerateTileInfo();
#if DEBUG
ScheduledActionService.LaunchForTest(task.ToString(), TimeSpan.FromSeconds(60));
#endif
NotifyComplete();
The GenerateInfo method doesn't do anything that would cause a problem, but of course, it's never getting there anyway. I did test my generating of the tile info, and implementing it, by placing that code in the MainPage.xaml.cs and calling it for now, to see if it worked, and the code I'm calling works fine. So if I open the app, the tile gets updated. Now I need to get the Background Task to work.
Any help that anyone can offer is greatly appreciated. One other clue is that last night I was getting an error that involved not being able to locate a pdb file - I think it was Microsoft.Phone.pdb, but whatever it was, it also referred to the System.Windows.ni.dll file, but now I'm not getting that pdb issue, just this InvalidOperationException. Last night the Debugging Symbols (I don't know what that means) were not loading. Today they are. I don't know what I did to fix it. Could have been a restart, for all I know.
Also, I tried creating a new project and copying my code to a new project, thinking I may have a corrupted project file, but the error I'm getting now is the same as I was getting earlier today that prompted me to create the new project.
Again, any help is appreciated. Thanks.
(Edit - New comments added below this point 12/29 at 11:34 am EST) =================================================================================
I tried another expriment. I created a new project, and copy/pasted code from http://www.jeffblankenburg.com/2011/11/25/31-days-of-mango-day-25-background-agents/ to see if I could debug the app. I did have to make a few minor changes to the code that Jeff Blankenburg wrote, because he states that when you add the scheduled task project, it will automatically add to the WMAppManifest.xml file the following code, which it didn't. I did that manually.
I also changed the StandardTileData type to FlipTileData (since that is what was default in the WP8 project) in the code that is pasted to the ScheduledAgent.cs.
Other than that, the only thing I did that Jeff doesn't mention in his article is to add the necessary using directives.
Given the results of this experiment, I think I might be looking at somehow my Visual Studio install being corrupted. Would you concur? I'm thinking that doing an uninstall/reinstall of VS2012 and the phone sdk are what's in order here, but since it takes so long, I wanted to get another opinion. Thanks.
Update (1/4/2012) ===============================================================
Uninstalled VS, went through the registry, then reinstalled VS2012, and phone SDK. Here's what I get now - at least now it will show me the stack trace:
[Native to Managed Transition] System.Windows.ni.dll!MS.Internal.JoltHelper.OnUnhandledException(object sender, System.UnhandledExceptionEventArgs args) [Managed to Native Transition] mscorlib.ni.dll!System.Reflection.RuntimeAssembly.nLoad(System.Reflection.AssemblyName fileName, string codeBase, System.Security.Policy.Evidence assemblySecurity, System.Reflection.RuntimeAssembly locationHint, ref System.Threading.StackCrawlMark stackMark, System.IntPtr pPrivHostBinder, bool throwOnFileNotFound, bool forIntrospection, bool suppressSecurityChecks) mscorlib.ni.dll!System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity, System.Reflection.RuntimeAssembly reqAssembly, ref System.Threading.StackCrawlMark stackMark, System.IntPtr pPrivHostBinder, bool throwOnFileNotFound, bool forIntrospection, bool suppressSecurityChecks) mscorlib.ni.dll!System.Reflection.RuntimeAssembly.InternalLoad(string assemblyString, System.Security.Policy.Evidence assemblySecurity, ref System.Threading.StackCrawlMark stackMark, System.IntPtr pPrivHostBinder, bool forIntrospection) mscorlib.ni.dll!System.Reflection.RuntimeAssembly.InternalLoad(string assemblyString, System.Security.Policy.Evidence assemblySecurity, ref System.Threading.StackCrawlMark stackMark, bool forIntrospection) mscorlib.ni.dll!System.Reflection.Assembly.Load(string assemblyString) Microsoft.Phone.ni.dll!Microsoft.Phone.BackgroundAgentActivator.LoadEntryPointAssembly(string assemblyName) Microsoft.Phone.ni.dll!Microsoft.Phone.BackgroundAgentActivator.LoadAgent(string assemblyName, string typeName) Microsoft.Phone.ni.dll!Microsoft.Phone.BackgroundAgentActivator.Microsoft.Phone.IBackgroundAgentActivator.CreateBackgroundAgent(string assembly, string typeinfo) Microsoft.Phone.ni.dll!Microsoft.Phone.BackgroundAgentDispatcher.AgentRequest.Invoke() Microsoft.Phone.ni.dll!Microsoft.Phone.BackgroundAgentDispatcher.InvocationThread() mscorlib.ni.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) mscorlib.ni.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) mscorlib.ni.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) mscorlib.ni.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) mscorlib.ni.dll!System.Threading.ThreadHelper.ThreadStart() [Native to Managed Transition]
Also considered that I was using the low memory emulator and had forgotten that background agents are not allowed in low mem devices, but which emulator (or device) I use makes no difference.
After all this time of fighting with it, I've got the problem resolved. In copying the code from one project to another, I forgot to add a reference to the ScheduledTask project in the main project.
I also learned a couple other things in the process of working on sample code to try to get it to work outside my project. First, when you add a ScheduledTask project it doesn't seem to add the necessary metadata to the WMAppManifest.xml file, so you need to add that manually. The other thing is that when dealing with background agents, the error messages can be pretty cryptic, and may not say a thing about what the problem really is.
From now on, when I see an error like I've seen here (I've seen several pretty cryptic errors, all seeming the same, but not quite) when working on Scheduled Tasks, that will be a prompt to be sure I've got a reference to the second project, and be sure the necessary info is in WMAppManifext.xml (including spelling - if you misspell it, it won't be underlined).