We are using MQ Client ver 7.5.0.5 (64 bit), now want to migrate to ver 9.0(64 bit).
Downloaded installer from here.
With that said, I would like to ask below:
App was compiled against ver 7.5.0.5; To enable the app to work with ver. 9.0 MQ client Installation does it need to be compiled against 9.0.?
MQ Client ver. 7.5.0.5 works with .NET framework 4.0. I guess MQ Client ver. 9.0. also works with .NET framework 4.0, right?
I searched IBM Site, but I didn't get pages explaining the above compatibility info. I might have not found if any pages explaining the above. If you know, could you give a link?
I think you are asking about .net apps, so my answer expands on that, but for things like C applications, they also should just work.
When you compile against 7505, you build in a dependency on the 7.5.0.5 version of amqmdnet for example. However MQ also ships policy files to indicate the newer versions or fix packs support the functionality of that one, and hence it should run without change on v9
Yes, MQ supports .net framework 4 the same as 7.5.0.5 and should work seamlessly, assuming it worked at 7.5
As an example I ran the 7.5 simpleput.exe sample against a v9 primary install and it just worked. (Although it looks like that sample is built with pre-.net 4, I dont have a .net 4 sample built against 7.5 to hand)
To confirm it really is linked against 7.5.0.5 (bear in mind older pre-7.1 releases all have 1.0.0.3 as the version), you can use ildasm.exe simpleput.exe, look in manifest:
.assembly extern amqmdnet
{
:
.ver 7:5:0:5
}
In the GAC you have a policy file: gacutil /l | findstr /i amqmdnet
policy.7.5.amqmdnet, Version=9.0.0.0, Culture=neutral, ....
I dont know of any compatibility document like that other than the MQ Statement of operating environments (SOE) stating support for .net 4.
Related
I have a task to update 8.5.5.2 web sphere to 8.5.5.14 on a windows 2008 server. I have java 1.7 already installed (and java 6 as well) and all the profiles uses it.
How ever when i try to apply fix patch using IBM installation manager, by default it's installing Java 8 which is not supported on windows 2008.
Is there a way where i can by pass java 8 and install only the fix patch (8.5.5.14) from installation manager.
Any pointer/help would be really appreciated. Thanks.
Installation Manager Screenshot:
No, WebSphere 8.5.5.14 requires Java 8, and Java 8 is not supported on Windows 2008 Server. If you must stay with Windows 2008 you can't update WebSphere past 8.5.5.13. More detail here: IBM WebSphere SDK Java Technology Edition 8.0 Minimum Supported Operating Systems
This is what IBM documentation ( https://www-01.ibm.com/support/docview.wss?uid=swg27045339 ) says, I did some shortcuts to make key points easier to notice in a long article:
In 8.5.5.14 and later, it is planned that (Java8) SDK will be required for all new installations and all updates (fixpacks).
In 8.5.5.14 (...) prior operating system releases (such as Windows 2008 (...) ) will no longer be supported.
So unfortunately what you are trying to do is not supported:
Although Java7 is still fine as a runtime environment for your servers, for example if your business application is not yet Java8 compatible, you need to have Java8 installed as a default JVM for Websphere 8.5.5.14 "internal" requirements.
You cant have IBM's Java8 installed in Windows2008, which is mandatory for Websphere 8.5.5.14, that means you cant install Websphere 8.5.5.14.
In the end, I would like to remind you, that you can upgrade to a previous release: 8.5.5.13. Version 8.5.5.13 is 11 fixpacks newer than what you already have, maybe it will suffice for your needs.
Bottom line - upgrade windows to a current version that's not 11 years old. Or, better yet, put it on Linux. WAS is great on Linux! Red Hat, Suse, OpenSuse, Fedora, CentOS are good flavors.
I am working on an internal tool for our product. Our product uses oracle database and have evolved over time from .net framework 2.0 to 4.5 and Oracle 10 to 12.2.
The aim of the tool is to write a single application which works across different versions of the product.
I have solved the problem of multiple .net framework versions by using the following entries in app.config
<supportedRuntime version="v2.0.50727"/>
<supportedRuntime version="v4.0"/>
As the oracle managed .net driver is supported for framework >=4.0, I can not use this as I have to support .net framework 3.5 also.
As I have to use unmanaged odp.net driver, I was thinking about the following scenario
My tool would use the lowest version of oracle.dataaccess.dll and target .net 3.5.
Following #1 above makes me refer to 2.xx.... version of the oracle.dataaccess.dll.
When I run this application on a machine with only .net framework 4 installed, what would be the behavior? Would it load 4.xx... version of oracle.dataaccess dll when running under the context of .net framework 4?
The best solution for this would have been availability of oracle managed driver for .net 3.5 version but I found that it is not available.
Please provide your valuable inputs.
Satish
UPDATE :
I have written a sample application targeting .net framework 3.5. In this sample app, I will build a connection string and just open a connection and close it.
This application runs successfully when there are no <supportedRuntime> tags in the app.config.
When we add any <supportedRuntime> tags in the app.config, I am getting a type initializer exception for oracle related types. I have tried this with the supported run time tags
<supportedRuntime version="v2.0.50727"/>
<supportedRuntime version="v4.0"/>
individually and both combined. But I am still getting the issue. Can anyone suggest how to resolve this issue?
ODP.NET unmanaged driver exist in following versions:
1.x (.NET Framework 1.0.3705/1.1.4322), available up to Oracle Client 11.1.
2.0 (.NET Framework 2.0.50727), introduced with Oracle Client 10.2
4.0 (.NET Framework 4.0.30319), introduced with Oracle Client 11.2
If your compile target is .NET version 3 or 3.5 then the application will try to load ODP.NET version 2.0 (and will raise an exception if it is not found on the machine). Actually I am not sure if it would also accept ODP.NET version 4.0.
If your compile target is .NET version 4 or higher then the application will try to load ODP.NET version 4.0 (and will raise an exception if it is not found on the machine).
You can do several solutions:
Provide a copy of Oracle.DataAccess.dll which matches your version and put it in your application directory.
Use late binding, i.e. instead of
var con = new Oracle.DataAccess.Client.OracleConnection();
use
var DLL = Assembly.Load(String.Format("Oracle.DataAccess, Version={0}.{1}.*.*, Culture=neutral, PublicKeyToken=89b483f429c47342", frameworkVersion, oracleVersion));
var type = DLL.GetType("Oracle.DataAccess.Client.OracleConnection", true, false);
dynamic con = Activator.CreateInstance(type)
However, this syntax is only available from .NET Framework version 4.0 on, I do not know how to write this in version 3.0/3.5.
Note, use con.GetType().Assembly.FullName and con.GetType().Assembly.Location in order to see which DLL was really loaded.
We have a number of Installshield projects that install and configure IIS applications. We have shipped several versions of the different applications (over 7 versions of 3 applications) and would now like to upgrade to use .net 4.0 instead of 2.0 & 3.5.
After modifying the "Internet Information Services" settings to change the ASP.NET Version on the web sites/application to 4.0.30319 and the .Net Framework version to v4.0 under the application pool, the installer correctly creates an application with the 4.0 version in IIS 6 and below, and in IIS 7 and above it correctly sets the pool to use v4.0, but upgrades do not work for any targets.
The upgrades install OK, but the .Net version of the virtual directory or application pool remain unchanged. Changing it manually works of course, but this would lead to increased support issues.
I have tried changing the upgrade to be a major upgrade, with no success, I am currently working on a custom action to change the .Net version after installation, but I don't have much experience with this feature of Installshield.
Has anyone experienced this issue? Are there any preferred ways of achieving this? (custom actions, or a .Net installer class, WIX is not an option)
Thanks
Without spending hours to dig into it... one quick solution would be to rename the app pools in your new installer and let a major upgrade create the new and remove the old. After all, if you are changing from .NET 2.0 to 4.0, in a sense you are creating a component that is not backwards compatible and thus should be a new component.
I am developing a Windows CE application which uses some libraries provided by other parts of our company.
When I deploy my application on "My Computer" (.NET compact application running on standard PC), everything works, but when I deploy to the device, the application hangs when trying to use methods from the library. The system also hangs. My Visual Studio 2008 sometime hangs, but sometime throws an exception "TypeLoadException: Could not load type from assembly Culture=neutral, PublicKeyToken=nu".
I couldn't include .NET Compact framework 3.5 because the image wouldn't compile, so I am using version 2.0. I use Visual Studio 2008 with deploy .NET framework option.
Most probably the problem is with version of the library you are using. Please cross check it.
Hope this link will help you.
I'm a bit confused.
First of all, what are the libraries "provided by other parts of [y]our company" build against? Are they Compact Framework assemblies (they must be)? What version of the Framework were they build against? Reflector can tell you this if you don't know.
Second, why can't you compile it with 3.5? What sort of errors are you seeing? The code should be 100% forward compatible, so if it won't build, there's a red flag going up.
Lastly, what version of the CF is installed on the target hardware? FOr example, are you trying to push a CF 2.0 app to a device with CF 3.5 already installed? If so, do you have an app.config file that provides the framework compatibility options so it knows it can run your assembly?
The problem was that libraries were compiled with for 3.5 target framework, and the application which uses them form 2.0 framework. In that case, 3.5 framework wasn't depoloyed and application would stop working as soon as call to the library methods was made.
Yesterday, I've downloaded and install the free trial version of WAS v7. The version I've downloaded is 7.0.0.9 but I need to certify my application against 7.0.0.3.
Where can I get this version?
UPDATED: It turns out that what I really needed was WebSphere Application Server for Developpers
It's working!
Now it can be downloaded from HERE
This link provides a Windows or Linux version of WebSphere 7.0.0.0 for development testing.
WebSphere Application Server for Developers V7
This link provides Fix Pack 3 for Windows (a Linux version of the fix pack is also available.)
WebSphere Application Server V7.0 Fix Pack 3 for Windows