We've written a webservice dll with Delphi XE2 and it is running in our IIS7 server, accessible with the url http://server/webservice.dll/soap
To be able to debug the service, I've created a webservice.exe project, which can be run in the WebAppDebugger of Delphi. The problem now arrises that the webservice running in the debugger is accessible with the url http://localhost/webservice.webservice/soap
Our client application has the last part of the url "webservice.dll/soap" hardcoded (security reasons) so i cannot change that when testing with our client application, the server-address part "http://server/" is configurable in the client.
So, my question: How can i register the debug service in my webappdebugger to use an url like my production dll?
I've found the solution myself ;-)
In the initialization of the debugform there was the following line:
TWebAppSockObjectFactory.Create('Webservice');
changing this to:
TWebAppSockObjectFactory.Create('dll');
made the overall address change to http://localhost/Webservice.dll/
This did leave a small problem that the debugger project had to be renamed to Webservice.exe in stead of WebserverDebug.exe as it was called, but moving it to subfolder made this rename possible.
Related
Today I started to write my first web application and I can't pass one step.
Everything works almost fine... I can connect to the server and open website. Problem is when I open browser and type the same address on the second pc, then I get te same data as on the first one.
Detailed...
Application has two forms, first is for login, and second one is for receiving data.
When I login on the first pc and second form shows up, and then I open browser and put the address of the server on the second pc, I see the second form after login from first pc.
What I should do in this case? I tried to find the solution in the net, but I couldn't :(
If you are using any Delphi IDE after XE3 (including) and using the IntraWeb edition that comes with Delphi you must upgrade in order to have it working correctly. It is free, and more information can be obtained here:
http://atozed.com/IntraWeb/Download/FreeKeyRequest.EN.aspx|
After upgrading (if this is your case) I suggest you to take a look at one of the IntraWeb demos, here:
https://iwdemos.codeplex.com/SourceControl/latest
There is a demo named Features that shows you exactly how to create a multi form application. To be honest, I work with IntraWeb for a long time and I've never seen that. Unless you are using some global var to hold your "current" active form. Have in mind that IntraWeb is a fully multithreaded application and global vars should not be used, unless you have some mechanism protecting concurrent access (but you should get rid of them and use ServerController properties instead).
Thnks for your quick reply.
I work with Delphi from some time, but I never used Intraweb, I worked with ComPort and IP works for I/O devices. I have XE7 and I upgraded Intraweb to 14.0.52.
I can't find a good file exchange server to put my application for sharing with you. If I find somethin I will post it below.
You can check the code and other settings of my simply project. I put the web application inside the link below, it is without the .exe file.
https://www.dropbox.com/s/75zurcew0zr363x/Project1.rar?dl=0
Thanks for your help.
I am trying to create a sample Delphi XE7 desktop app that will connect to SSRS 2005 web service but every time I try to call LoadReport web method, the following error is shown:
This is what I have done so far:
Create a desktop app.
Import WSDL for ReportExecution2005 and ReportService2005.
Create a button that call the web service based on the code shown
here. The web service locations as well as report are hardcoded for
simplicity purposes.
This is the code snippet from the link:
HTExec := tHttpRio.Create(nil);
rsExec := GetReportExecutionServiceSoap(False, ExecURL, HTExec);
// Load the selected report.
LRParams.Report := 'ReportName';
LoadParamsResponse := rsExec.LoadReport(LRParams); //here it fails
Note: I have already created a .NET win form app (VS2010 and VS2013) that consumes this web service without any issues, thus I know the web service and report to render are working OK. Sadly our requirements is for a Delphi solution, My educated guess is that the WSDL importer generated code is not correct and somebody out there may have come across with this issue before and know how to solve it.
I did a quick search for "http://schemas.microsoft.com/sqlserver/2005/06/30/reporting/reportingservices/LoadReport"
and found this.
If it applies to you as well, it may be the case you're calling the service on an incorrect URL, use the one with ReportExecution2005.asmxin it, not ReportService2005.asmx
(There's a lot more here)
To find out differences between the Delphi version and the working version, use a HTTP proxy (Fiddler2) to capture the SOAP HTTP traffic in both setups.
If you have no access to the working environment, use SoapUI to create SOAP requests.
Quite not sure why I see this error.
I navigate to my Login View like so http://test.staging.com/mywebsite/Login
My Login view was just redone using MVC but I have seen this same error message going to an aspx page as well...
If I use http I get the error message The specified request cannot be executed from current Application Pool.
If I use https://test.staging.com/mywebsite/Login, I'm good.
If I don't specify a protocol, test.staging.com/mywebsite/Login, I get the error as well
Is there an error happening under the covers and my custom error page can't be shown like discussed here?
What are some other causes of this error?
That usually means your custom errors are configured to run as a different AppPool.
You can read more at MSDN. (See section "Using Custom Errors from Another Application Pool").
There are two ways to correct this behavior. The first is possibly not one that you are interested in because it would require you to change your current architecture and run both sites in the same application pool (such as share the same worker process memory space). To do this, simply move the /errors virtual directory to run in the same application pool as the site for which it serves the custom error.
The second way is to make use of a registry key provided by IIS 6.0. This registry key makes sure IIS 6.0 does not check the metadata during the execution of the custom error and therefore allowing this to work.
See the article for information on the registry key fix.
It may also mean that you are using something along the lines of Server.Transfer to a page that is in a different AppPool.
It could be because you're using different versions of ASP.NET for one or many apps in the pool.
Make sure all apps in the pool use the same version of ASP (e.g. ASP 2.0.50727)
If you just added a new app, try changing the app momentarily to a different version of ASP, then back to same version. I experienced an issue where the displayed version was correct, but under the hood, a different version was used!
Check your event log, under Application, to get more details about the error.
The message would be caused by your page server-side redirecting to a page served by another application pool. Such as for example, in your link, the error page.
I know this is an old thread, but I stumbled upon it and found a different solution. Here's what worked for me: Make sure your application handles .asmx files correctly
From IIS:
Right Click on your project > Properties > Configuration
If necessary, add the .asmx file extension that maps to the aspnet_isapi.dll
Limit to: "GET,HEAD,POST,DEBUG" and restart.
Because I can't comment on vcsjones's answer, I'll add it down here. The DWORD value IgnoreAppPoolForCustomErrors needs to be set under HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters vs HKLM\SYSTEM\CurrentControlSet\Services\W3SVC referenced in that technet article. Set it to 1 and do an iisreset and you're good to go.
Source Blog Post
In my particular case, I received this error while trying to serve a content (non ASP.NET) website while it was an Application. Right-Clicking the virtual folder and removing the application fixed it for me.
In my case the application used the application pool that didn't exist. I have no idea how it's happened.
I'm trying the WorkSpace.PendAdd method under Microsoft.Teamfoundation.Client namespace to add the local folder to TFS, it works normally when i debug with VS2010, but it doesn't work if it's published to IIS. I also tried giving the full control to the folder, but still no effect. Any idea will be appreciated.
Check to see what identity the web app is running under. Does that ID have appropriate rights in TFS? If you're hosting on a web server that is not also your TFS application tier, you could also be running into the two-hop limitation of passing identity.
When you're running in debug mode, it is probably picking up your credentials, and since your machine counts as hop zero, there's no problem passing them on to the TFS application tier.
I found a solution after checking the versionControl NonFatalError event.
Before the calling to workspace.PendAdd, just call:
Workstation.Current.EnsureUpdateWorkspaceInfoCache(
_versionControl,
_versionControl.AuthenticatedUser);
(for some reason it's the only way the specific file folder path will be mapped when running in IIS)
We use MVC controllers that access System.File.IO in our application and they work fine in localhost (IIS 6.0-based Cassini). Deploying to IIS7, we have problems getting the controllers to work because they throw UnauthorizedAccessExceptions.
We have done the following to try to resolve the issue:
- Set NETWORK SERVICE and IUSR accounts to have permission on the files and folders in question
- Ensured the App Pool is running under NETWORK SERVICE and loading the user profile
- Application is running under full trust
- We tried adding impersonation to web.config and giving NETWORK SERVICE write permissions (which was not a great idea because that's not what we want to do)
Now, we alternate between getting UnauthorizedAccessException and an IIS7 404 page that suggests the routes are being ignored completely (for example we serve "/favicon.ico" via a controller when the physical file actually lives at /content/images/favicon.ico). We used ProcessMonitor to try to track down the issue but weren't successful.
UPDATE:
This issue is intermittent. We had a brief few minutes where everything worked without making any configuration changes. We're running on EC2, so this could be related to a distributed file system. We're also using a separate drive to store all web site data, we're not using inetpub/wwwroot.
UPDATE 2:
The site works without incident under IIS 7.5, with no configuration changes needed but this is likely due to running with the new AppPoolIdentity. Otherwise it's an identical deployment. Unfortunately we can't run R2 on this EC2 instance.
One of the ways to identifying the cause is using Procmon tool from Sysinternals
Procmon will show the reason for unable to open the file , it will also show who is holding the file.
The issue turned out to be the controller factory we were using not handling file requests properly.