Running Dynamics GP 2010, AX 2012, and SL 2011 on the same machine
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:
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe "c:\dynamics\gp2010\launch_gp.ps1"
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 Roth
Senior Escalation Engineer