I am trying to get the PowerBuilder 10.5.2 sample web services application running. I can open the workspace just fine, and I can see the objects and even run the app but I get a "bad runtime function reference" error when I try to invoke the service.
I believe I have installed all the requisite parts:
PB 10.5.2
.Net 2.0 SDK
Web searches reveal that some of the web services used by the sample app are defunct, but I can't imagine all of them are, so the error seems to indicate a problem with the setup or objects, not the third party services.
I can see pbwsclient105.pbd in the workspace list and in the Sybase shared objects directory. However, as a test, I tried to use the alternative method the documentation listed for setting up the PB proxy to the .Net web service objects (by importing PB extensions from pbwsclient105.pbx) and got a "invalid dll error" so perhaps my web service libraries are corrupted?
What else could be missing? Path settings? Incorrect .Net 2.0 SDK installation?
* * * Edit: Problem Solved - at least on my machine(s) * * *
I took a cue from the thread I found here and began examining what was happening with PowerBuilder when these errors occurred -- both during the import of the PBX and during runtime if you executed the sample application.
One person in the thread mentioned the issue was related to libeay32.dll and ssleay32.dll. This is not the first time OpenSSL has given me fits with these components -- my hard drive is littered with them in various application folders. These DLLs get loaded by PB when the PBWSCLIENT105.PBX extension is imported or by an app using the associated PBD at runtime. Sure enough, by using ProcMon, I was able to confirm that libeay32.dll and ssleay32.dll were being loaded from Windows\System32 as opposed to the version of the same DLLs located in the PB folder structure. Apparently, this is a problem. I renamed the two DLLs located in System32 to effectively remove them, fired up PB and the import of PBWSCLIENT105.PBX worked like a charm.
I have a similar issue with our PB 10.5 installation. Importing the PBX file gives me the error message:
---------- Import PB Extension:
Importing C:\Program Files\Sybase\Shared\PowerBuilder\pbwsclient105.pbx - Error: The file is not a valid dll or pbx file.
---------- Finished
I initially thought the issue was that the files were corrupt, etc. However, I installed PB 10.5 on a clean machine (a VM actually) along with the .Net 2.0 SDK and the import worked flawlessly; also, I was able to call a web service. Every developer in my group has the same problem on their own machines, but if they use a "clean" machine or VM with PB installed (and perhaps a few other apps), the import of the PBX file works without issue.
At this point I am trying to pin down what in the environment causes the problem, but haven't been able to yet. What's interesting, as you've noted, is that if you open the sample application, you can see the exact same imported libraries present; however, you get the error at runtime. All of this really points to something environmentally missing or incorrectly registered. So, if you have the ability to use a VM, I recommend that as a temporary work around.
One thing I'll add here: if you happen to use Vista or Windows 7 as your VM, the import of the library works fine, but I had issues generating the client-side proxy using the .Net web service engine. I finally discovered that in the background, the SDK tool WSDL.exe is being executed against the WSDL for the service in order to produce a .Net client-side proxy. Turns out that Vista/Win7 User Access Control was preventing WSDL.EXE from running. I ran PowerBuilder "as Administrator" and everything worked as expected in terms of generating the client-side proxy.
If you discover anything about why the PBX import doesn't work, I'd be interested in hearing about it!
Related
I'm trying to call to my unmanaged dll from my asp.net mvc web app.
when I call this dll from localhost it work just fine.
when publish the app to azure and try to call this dll I'm getting this:
Error:System.DllNotFoundException: Unable to load DLL 'SerenityConfigCodec.dll': A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A).
I succeed to call to a simple dll in azure (not mine). According to Microsoft azure documentation.
I use a dependency walker on my dll to know the dlls that I need in azure and add them.
I have some theory that my dll need some extra dll in azure that dependency walker not tell me about them.
Or maybe I need to connect my website to iis and try to use iisreset to cause maybe the .bin folder in azure get into locked at run time and let iisreset unlock it.
Sounds like Azure cannot find your referenced DLL.
Is this DLL added as a Dependency in your project? or as a Nuget package?.
If it's a Dependency there two possible solutions depending on your publishing method:
Add the Copy Local to True if you are publishing using Web Deploy (Right-click > Publish from Visual Studio)
If you are publishing through Continuous Integration and a link to a repository (GitHub / Bitbucket / VSO / etc), add the DLL file to your repository (maybe in a folder especifically for that) and reference it in your project using that folder path.
If it's a Nuget package, it will fail if you are using Web Deploy (unless you set the Copy Local to True), if you are deploying through Continuous Integration, Kudu takes care of downloading all the packages on the deployment process.
I solved this problem by adding the compiled unmanaged DLL file to the managed project, so it would be included in the publish package. Since the added file was either the debug or release DLL I had to manually edit the .csproj file to conditionally copy either the debug or release build DLL depending on if I'm building the debug or release managed DLL. This in turn generates warnings every time I load the project but the builder handles it right. And I need to remember to rebuild the managed DLL to get it to pick up on changes to the unmanaged DLL since it hasn't been doing that for me automatically.
Depending on which version of VS you're using you may need to install the C++ runtime DLLs as well.
The 0x8007045A error indicates that the DLL was found but init failed, while the 0x8007007E error mentioned an a comment to another answer indicates that it couldn't find the DLL to load.
We have an MSI to install windows service on client machine.
Windows service calls the web service of our server to perform operations.
Initially both the MSI and web service were built using .NET 2.0 framework.
Last quarter we upgraded our systems to .NET 4.0. Though our web service is still ASP.NET i.e. asmx (and not WCF). Also I did set framework 4.0 as the prerequisite for MSI to install.
One of our clients reported this issue:
Client was using .NET framework 2.0, and had the older version of MSI installed in his system.
When he tried to installed the .NET framework 4.0 version of the MSI, was prompted to install framework 4.0 (because of the prerequisite). Once the framework installation finished, he tried to install the MSI and got this error. Can someone please guide me to the resolution. I can provide details if needed.
EDIT 1:
On more research, I found it is my AppName.installstate file. Uninstall removes this file, but upgrade does not do it. The file is lying in the install directory. On a closer look I can see "http://schemas.xmlsoap.org/soap/envelope/:Envelope" in the file contents. Any pointer would be greatly appreciated.
EDIT 2:
Custom action Install creates AppName.installstate file and custom action Uninstall deletes the file. In my case, I am doing an MSI upgrade which does not do anything to this file. When I compared the installstate file from 2.0 and 4.0 (both installed manually), I could see a huge difference in the XML syntax, schema and contents, the reason, I am getting serialization error. Now I need to know why AppName.installstate is not getting overwritten when upgraded. Doing lot of google, but landing nowhere.
Looked at MSI install log, but no useful information.
Eureka !!!!
I found solution to my problem.
Root cause of the problem:
MSI generates an XML file during installation (application_name.installstate), which stores information MSI uses during install, uninstall, rollback. The format of this XML file is completely different between .NET 2.0 and .NET 4.0 i.e. MSI developed using VS2005 and VS2010.
Because 4.0 frmaework is not able to understand the file generated by Old Framework version (2.0), we are getting the error saying “Not able to serialize the Type of the Installstate file”.
Though there is no documentation available online for this, there is this discussion I found > http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/bedbb8bd-dad5-4bcb-a87a-ac69386669b4/
Solution I tried (I would call it work-around):
During installation of the New version, I am explicitly replacing the old XML file with the new format (4.0). i.e I included application_Name.installstate file (generated by new version) in my package, so it overwrote the old file while upgrade.
MSI got installed without any error and is running successfully.
Reply here if anybody needs detail on both problem and solution.
This error message has nothing to do with the installer per the 1001 error message. The problem is fully inside your service.
Your service's OnStart method should be doing nothing but spinning up a background process and returning success start to the service control manager as quickly as possible. There shouldn't be any long running code in that critical path as the SCM will only wait so long before assuming there was an error starting the service.
Refactor your service to run the job on another thread and the install will successfully install. From there you can focus on the real problem of what's going on in your DeSerialization process.
I know that this topic has been posted over a dozen times, but I wasn't able to find a topic that fit my issue so I will post all detail below.
To start I will mention that I have two projects: The first is the main application and the second is a DLL. The project was due for a major revision and needed a DLL to be replaced due to the company I work in switching vendors. After creating the DLL needed to import into the project I was successfully able to test and run on my machine as well as other developers machines. However once I tried to deploy it on our barebones testing machine I got the error stating that the application configuration is incorrect.
Seeing as I've seen this error before I tried to install the vcredist but I got the same error message. I tried using dependecywalker to see if I had all my needed files for the application to run to which it stated that I was missing MSVCP80.DLL, MSVCR80.DLL, and MSVCR90.DLL. Seeing as running the vcredist didn't help I tried to create a msi installer. Once I deployed that I got the application to run, but at the same time it didn't. The application needs to load in configuration files to be able to run properly otherwise it is not able to connect to our database.
I was wondering if anyone had any advice on how I can include the needed policies/dependencies in order to get this project to be able to run successfully.
To sum it up:
Release application is able to run on other developer machines and
able to load all proper configuration files, but cannot be run on any
bare bone or test machines.
Application created from Visual Studio Installer is able to run, but
ignores the configuration file directory and tries to load in default
directories.
Project is built using VS2005 C++.
Any help would be greatly appreciated.
Thanks,
Sebastian
There are different versions of redist regarding the VS service pack. So make sure, that if you have installed the VS2005 with service pack 1 you provide the redist for VS2005 service pack 1.
You might have gotten the ATL security update on your build machine but not the target.
My open source project it is C++ dynamic linking library. Most of bugs - crash.
I want create public symbol server to simplify debugging with memory dump.
See also: Setting up a Symbol Server
I assume you're using Microsoft tools? If so, all you should need to do is expose your 'symstore' directory with a web server then configure debuggers to access that store:
srv*symbol-cache-location*http://your.web.server.com/symboldir
The "Debugging Tools for Windows" docs (debugger.chm) has details for configuring IIS - I'm sure any other HTTP server will work just as well if you don't need authentication, which I imagine would be the case for an open source project. As far as I know, symsrv.dll just makes normal HTTP GET requests for symbol files when it's trying to get them from an HTTP server.
You'll also need to build the symbol store using the 'symstore' utility. Hopefully that can be integrated into your build or packaging process so it happens automatically. Again, debugger.chm has good docs on the tool.
This will not be a real answer, but you might want to take a moment to vote for C++ support in NuGet in work item Support Managed C++ Project Types or have a look at the discussion about C++ Project support. When that gets in, SymbolSource support will follow shortly (currently it only supports hosting symbols for .NET assemblies).
Trying out BizTalk with a web service call
The request/response is working fine on my own dev machine, but not on test ...
Exported the MSI over to my deployment test server (a seperate virtual), created the application with the Application/Import and then tested it to find it not working ...
checking the event log and it's shows an XLANG error with "Could not load file or assembly"
checked the GAC and the BizTalk assembly isn't there ...
so manually added it and that seemed to do the trick
Does the added web service reference mean the assembly has to be GAC'ed as part of a deployment?
And just to get me confused, tried deploying to the real test server, import the MSI, manual copy of the DLL to the GAC ... and it fails with the XLANG error in eventlog :-(
any idea what's going on here ?
What adapter are you using? I am assuming the SOAP adapter. If so you can look at your bindings. Look here near figure 6:
http://msdn.microsoft.com/en-us/magazine/cc163464.aspx
-Bryan
Just importing the MSI will by default not include the dll.You need to run it as well (like from windows explorer or the option given after install). This will physically move the file. This behavior is quite useful when scaling out. I don't think it have anything to do with the web reference specifically.