I ran across an issue a while back that a developer was running into after installing Dynamics SL 2011 on a machine with Dynamics GP 2010 (and Dynamics GP 10). Then in the next few days we had two more cases of the same issue (and again here, here, and here). But I'm getting ahead of myself in that we didn't notice that was a common thread until the third case.
So anyway, what we found was that SL ran fine as did GP 10.0. However Dynamics GP 2010 would crash consistently on launch.
After discovering that SL was the common denominator, we had un-installed SL and found that Dynamics GP 2010 again launched just fine. Reinstalling SL would again cause GP 2010 to crash on launch.
But we found it interesting that Dynamics 10 would run fine.
So how would we figure out the issue?
About the only way to determine this was to collect a memory dump of the crash - I believe we used ProcDump from Microsoft Sysinternals Tools to gather this.
Once the dump was gathered, I opened it in Windbg to take a look.
We can see that the "OnShown" event of the Microsoft.Dexterity.Shell.NavigationForm is being invoked as Dynamics GP displays it (highlighted)
Then some ".NET stuff" happens which ends badly throwing an exception (KERNELBASE!RaiseException and highlighted also) and the error bubbles up from there.
Looking at source, it appeared that Dynamics was having an issue with one of the Navigation shell components (in one of the above links I offer Microsoft.Dynamics.Framework.UI.WinForms.Controls.dll as the file).
Not having seen any issues here before and not sure right off what exactly might be the issue, I wanted to take look at the file and found the it was loaded from the GAC and not the GP folder as is typical.
In the screenshot, we can see for the two Microsoft.Dynamics.Framework.* files; the ImagePath is the c:\windows\assembly folder which is the Windows GAC.
So yes, interesting. I checked my GAC and did not have that file there (as expected).
But I note the major/minor version of the assembly is the same is the same as mine though the build number is different 1.4.11166 vs 1.4.10877.03.
Looking in the GAC on the problem machine, we noticed several of the Navigation shell components loaded there.
As a test, we removed them from the GAC and tried launching Dynamics GP 2010 - this time it fired right up successfully.
Now we're getting somewhere.
So what are these files for?
These files are part of the "common" framework controls that the Dynamics family products share. What I had always assumed was that these were the same for all the products. That was incorrect - they share the same 'base' library but then each product modifies them as desired.
Ah - that makes more sense now. Since we know that Dynamics GP doesn't put files in the GAC, then we'd guess that AX/SL does. As it turns out, apparently these files are a bit 'incompatable' than what Dynamics GP is expecting and cause the crash.
Why does GP pull these files from the GAC when they are in the GP folder? Well, that is just how .NET works. There isn't any way to make it NOT pull a matching file from the GAC - even if the one we want is right in the same folder. Rats. One comment in one of the forum posts was that .NET should honor side-by-side of the different versions. But the problem is that the assemblies are all the _same_ version (1.4). Same name, signed by Microsoft, and have the same version number. So they look, smell, and taste the same.
The good news is that Dynamics GP 10.0 runs completely fine - the assemblies it is compiled against are v 1.0 and therefore aren't loaded by Dynamics.exe/.NET and so we don't have an issue on that version.
But at least knowing this we're in good shape - we just need to figure out a way to make all the apps work.
There are a couple of solutions.
The first one would work with GP & AX or GP & SL loaded together.
For this, we would actually move the assemblies out of the GAC and put them into application folders to the respective applications can find then.
In the files.zip attached - the move_ax.bat & move_sl.bat are simple batch files that move the "problem" assemblies from the GAC to the "proper" SL/AX local folders. You would need to modify the paths in the files to take account of your actual install folder(s). If I was a bit less lazy, I would re-write those as Powershell.
The easiest solution and the one I would recommend would be to just temporarily rename the files in the GAC, launch Dynamics so that it loads the versions in the GP folder, and then rename the GAC files back again.
In the files.zip file, the launch_gp.ps1 is a Powershell script that automates this for you.
To use it, make a new shortcut to Powershell (v1, v2, or v3 as you have installed - the example below is v 1.1)
The shortcut would be:
You can modify the file by using Notepad, PowerGUI, or the windows Powershell Editor to adjust your path to Dynamics or the sleep time (30 seconds currently) to a smaller delay.
Hope this tip helps!
Patrick RothSenior Escalation Engineer
You are awesome! Thanks for sharing this tip. I was scratching my head on this very issue for a while and your blog post came as a great rescue.
Hi Patrick, i can't find file Microsoft.Dynamics.Framework.UI.WindForms.Controls.dll in C:\Windows\assembly
when i check this file in GP folder this file is exist.
where i can find this file in C:\windows\assembly folder.
From Explorer you might not be able to see it, you might have to go to a command prompt and use the dir command. Or take the powershell code that I have in the zip file and you can modify it to show the files it finds and their paths.
Be careful. If you are trying to make GP, AX and SharePoint all work together, this fix will break SharePoint as it expects the UI.Navigation DLL to be in the GAC and does not care to read it from the INETPUB location that the bat fil copies it to. David may have an idea for a workaround??
You'll note that I offered this as a workaround also:
"The easiest solution and the one I would recommend would be to just temporarily rename the files in the GAC, launch Dynamics so that it loads the versions in the GP folder, and then rename the GAC files back again."
but this would work only if we had a GP/AX or GP/SL conflict.
If you were trying to make AX/SL work on the same box (I don't believe they will though due to this exact issue) then you wouldn't have a choice but to remove the files from the GAC so the crashing application no longer finds them.
So if the AX components in Sharepoint isn't reading that particular assembly correctly from the INETPUB folder, you would have to do some tracing to figure out _where_ it should be placed so the .NET can find it.
Easiest way to do this would be to use Process Monitor and then perform your operation.
Then look at the trace to search for the name of your file. You'll see a lot of "Not Found" type of errors as the runtime searches for the file. You should be able to copy the assembly into any of those folders so it can be found.
Thx, it works perfectly.
i am a developer and need to have both AX & GP on my machine
I tried your solution for my client mechine where AX and GP client has been installed, but the problem still exists.
Could you reply my problem. where i am going wrong?
I suggest you post on the forums (links in right hand pane) or log a support incident.
Blog comments are not the appropriate location for delivering support.
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.