MQ client 7.5 is already installed on machine and is primary. Then installed MQ client 9.1.4 but didn’t make it primary so now this machine has both clients where 7.5 is primary.
Name: WebSphere MQ
Version: 7.5.0.6
Level: p750-006-160226
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Windows
Mode: 32-bit
O/S: Windows Ver 6.2 (7) Server Standard x64 Edition, Build 9200
InstName: Installation1
InstDesc:
Primary: Yes
InstPath: C:Program Files (x86)IBMWebSphere MQ
DataPath: C:Program Files (x86)IBMWebSphere MQ
MaxCmdLevel: 750
Name: WebSphere MQ
Version: 9.1.4.0
InstName: MQ9client
InstDesc: mq9.1
InstPath: C:Program FilesIBMMQ9Client
Primary: No
We want to keep 7.5 as primary while we migrate applications to 9.1.4 one by one. For that I created the following environment variable and also added entry in config file of my applications.
Environment Variable
DEVPATH
C:Program FilesIBMMQ9clientbin
Config Entry
<runtime>
<developmentMode developerInstallation="true"/>
</runtime>
After that I changed my applications to start using MQ 9.1.4 BUT there is a problem and that is only desktop applications are working fine while all web based application in ASP.Net are throwing this error:
The type initializer for 'IBM.WMQ.Nmqi.UnmanagedNmqiMQ' threw an exception
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Whether I use IISExpress or IIS the issue happens with both. Any idea why desktop based applications work but not web based?
Stack Trace
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
at System.Reflection.Assembly.CreateInstance(String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
at IBM.WMQ.Nmqi.NmqiEnvironment.GetInstance(String name)
at IBM.WMQ.Nmqi.NmqiEnvironment.GetMQI(Int32 id)
at IBM.WMQ.MQQueueManager.Connect(String queueManagerName)
at IBM.WMQ.MQQueueManager..ctor(String queueManagerName, Hashtable properties)
at WebApplicationNewMW.Middleware.CreateQueueManager() in c:DocumentsVisual Studio 2013ProjectsWebApplicationWebApplicationMiddleware.cs:line 43
at WebApplicationNewMW.Default.Page_Load(Object sender, EventArgs e) in c:DocumentsVisual Studio 2013ProjectsWebApplicationWebApplicationDefault.aspx.cs:line 17
at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
at System.Web.UI.Control.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
has context menu
4
Assuming that the C# .NET code being invoked through IIS is similar to the code running natively, then the difference will most likely be due to differences in:
- Build options
- Runtime environment (maybe the difference in static vs dynamic binding)
In which case, the answer to this question – The type initializer for ‘IBM.WMQ.Nmqi.BindingsNmqiMQ’ threw an exception
may resolve your issue.
In essence when running under IIS, you may have some MQ v7.5 assemblies in the .NET Cache (GAC) that are interfering with the 9.1 assemblies.