Dynamics CRM 2011 on premise.
I registered a custom workflow assembly using the Plugin Registration Tool.
The plugin code was:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Activities;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Workflow;
namespace CreateDirectDebit
{
public class CreateDirectDebit : CodeActivity
{
protected override void Execute(CodeActivityContext context)
{
}
}
}
This was successful.
Then I change the code to this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Activities;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Workflow;
namespace CreateDirectDebit
{
public class CreateDirectDebit : CodeActivity
{
protected override void Execute(CodeActivityContext context)
{
// Create the tracing service
ITracingService tracingService = context.GetExtension<ITracingService>();
if (tracingService == null)
throw new InvalidPluginExecutionException("Failed to retrieve the tracing service.");
tracingService.Trace("CreateDirectDebit.Execute, 1");
throw new InvalidPluginExecutionException("Testing dialog custom workflow.");
}
}
}
When I update the assembly using the Plugin Registration Tool I get this error on pressing Update Selected Plugins:
Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: Plug-in assembly fullnames must be unique (ignoring the version build and revision number).
Detail: <OrganizationServiceFault xmlns="http://schemas.microsoft.com/xrm/2011/Contracts" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<ErrorCode>-2147204741</ErrorCode>
<ErrorDetails xmlns:a="http://schemas.datacontract.org/2004/07/System.Collections.Generic" />
<Message>Plug-in assembly fullnames must be unique (ignoring the version build and revision number).</Message>
<Timestamp>2013-10-14T10:04:55.4528719Z</Timestamp>
<InnerFault>
<ErrorCode>-2147204741</ErrorCode>
<ErrorDetails xmlns:a="http://schemas.datacontract.org/2004/07/System.Collections.Generic" />
<Message>Plug-in assembly fullnames must be unique (ignoring the version build and revision number).</Message>
<Timestamp>2013-10-14T10:04:55.4528719Z</Timestamp>
<InnerFault i:nil="true" />
<TraceText i:nil="true" />
</InnerFault>
<TraceText i:nil="true" />
</OrganizationServiceFault>
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.Xrm.Sdk.IOrganizationService.Update(Entity entity)
at Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy.UpdateCore(Entity entity)
at Microsoft.Crm.Tools.PluginRegistration.RegistrationHelper.UpdateAssembly(CrmOrganization org, String pathToAssembly, CrmPluginAssembly assembly, PluginType[] type)
at Microsoft.Crm.Tools.PluginRegistration.PluginRegistrationForm.btnRegister_Click(Object sender, EventArgs e)
The same error occurs if I revert the code to the first version and try to update the assembly.
What have I done wrong?
This usually arises for one of two reasons:
You've clicked Register rather than Update in the Plugin Registration Tool
You've clicked Update but you had selected the wrong plugin/workflow assembly to update.
In Dynamics CRM 2011 plugin and workflow assemblies can be updated as long as name, public key, major version and minor version of existing and new assemblies are the same. If the minor version of your assembly has been incremented (your VS build may have done this automatically), then both are considered to be different.
They can however be registered side-by-side. Just register the new version and remove the old one.
In my case, I received this error when trying to update a plugin.
The plugin I had selected to update in the Registered Plugins & Custom Workflow Activities area wasn't correct. The names were very similar so I didn't notice at first.
By selecting the correct plugin to update from the list, I was able to continue with the update.
Your assembly must be strongly signed with the full strongname matching. The two most likely culprits are the version number and that you've used a different key to sign the assembly.
I wrote up a blog post with more info:
PLUGIN ASSEMBY FULLNAMES MUST BE UNIQUE
http://helpfulbit.com/plugin-assemby-fullnames-must-be-unique/
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).
Yeah, there's no way this code snippet runs on WP7.5 SDK. task.ToString() will be the type name ("Microsoft.Phone.Scheduler.PeriodicTask") and as such not the right value.
Change:
ScheduledActionService.LaunchForTest(task.ToString(), TimeSpan.FromSeconds(60));
To:
ScheduledActionService.LaunchForTest(task.Name, TimeSpan.FromSeconds(60));
And it works fine.
To answer your question: *.ni.dlls are NGENed .net dlls. The framework gets NGENed and deployed to the phone so most exceptions you'll see will come from *.ni frameworks dlls. I'm guessing you just saw a generic exception.
How are you getting on with this? I have a very similar issue ('System.InvalidOperationException' occurred in System.Windows.ni.dll" when I go into the Background agent code... it was working fine in WP7... the app is still WP7 except that now I am running under VS2012 and have installed the WP8 SDK.
Funny thing is that I have another app that works just fine - exactly the same scenario and environment.
Have you got your issue sorted yet? It's been very frustrating.
The ".ni." stands for Native Images, surrounding .NET specifically.
I found this when a BackgroundDownload.exe started running and I started tracking. This came out of one of its logs.
1,"fusion","GAC",0
1,"WinRT","NotApp",1
3,"System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System\556b21e2d636701016ad76fe3776a505\System.ni.dll",0
3,"System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Core\f8a689485cf213780df744fde2c54190\System.Core.ni.dll",0
3,"System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Configuration\d577fd286e51f472414996f5144aaaa9\System.Configuration.ni.dll",0
3,"System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Xml\b7630f847e13fc7dd88ab8a8862c2b7a\System.Xml.ni.dll",0
3,"System.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Security\68e68081542c0d5baa15a846cf2ca458\System.Security.ni.dll",0
3,"System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Drawing\74f4937603f11ad21e91b4aed570fd4f\System.Drawing.ni.dll",0
3,"System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Windows.Forms\56eb2160cb5e0e733dd0c2366d3de3d2\System.Windows.Forms.ni.dll",0
3,"System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Runtime\89b3e92a43e17d474b9cbc6747c76fa0\System.Runtime.ni.dll",0
3,"System.Reflection, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Reflection\aaf8c507950277bf496287476935feeb\System.Reflection.ni.dll",0
3,"System.Numerics, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Numerics\efa65924471acfbcd2b23cceae87e730\System.Numerics.ni.dll",0
3,"System.Runtime.Serialization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Runteb92aa12#\ddf4d9ca9e105b351ad6a99442e5edd9\System.Runtime.Serialization.ni.dll",0
3,"System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Data\7331e242363acc7a26bec36a4a703e6c\System.Data.ni.dll",0
3,"System.Xml.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Xml.Linq\2ca98da3b8de00d4eaf9599d6316c284\System.Xml.Linq.ni.dll",0
3,"SMDiagnostics, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\SMDiagnostics\614b71bb8864202da9d3e6dcbc0be4a3\SMDiagnostics.ni.dll",0
3,"C:\WINDOWS\system32\WinMetadata\Windows.Networking.winmd","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\Windows.Networking\c98b01a13bd7a97270a1775b1cd0cf4f\Windows.Networking.ni.dll",1
3,"System.Runtime.InteropServices.WindowsRuntime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a","C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\System.Runtbff93e24#\16fa2326f490f06c2d7a427861e635b6\System.Runtime.InteropServices.WindowsRuntime.ni.dll",0
My question is very similar to this one, only that the answer and work-around are not working for me. Also I am in Visual Studio 2012.
I have a VSPackage which is referencing another project, which is dependent on other dlls. Everytime time I run my package in debug I get an exception that the other dlls cannot be found. They are in the output directory, and they are signed.
I tried referencing them directly by the VSPackage project to no avail.
Thoughts?
This problem exists because Visual Studio is not looking for assemblies in a folder of your extension if your extension has no explicit dependence on these assemblies. For example, dependences set in a configuration file (IoC config) or in xaml code. I know three solutions to this problem:
You can deploy these assemblies in the GAC and Visual Studio will load them. This method is good if you use a third-party library that built for use in the GAC (for example, MS Enterprise Library). But VSIX Deployment Package does not allow installing assemblies in the GAC, you can use the MSI installer.
For VSPackages for Visual Studio 2010/2012 you can use ProvideBindingPath attribute. The path where your extension located will be added to the paths that Visual Studio uses to find dependent assemblies. If your extension doesn't include a VSPackage, you can add this attribute to any public class (see here).
[ProvideBindingPath]
public class MyVsPackage : Package
{ /* ... */ }
You can manually resolve assembly names. To do this, you need to subscribe to the AssemblyResolve event and you need to return required assemblies from a handler. This is the most flexible way, if you cannot use the previous methods, this is especially for you.
In my IntelliDebugger project, I wrote a class ManualAssemblyResolver for it:
using System;
using System.Reflection;
namespace IntelliEgg.Debugger.Utility
{
public class ManualAssemblyResolver : IDisposable
{
public ManualAssemblyResolver(Assembly assembly)
{
if (assembly == null)
throw new ArgumentNullException("assembly");
_assemblies = new[] {assembly};
AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolve;
}
public ManualAssemblyResolver(params Assembly[] assemblies)
{
if (assemblies == null)
throw new ArgumentNullException("assemblies");
if (assemblies.Length == 0)
throw new ArgumentException("Assemblies should be not empty.", "assemblies");
_assemblies = assemblies;
AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolve;
}
public void Dispose()
{
AppDomain.CurrentDomain.AssemblyResolve -= OnAssemblyResolve;
}
private Assembly OnAssemblyResolve(object sender, ResolveEventArgs args)
{
foreach (Assembly assembly in _assemblies)
{
if (args.Name == assembly.FullName)
{
return assembly;
}
}
return null;
}
private readonly Assembly[] _assemblies;
}
}
This class must be created before the first call to the problem assembly (e.g., in Package::Initialize() method)