I got an very basic test.asp page that needs to run on a 64-bit server
first i tried
<!--METADATA TYPE="TypeLib" NAME="Microsoft ActiveX Data Objects 2.5 Library" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" VERSION="2.5"-->
<%
.... more code
does not work (even though i found the reference in COM)
the i try
<!--METADATA TYPE="TypeLib" NAME="Microsoft ActiveX Data Objects 2.8 Library" UUID="{2A75196C-D9EB-4129-B803-931327F72D5C}" VERSION="2.8"-->
<%
... more code
this works ,, but why can't i reference the 2.5 version when the library exist on the server?
Josip is nearly correct MDAC 2.5 is only 32 bit (2.8 has a 64 bit flavour). By default on 64 bit server your application pool will run using 64 bit processes. It will be looking in the 64 bit version of the system hive for the 2.5 type library reference but won't find it (its only in the 32 bit version).
If you edit your application pool settings so that it runs as 32 bit you should find the 2.5 reference will work.
MDAC is available only on 32-bit.
You must change your application to target x86 (by default it targets AnyCPU). It will still run on x64 but with smaller memory space.
Related
I'm writing a Qt application for windows, and using windows 7 64 bit.
The application has to write to the registry, I tried to use QSettings class, but as I found in the documentation:
On Windows, for 32-bit programs running in WOW64 mode, settings are
stored in the following registry path:
HKEY_LOCAL_MACHINE\Software\WOW6432node\MySW
Is there a way to override it and write to: HKEY_LOCAL_MACHINE\Software\MySW directly?
Clarification:
The application is writing to the registry, the keys written are to be used by other application, which I cannot know if running on 64 or 32 bit mode.
I know it is possible in C#, so it must be possible in C++.
See this article on MSDN:
32-bit and 64-bit Application Data in the Registry
It appears that using some of the Win32 API you might be able to change how this behaves. Although I'm not sure why the default behavior won't work for you.
I suppose that if you want to do it in Qt then this would be the most appropriate way:
[ Source: http://doc.qt.digia.com/4.7/qsettings.html#accessing-the-windows-registry-directly ]
Accessing the Windows Registry Directly On Windows, QSettings lets you access settings that have been written with QSettings (or settings in a supported format, e.g., string data) in the system registry. This is done by constructing a QSettings object with a path in the registry and QSettings::NativeFormat.For example:
QSettings settings("HKEY_CURRENT_USER\\Software\\Microsoft\\Office", QSettings::NativeFormat);
All the registry entries that appear under the specified path can be read or written through the QSettings object as usual (using forward slashes instead of backslashes).For example:
settings.setValue("11.0/Outlook/Security/DontTrustInstalledFiles", 0);
I get the following error with a legacy asp application that I have been asked to help out with.
Server object error 'ASP 0177 : 800401f3'
Server.CreateObject Failed
/site_manager/image_upload.asp, line 27
800401f3
The line ofcode that throws the error is shown below:
Set fbase = Server.CreateObject("chili.upload.1")
As you ahve probably guessed oldschool asp isn't my strong point but from the research I have done it seems as if a component hasn't been registered on the server (I only have FTP access).
What component needs to be regsistered?
Thanks for the help...
You're missing the registration of the DLL that creates the chili.upload.1 object. Are you trying to run this on a Linux machine?
You need to register the Sun Chili!Soft ASP components. Here's the manual on this from 2003:
http://ns7.webmasters.com/caspdoc/html/running_the_setup_program_sun_chili_soft_asp_for_windows.htm. Note that this only works if you still have the original setup. Otherwise you're out of luck. Sun Chili!Soft ASP is no longer available and very, very dead.
If you're just interested in file upload functionality on ASP, I can recommend Free ASP Upload. It requires no registration of any components and generally works. I can also recommend this article on the topic of ASP uploads. If you're willing to shell out some money there are hundreds of components that do the same thing too.
Register the DLL on your computer, and then do this:
Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\
FeatureControl\FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701
Note If the FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701 subkey does not exist, you must manually create it. If you're using a 64 bit OS, you may need to use HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\ FeatureControl\FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701 instead
Right-click FEATURE_IGNORE_ZONES_INITIALIZATION_FAILURE_KB945701,
point to New, and then click DWORD Value
Type w3wp.exe to name the new registry entry, and then press ENTER.
Right-click w3wp.exe, and then click Modify.
In the Value data box, type 1, and then click OK.
After setting this registry key, a simple app pool restart will apply the change. No longer will your .NET COM components randomly stop working with no real solution except shuffling application pools!
Brief Summary:
We are using Tridion 2009 SP1, however we never used .NET templating, we are still using R5 concept i.e. (VBScript, XSLT etc), we are using broker database for our linking etc.
Our Tridion Server/Presentation Server/services are running perfectly on 32 bit environment/mode, our IIS is running on 32 bit mode. Everything is running perfectly.
Problem:
We recently decided to move all our server to 64 bit mode, so now everything moved to 64 bit (IIS, Tridion Server/Services etc), everything is working perfectly except the Component Links. Due to that we again moved our Tridion services to 32 bit mode as well as IIS to 32 bit mode and then component links start working
Error:
When all the things are running on 64 bit mode, we are getting component link resolving error and getting below error when it trying to resolve the component.
Error Failed to resolve component uri tcm:233-218990 while called from ComponentLink.ResolveLink on /english/index.aspx
... EGIT.CCIT.Tridion
... Object reference not set to an instance of an object.
... at EGIT.CCIT.Tridion.COM.ComponentLink.GetLink(String pageURI, String componentURI, String componentTemplateURI, String attributes, String text, Boolean textOnFail, Boolean anchor)
... at EGIT.CCIT.Tridion.Broker.LinkResolver.ComponentUrl(String pageUri, String uri, String componentTemplateUri, String publicationUri)
...
09:50:58.90 Error Error in Core Tridion call
... netrtsn
... Attempt to load JVM failed on native side
... at Codemesh.JuggerNET.JvmLoader.Load(Boolean bAcceptPreloaded)
... at Codemesh.JuggerNET.JvmLoader.Load()
... at Codemesh.JuggerNET.JavaClass.init()
... at Codemesh.JuggerNET.JavaClass.get_JObject()
... at Codemesh.JuggerNET.JavaMethod.init()
... at Codemesh.JuggerNET.JavaMethod.get_MethodPtr()
... at Codemesh.JuggerNET.JavaMethod.get_Handle()
... at Codemesh.JuggerNET.JavaMethod.CallObject(JavaProxy jpo, JavaMethodArguments args)
... at Com.Tridion.Linking.ComponentLink..ctor(Int32 publicationId)
... at Tridion.ContentDelivery.Web.Linking.ComponentLink..ctor(Int32 publicationId)
... at EGIT.CCIT.Tridion.COM.ComponentLink.GetLink(String pageURI, String componentURI, String componentTemplateURI, String attributes, String text, Boolean textOnFail, Boolean anchor)
Please suggest!!
Thanks.
Best Regards,
Manu
Manu,
You can use VBScript templates (thought it is a good idea to start moving off this platform anyway) in your CMS backend and 64-bit on the front end, if your front end is .NET or Java.
What you cannot do is use COM on the Front-end (even if being called from .NET) and be on 64 bit, since the Tridion COM-based linking API is 32 bit only.
The .NET linking libraries and the Java linking libraries are 32 and 64 bit compatible, but not the COM libraries.
Hope this helps
N
Which version Java did you install on the presentation server? Is it 64-bit? Try the 32-bit version of Java. Otherwise try the 64-bit version.
Going mad here.
I'm new to windows dev and I have registered my dll in the GAC.
I get a message saying "Assembly successfully added to the cache" and I can do a
Gacutil /l "its name" and see it there
But when I try to instatiate it in Classic asp like so:
Set TemperatureComponent = Server.CreateObject("comInteropTutorial")
I keep getting the error:
"Server object: 006~ASP 0177~Server.CreateObject Failed~800401f3"
which I believe means it can't find it?
I have also tried to do the same things for other components that were already in the Global cache like:
Set TemperatureComponent = Server.CreateObject("XamlBuildTask")
and the same thing happens.
Before adding the dll to the GAC, I did the following:
I compiled the dll in Visual studio 2010 and did the following:
Click on project
Application - sign the assembly
Build - register for Com interop
Signing - sign the assembly use a file that you have created using sn command (sn –k )
I'm truely stuck now, can someone recommend anything?
I'm on windows 7 here, dunno if that matters... 64 bit 32 bit etc?
I'd happily step through a process that helps me determine the cause of this problem if anyone can recommend one?
Looks like it is answered in another post: Accessing a .NET Assembly from classic ASP
...make sure your .Net assembly is set to
be COM Visible.
In Visual Studio, does the component show up in list of objects under the 'COM' table if you try to add it as a reference? Does the assembly depend on other assemblies or DLL's?
Just a guess here, sounds like either the regasm step is missing which adds the appropriate stuff to the registry, or in my case recently, IIS was running in 64bit, but the assembly was compiled for 32bit.
We are facing problem in checking output parameters for “DBNull”. “DBNull” value returned by Oracle stored procedure or function is treated as “null” string by oracle 11g client/ODP.Net provider. This works fine with oracle 10g client as it returns “DBNull”.
Because of this all our “DBNull” check fails
ODP.NET RETURNING "NULL" STRING WHEN THE VALUE IS NULL [ID 968857.1]
Modified 04-JAN-2010 Type PROBLEM Status PUBLISHED
In this Document
Symptoms
Changes
Cause
Solution
Applies to:
Oracle Data Provider for .NET - Version: 10.2.0.2.20 to 11.1.0.7.10
Microsoft Windows (32-bit)
Microsoft Windows x64 (64-bit)
Symptoms
After migrating from a previous version of Oracle Data Provider for .NET, a change in behavior may occur with respect to null values being retrieved. Whereas the application previously returned an empty string, a string with the value "null" is now obtained.
Changes
Migration from 1.x ODP.NET to 2.x ODP.NET
Cause
The behavior is due to a migration from the 1.x Oracle Data Provider for .NET to the 2.x provider. 2.x ADO.NET supports the ability of the provider to return provider specific types, and this is one of the potential "breaking changes" going from .NET 1.x to 2.x.
ODP.NET versions 9.2.x, 10.1.x, 10.2.0.1.0 were all 1.x framework providers. Typically this behavior is noticed when migrating from an early version ODP to a newer version of ODP, but at the same time swtiching from the 1.x provider to the 2.x provider. It is the change in .NET framework support rather than the change in Oracle client version that causes this behavior.
This behavior may also be noticed migrating the application to a 64 bit operating system, as there is no 1.x 64 bit framework.
Solution
To resolve this behavior, the code will need to be modified.
As a workaround, using ODP.NET for 1.x (1.111.7.0 for example instead of 2.111.7.0) will result in the previous behavior, but note that the 1.x provider is not tested or supported on any version of framework other than 1.x, and that support for 1.x is not planned for any version later than 11.1.0.7.0
If the operating system is 64 bit, the application will need to be forced to run under the SYSWOW64 subsystem (ie, as 32 bit) in order to use 1.x ODP.NET.
To correct the code:
If the value is a DbType, you can check for param.Value==DbNull.Value
If the value is an OracleDbType, you can check for ((INullable)param.Value).IsNull since Oracle Types inherit INullable interface.
Following the breaking change that Oracle released (see comment below). You need to add the additional bit below:
if (oraParam[7] == null ||
oraParam[7].Value == DBNull.Value ||
((INullable)oraParam[7].Value).IsNull)
INullable is in the Oracle.DataAccess.Types namespace.
Or you can try...
(OracleString)result == OracleString.Null