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.
Related
I'm working in an application developed with Spring5 (not Spring boot!) that runs on Jetty. This application has module that uses the plugin liquibase-maven-plugin.
We generate a image from a dockerfile (base image jetty:9-jre8), where we add the application (war file) in the jetty application directory.
In some specific environments, where I deploy the application, I want to be able to disable that execution.
Is it possible to do so?
I've seen on spring boot documentation, that it's possible to do so by defining the property spring.liquibase.enabled (or liquibase.enabled on Spring4) to false, but that seems that doesn't work:
I've tried to define them at the properties file, define them as env properties and also as java options (-Dspring.liquibase.enabled=false).
This has the same behavior when I deploy the container, or when I execute locally the maven command: mvn jetty:run
Do you have any ideas or hints how to do this?
Thank you in advance
Well I just discovered that it's possible to disable the execution of liquibase by adding the JAVA_OPTION
-Dliquibase.shouldRun=false
For more details see here
I will keep this quesion anyway, in case someone has the same problem I did.
I am using 3 webservices in my project and it was running correctly. But in these days it is crashing when creating it's client and I haven't changed anything.
How can I solve it, could you help me, please?
It's saying your service config file is not found. Are you referencing it correctly from the app.config?
It looks like you're using WPF or Silverlight so find your app.config file.
You cannot apply configSource= to since that is a config section group - not a simple config section, and the configSource attribute is only available on simple configuration sections.
You should however absolutely be able to apply the configSource attribute to any of the nodes inside - I do this all the time, in production systems - and it just works; for behaviors, services, clients, bindings, etc; each in a separate .config file.
.ClientConfig is also a bad extension. All configuration files should have .config extension.
In the worst case scenario that you can't configure the external config source for the settings, move them back tot he app.config file of the application!
I'm using TeamCity 7 as CI Server, and I'd have to test several Web Application plugins, mainly written with PHP. I'm familiar with ANT and *Unit, but I have an issue to solve: to properly test a plugin, my idea would be the following:
Cleanup the testing environment.
Install a clean copy of the Web Application which will host the plugin.
Install the plugin.
Enable the plugin.
Run the tests.
Obviously, running the tests on an installed environment is the easy part. Most tests are fired by directly calling plugin's classes' methods, yet the framework must be configured, even with minimal settings, to allow calling its bootstrap file and perform due initialization. I tried running the tests in an environment I prepared manually, and they run as expected.
The issue is now automating the installation of the standard Web Application, and, most importantly, its configuration. The basic steps are the following:
Unzip framework somewhere (done).
Create a Database (done).
Create a Database User ans assign it propert privileges (done).
Run Web Application's setup.
The tricky part is that not all Web Application implement a command line interface, such as drush for Drupal, hence I came out with two possible ways to complete the installation:
Simulate manual installation via CURL
Take note of the installation steps and the forms that need to be filled.
POST data to each of the forms using CURL.
I tried this method, still manually, with acceptable results. The Web Application gets installed as expected, and it can be used.
However, this requires a Web Server where the application can run. As far as I know, TeamCity Agents work in their own, random named directories and anything "installed" in them cannot be accessed via HTTP requests.
Backup/Restore
Manually pre-install a Web Application and configure its basic settings.
Zip the Application's directory and a backup of its database.
Before running the tests, unzip the directory in Agent's working directory.
Restore the backed-up database. The application will now be "configured".
This method is a bit "rough", but it doesn't require a Web Server to be running. Although the Web Application won't be able to server HTTP requests, that doesn't necessarily matter, as the tests will be run against plugin's classes.
This method has two major drawbacks, though:
Tests involving interaction with the Web Application (e.g. hooks, event handlers, and so on) can't be run.
Since the Web Application and its database are pre-configured, their parameters will be the same at every run. Therefore, it wouldn't be possible to run two Agents at the same time, for example to test two different plugins.
I'm now wondering if there's a better solution, as both the above look less than optimal to me.
Please note that, although I'm using TeamCity, the CI Server itself should not be a big deal, as I'm running everything with ANT. Therefore, any suggestion, even related to another CI Serverm, will be welcome (I know Hudson, CruiseControl and BuildMaster, I can adapt a concept easily). Thanks.
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.
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!