I built a Delphi-7 Windows Application which uses some web services. The application is built in such a way that it does not require run-time DLLs. When I deployed it on a Windows 2003 server it fails while calling the web service. It results in error "Access violation at address 00c05269. Write of address 00c05269". I believe the reasons is that it needs some package to be installed. Can anybody help me to figure that out?
TIA
Just a guess: If the client was built with D7, that runtime will AV on machines with DEP enabled. See the following link for more information:
groups.google.com/group/borland.public.delphi.webservices.soap/msg/b19f3c2681de50f4
You can disable DEP for just that client (or system-wide) on the Win 2003 machine to see if that's the issue:
technet.microsoft.com/en-us/library/cc738483(WS.10).aspx
And if it is, you can download a SOAP runtime fix from here:
http://cc.embarcadero.com/Item/24535
Cheers,
Bruneau
Some troubleshooting suggestions.
Can you browse to the web service from a web browser? If not, you have a connectivity problem.
If this works, I would build a bare bones client that consumes the web service and calls a couple of methods but doesn't read from or write to any external files.
Related
I have a COM+ application consisting of a client DLL and many middle-tier DLLs.
The application gets run by using an MSC application file.
When I am in die IDE and run my client DLL, I have the following run parameters to launch, run and debug my client DLL (this works great):
The theory is that I should be able to debug my middle-tier by running the DLL with the following parameters (I get the ProcessID from my COM+ Application in Component Services):
Once it is running, I should then be able to start my client MSC application and that should allow me to attach and debug my middle tier. I have seen this working before.
Running my Client DLL from the IDE or as an MSC application works without issues but when I try to debug my middle-tier, as described above, I get a "The RPC server is unavailable" error.
I am running everything locally so I am not sure what server it is referring too.
I have also made sure the following services are up-and-running:
DCOM Server Process Launcher, Remote Procedure Call (RPC) and RPC Endpoint Mapper
Any idea what else could cause this error or what server it is trying to connect too?
It turns out there were more than 1 version of the DLLs registered on my pc. I inherited the pc from a previous employee and noticed some install files of the application on the C drive (all my stuff is on the E drive). I ran the uninstall procedure on the C drive that also unregistered some DLLs and my RPC problem was resolved.
I've revisited my asp.net mvc core 2.0 web site after some 8 months and for some reason I cannot upload any dll files from my local published folder to the hosting server. I keep getting the following error...
"Copying files to remote side failed.
The process cannot access the file because it is being used by another process."
I get this error no matter which method I use, ftp or http.
What's changed in the last 8 months?
Please check list below:
Please ensure you have rights to access the file;
Please check if the FTP port is used by other applications;
Please check if the file is indeed used by other programs.
Please run process explorer and see what process is locking the file.
Also try:
Restarting your visual studio
Restarting your operating system.
Restarting target server or Web Server.
Please provide more information for more help
I have written a SOAP server and client to consume the services in Delphi XE2. The SOAP server executable is installed on a development Windows 8.1 PC running IIS and also a Windows 2003 Server (also IIS). Everything has been going ok except I have just added another service(method?) to my SOAP server and it won't show up in the WSDL after deploying the exe.
If I browse to the services executable (using firefox) e.g.
192.168.2.64:8080/mysoapservices/MySOAPServer.exe or 192.168.2.64:8080/mysoapservices/MySOAPServer.exe/SOAP/IASOAPServer
Then I can see the new method listed, but if I look at the WSDL
192.168.2.64:8080/mysoapservices/MySOAPServer.exe/WSDL/IASOAPServer
then it isn't in the XML definition. So, when I import the WSDL via Delphi/Component/Import WSDL it is missing my new method.
Does anyone know what I am doing wrong?
Why are you looking at ASOAPServer.exe instead of MySOAPServer.exe?
I've an asp.net MVC website which use somme DLL that work only in 32 bits or only in 64 bits(sql lite).
Since our server are running in 64 bits, I would like to run all my code in 64 bits. The problem is that the Visual studio development server is running in 32 bits in all case.
So I come to use a Local IIS Web server.
The problem is that with an asp.net MVC website, it's mandatory to have the website at the root of the URL.
So I wish to have something like "mywebsite.lo"(with a entry in my hosts file) or "localhost:9999" as project url.
But if I try to put this, when I create the virtual directory, I got this error:
Unable to create the virtual directory. Could not find the server 'mywebsite.lo' on the local machine. Creating a virtual directory is only supported on the local IIS server.
So I created myself the website with the correct binding responding to 'mywebsite.lo'. Now if I click on Create Virtual Directory, I got a successfull message. If But when I run the website, I got a message saying : Unable to start debugging on the web server. The web server is not configured correctly. See help for common configuration errors. Running the web page outside of the debugger may provide further information.
In order to debug in visual studio with a local IIS, then Visual Studio must be running as an administrator, are you doing that?
I made a dummy mistake: The application pool was in .Net 2.x :/
I have been able to install 'VS2008 SP1' and 'VS2008 Tools for Silverlight' on my Windows Server 2008 development machine, but I have not been able to install the MSI for 'Silverlight Toolkit July 2009'. The install fails with the following:
"The system administrator has set policies to prevent this installation"
I am a local admin on the box. I have seen something similar when try to to 32-bit MSI on a 64-bit machine. Is that the problem that I am having?
I don't think that you need to install the SL toolkit on the server. At least, we haven't had to. We're using 64-bit Windows Server 2003, and any required Silverlight DLLs, etc., just get included in our .xap file, and get downloaded by the client when it downloads that file. All the server knows is that it's got to pass the .xap file down to a client when it requests it. The only thing that any server-side process might need to know about is the System.ServiceModel.PollingDuplex.dll (if you're using duplex WCF services), but if you simply install the SL 3.0 SDK on your dev machine, and then reference that DLL from your WCF project, it'll get included with your WCF project when you roll it out to the server in question.
The only reason you'd need to install those things on the server is if you're planning to do development on the server, which I suppose you might want to, but certainly isn't normal :-).