I'm having problems migrating a PowerBuilder application from XP to Windows 7.
We've built the application in PowerBuilder on Windows XP, and when we attempt to install components in to component services on Windows 7 machines, we get compatibility errors. Everything works great on Windows XP. But I think because the DLL's on 7 are so different, it's having problems.
If the program was built using a PowerBuilder IDE in a Windows 7 environment, would that possibly fix the problem?
The application is divided into
- a server component running on Server 2003
- a client component which installs sucessfully on Win7
- proxy components that are generated into an MSI when the server components are installed.
The problem is only the proxy. The MSI doesn't want to work on Windows 7.
Without the proxy installed on the client desktops, the client can't communicate with the server.
When I run the MSI in compatibility mode on Windows 7, I get some details of the error. Here they are
Program Compatibility Issues found Incompatible Application Fix
application CCS_Proxy_XP_Exports
Issues found Incompatible Application CCS_Proxy_XP_Exports is
incompatible.
Fix application CCS_Proxy_XP_Exports Provides steps to fix the
incompatible application. CompatMode CompatMode UserVerifySolution
User Verification of Solution Verify_NO
Detection details Collection information Computer Name: ##########
Windows Version: 6.1 Architecture: amd64 Time: Wednesday, November
14, 2012 11:56:36 AM
Publisher details Program Compatibility Make older programs run in
this version of Windows. Package Version: 1.5 Publisher: Microsoft
Windows
Program Compatibility Make older programs run in this version of
Windows. Package Version: 1.0 Publisher: Microsoft Corporation
If I view more details on the event log, I get the following
“Product: Client Communications (Application Proxy) -- Error 1928.
Error registering COM+ Application. Contact your support personnel
for more information.”
General idea
Actually dll on the win7 platform are not different from previous ones. There can be differences related to the multiple and different C runtimes that live now in the WinSxS dll-hell directories but this should not impact powerbuilder (as I can say from my 11.5 classic release experience).
I suspect that you might have some problems related to the UAC and or ACL management. I recently upgraded some legacy PB applications by adding compatibility to the Vista / Win7 specifications.
In short : the application must run without needing administrative privileges, and must not try to modify data in privileged places like c:\ or c:\windows.
Thus everything must no more be installed in program files directory. The application binaries can be deployed in program files but if the application need to create / modify some files they must be deployed in a ProgramData subdirectory for user-shared datad and / or in the local user data files for the private data. The application has to be modified to create or find the files in the correct directories. If you do not comply to the standard, the file virtualization mechanism can hide a lack of rights and can simulate the files in a VirtualStore directory in the user local data but is just a workaround and it provides some other problems.
Com+ error
Given you error messages, if the proxy is also a PB application, given the fact that PB only produce 32bits binaries and that your system is a 64bits one, maybe that the tips to register a 32b COM+ onto a Win2008 could help you?
Thought, your proxy exe/dll file does not have manifest or manifest does not contains compatibility section. Try to add compatibility info to manifest.
Related
I'm installing WebSphere 8.5 for developers on my local computer, and I'm running into an error message A screenshot and the message is listed below.
http://imgur.com/DBAb4Gm
"To run an application without administrative privileges on the Windows Vista operating >system, you must install the application package into a directory that is not virtualized. >The Program Files directory on Windows Vista is virtualized. To run an application with >administrative privileges after it is installed, right-click the package, and click "Run as >administrator"."
I'm actually on Windows 8 (64-bit), so this is a bit odd. How do I defeat this error?
Hello,
Install it into non virtualized directory (so not into Program Files).
It's always the best to use the shortest path possible, when installing Java based stuff on Windows. I prefer C:\IBM\WebSphere\AppServer etc.
The System requirements page suggests WebSphere Application Server for Developers 8.5.5 being supports Microsoft Windows 8.
WebSphere Application Server 8.5.0.1 seems to have introduced Windows 8 support as well.
I'm using the Crystal Report 10 viewer ActiveX control in an Access App I've written. Works great in Office 2003 on 32bit versions of Windows. The problem arrises when I try to run the program in 64 bit Windows (with 32bit Office). I get the following error:
Run-time error '429': ActiveX component can't create object
I get this error on the following line of my VBA code.
Set rdApp = CreateObject("Crystalruntime.application.10")
How can I get this to work in 64bit?
I don't have any specific experience with Crystal Report, but I do have some experience with installing components on a 64-bit Windows environment that were intended for 32-bit Windows, so here are some general suggestions of things to try:
Before installing, try loosening the security privileges - I have Windows Server 2008; on this OS, they're under Start | Administrative Tools | Local Security Policy. Many old installers are thwarted by these controls. You'll want to return them to their defaults after the install.
Make sure that you run the installer with admin privileges (right-click; run as Administrator).
Examine the installation log for Crystal Report - it may indicate a failure registering a component. In one instance, I was able to get the installation working by running the command to register the failed component manually, on an administrator-privileged command line (the command was in the log).
If acceptable, try to create a Windows Virtual Machine running a virtual Windows XP, and try the installations there (this might be a bit tedious, due to your need for MS Office).
Take a look at VMWare's ThinApp - this is intended for packaging applications for administrators, but this was the solution we ended up using to shield one of our 32-bit apps from Windows 64-bit perils
Hope this helps; we struggled for awhile trying different things to get our legacy apps working on a 64-bit environment.
Background
We're using System Center 2012 to deploy a Windows 8 Metro-style application to Samsung slates in the field running Windows 8 Enterprise x64. The slates are joined to the domain and have a persistent DirectAccess connection back to it, allowing System Center to push applications and updates to the devices.
We have to deploy our application to potentially hundreds of devices in the field, which is why we went the System Center route. The code signing cert is installed on every device using Group Policy. To deploy the application, you simply provide the package output and specify the collection of devices to install it on. The app just shows up on the device in a few minutes.
The problem we're having is that when System Center deploys our application, the SQLite dependency is lost and none of our data access works.
About our project
Our application is a WinJS application that uses SQLite as a backend. However, all our data access code is in a C# WinMD project which the WinJS project references. We're using the sqlite-net library to talk to SQLite - we included the source for that in our C# project.
In Visual Studio, we installed the SQLite for Windows Runtime extension as described in Tim Heuer's article. The Metro application references this.
Testing using other deployment methods
SQLite data access from the application works fine when you debug or run it locally - in both Debug/Release and x86/x64.
The app packaging process provides a PowerShell script that you can use to install the application and a developer license if necessary. When installing our app using the PowerShell script, SQLite data access also works fine. Verified this by packaging and installing both Debug/Release and x86/x64 versions of the app.
Troubleshooting
When the application first tries to use SQLite, we see an exception about it not being able to find the sqlite3.dll.
We've tried/verified the following:
Confirm that we're deploying a Release/x64 build
Examine the appx in WinRAR and verify that it contains the sqlite3.dll
Reference the "SQLite for Windows Runtime" extension from the C# project instead of the WinJS project
Also reference the C++ runtime, this caused System Center to fail when deploying the app. Don't know why yet, but looking into it.
UPDATE
The issue is that System Center is having trouble deploying the Visual C++ Runtime Library dependency that the SQLite library needs. So unfortunately this isn't a programming question anymore. We're getting some help on this and I'll post the fix.
I wanted to post the details of a temporary fix that we're going with. We've also gotten closer to the root of the problem, so I wanted to provide those details as well.
Recap of Issue
When referencing the Visual C++ Runtime Package from our Metro project, System Center is unable to deploy the application to the devices because there is a problem deploying the proper version of the dependency for the appropriate architecture and build flavor.
Our development machines running Visual Studio 2012 (and packaging the project for deployment) are using a newer version of the Visual C++ Runtime (50727) than what is available in a fresh installation of Windows 8 (50712).
Worked with the System Center team and confirmed that this was a bug in the version we were using and has already been addressed in future builds. We're going to work on upgrading the environment but that will take a couple of weeks.
Workaround
I confirmed and tested the following workaround:
Remove the reference to the Microsoft Visual C++ Runtime Package from the Metro project
Install the x64 version of the Visual C++ Redistributable for Visual Studio 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=3
Deploy the application
Works like a charm because the correct version of the dependency is there already. Obviously not a long term solution if we choose to also target x86 and ARM, but will get us over this hump.
My company has a VB6 application using Crystal Reports 7 which a client has asked to be installed on Windows 7 32 bit. It is currently installed on Windows XP 32bit SP2 machines at the client. Connection to the DB is done via ODBC to SQL Server 2000 instance on another server.
On Windows 7, the installation works fine, however when you try to open the application, the error is given.
I have looked at the following:
Registering all the dll's and ocx files using regsvr32. Some will not register as they either are registered already or the following message is given "Make sure that "[name].dll" is valid DLL or OCX file and then try again." I read this forum thread regarding this: http://social.msdn.microsoft.com/forums/en-US/vblanguage/thread/0653f685-4526-45d9-89f3-8c479a6b4c62
Monitored the opening of the application using a ProcessMonitor application to try and spot if there is a missing dll or ocx file - this does not seem to be the case.
Reviewed the application according to this list and nothing seems to be against these guidelines
I've noticed two items in the knowledge base that relate to this
http://support.microsoft.com/kb/281848 - the comdlg32.ocx bundled with the application is version 6.0.81.69 and the one in the system32 folder on the dev machine (WinXP 32 bit) is 6.1.97.82. However if this was the issue then surely it would not work currently?
http://support.microsoft.com/kb/184898 - I'm not sure how to confirm that this is the issue
Finally, due to complexities, I am not allowed to make code changes to this application. Even if I was, I'm not a VB6 programmer, just the guy who got the terribly support project! If code changes are required, then I'll have to investigate using WinXP mode.
Update: I get the same error in XP Mode. That's a Win XP with SP3 VM. This runs on a Win XP SP2 VM, is there potentially something in SP3 that would have caused this to occur? Or is it just a fact of it being XP Mode?
I got the same error but I solved by using regsvr32.exe in C:\Windows\SysWOW64.
Because we use x64 system. So if your machine is also x64, the ocx/dll must registered also with regsvr32 x64 version
The file msrdo20.dll is missing from the installation.
According to the Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7 this file should be distributed with the application.
I'm not sure why it isn't, but my solution is to place the file somewhere on the machine, and register it using regsvr32 in the command line, eg:
regsvr32 c:\windows\system32\msrdo20.dll
In an ideal world you would package this up with the redistributable.
This download fixed my VB6 EXE and Access 2016 (using ACEDAO.DLL) run-time error 429. Took me 2 long days to get it resolved because there are so many causes of 429.
http://www.microsoft.com/en-ca/download/details.aspx?id=13255
QUOTE from link:
"This download will install a set of components that can be used to facilitate transfer of data between 2010 Microsoft Office System files and non-Microsoft Office applications"
You say it works once you install the VB6 IDE so the problem is likely to be that the components you are trying to use depend on the VB6 runtime being installed.
The VB6 runtime isn't installed on Windows by default.
Installing the IDE is one way to get the runtime. For non-developer machines, a "redistributable" installer package from Microsoft should be used instead.
Here is one VB6 runtime installer from Microsoft. I'm not sure if it will be the right version for your components:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7b9ba261-7a9c-43e7-9117-f673077ffb3c
I have a visual studio solution with an ASP.NET 3.5 web application (WCF host) and a test project. I wanted to use the Oracle Instant Client (v11, via NHibernate) to create Oracle connections without having the Oracle client tools installed on every "involved" machine (dev, CI server, test server, production server).
The weird thing is that on my development machine (x86) my tests run without problem, while my web application still gives me the following error message: System.Data.OracleClient requires Oracle client software version 8.1.7 or greater
Things I ruled out already:
The bin folder has read & execute permissions for everyone
The DLL's are unblocked (windows 7)
Problem occurs with both Visual Studio Development Server and IIS 7
I've also tested this on a machine with Oracle client tools installed and that works
I even managed to get the tests running on our x64 CI server (more info).
Anyone has a clue on what I am missing?
I see this error almost every time I set up Oracle on a new machine.
Check that the oracle bin folder is in your path
Give read and execute permission to everyone on the client folder (on my machine C:\oracle\product\10.2.0\client_1)
Changing permissions may not take effect until you reboot your machine.
EDIT:
From your comment, steps 2 and 3 are irrelevant for Oracle Instant Client. Hoverer, I would guess that the problem is still that the system cannot find the Oracle Instant Client DLLs. It would be worth putting the location of these DLLs into your path and seeing if this resolves it.
From http://www.oracle.com/technetwork/database/features/instant-client/index-100365.html
Installation Instructions
Installation Steps:
Download the appropriate Instant Client packages for your platform. All installations REQUIRE the Basic or Basic Lite package.
Unzip the packages into a single directory such as "instantclient".
Set the library loading path in your environment to the directory in Step 2 ("instantclient"). On many UNIX platforms, LD_LIBRARY_PATH is the appropriate environment variable. On Windows, PATH should be used.
Start your application and enjoy.