It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
what are minimal steps required to make ISAPI dll working in IIS7 for query www.website.com/test/bin/ISAPIGet.dll?a=b ? Please don't refer to top google searches, they are very generic and don't work.
I wrote very simple ISAPIGet.dll in Delphi2010, which works great in IIS5 Win2000. Then I put it on IIS7 SBS2008,
into C:\inetpub\wwwroot\website\test\bin folder.
Created website for /website,
Application for /test,
VirtualDirectory for /bin,
in HandlerMappings for /bin Added Script Map *.dll to my ISAPIGet.dll,
allowed my dll in ISAPIandCgiRestrictions,
created 32bit ApplicationPool NonManaged code, Classic mode,
bound it to /test Application.
When quering www.website.com/test/bin/ISAPIGet.dll?a=b I'm getting all kinds of errors like 500, 503 (when AppPool fails), while homepage www.website.com is working fine.
What else should I do? Do I need to configure web.config file, where and how?
As I recall, I had similar problems getting our ISAPI DLL to run in IIS7 on WinSvr2008R2(64b). I wrote down some quick notes to help me repeat the steps that finally got it working. I'll try to provide those here (at least what we did).
Grant "Read & Execute, List folder contents, and Read" rights to IUSR to the folder C:\PathToISAPI_DLL
Copy all DLL files that the ISAPI DLL needs to run into the c:\windows\syswow64 folder (e.g., midas.dll, dbxmss.dll, etc.)
Start IIS Manager
Add the app pool "MyAppPool" [no managed, classic, start now]
Change "Advanced Settings" of new App Pool to allow 32-bit, plus set idle time-out
Add an application "MyApp" to your website using "MyAppPool" and set the physical path to C:\PathToISAPI_DLL
Now you have to do several steps at the DOS prompt to finish configuring things:
cd /d c:\windows\system32\inetsrv
REM *** Grant rights to execute the DLL ***
appcmd.exe set config -section:isapiCgiRestriction /+[path='C:\PathToISAPI_DLL\ISAPI.dll',allowed='true']
REM *** Grant the url of the Execute access for hander mappings ***
appcmd.exe set config "Default Web Site/MyApp/ISAPI.DLL" "/commit:Default Web Site/MyApp" /section:handlers /accessPolicy:Read,Script,Execute
REM *** Make sure you have an ISAPI module mapping for *.dll at that path ***
appcmd.exe list config "Default Web Site/MyApp" /section:handlers | findstr /i *.dll
That's the extent of my notes. I have successfully followed them several times and it has always worked. I have never been able to get it work using just the GUI. I've always had to run the appcmd commands at a DOS prompt to finish configuring things.
Sometimes I still see a 404 error, in which case I delete the web.config from the folder with the ISAPI.DLL and run the last two appcmd commands again. Of course, my ISAPI DLL doesn't have any other settings in the web.config file so it doesn't hurt to just delete it...
Is it not just because the dll is 32 bit and IIS7 is a 64 bit process so is not able to read a Delphi 32 bit dll?
Your main page is static html which is handled by IIS with no problem.
But when IIS tries to load ISAPIGet.dll, it fails because it is not a 64 bit library, or one of its dependency is missing.
Are you sure you use a IIS7 app-pool in 32-bit mode?
Do you have all needed sub-libraries and bpl in the same path or in c:\windows\syswow64 ?
Related
There are quite a few solutions out there for this one but they all pertain to the actual IIS box. I am Unable to publish at all the publish process fails with the following error:
Could not load file or assembly 'file:///C:\Users\user\Documents\VSSolutions\myWebApp\myWebApp\bin\AjaxControlToolkit.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
I CAN and successfully do build/run and test the app on my local machine.
This is an isolated problem to my specific machine as in my other developers are able to do the publish after I check in all of my changes!
Here is everything that I have tried.
enabled 32 bit on IIS
gave full rights to Temporary ASP.NEt folder at several different locations based on offered solutions
dll file is NOT blocked!
I am using VS 2022 AND VS 2019 and the same issue persists on both!
Please help :)
I saw another Stack Overflow post to make sure anti-virus is not blocking a temporary ASP.NET folder. In my case turns out that was the case indeed. Anti-virus was blocking my publish from completing...
In my application (build with Delphi XE8) I use the IdHTTP component. When I tried to run the application, the following exception was thrown: 'Could not load SSL library'.
I solved this issue by downloading the OpenSSL library from this site
http://thundaxsoftware.blogspot.nl/2014/09/cannot-load-ssl-library-using-delphi-xe7.html
If I'm correct: the files 'libeay32.dll' and 'ssleay32.dll' are needed.
But it only works for me. A friend of mine, who also uses this application, got the same error ("Could not load SSL library").
I want others to be able to download my application without them having to download the OpenSSL library seperately.
Is it possible to include these two files into my application?
For example by adding a folder to the directory location of the application? If so, how can I make the application find these files when it needs them?
I hope you can help me! (My apologies for the bad English)
You should bundle the DLLs (and any other necessary files) with your application in an installer. The installer can then install the DLLs in the same folder as your application executable, and your app will be able to find them when it's run. It also makes it much easier for your users to get the files into the proper locations by simply running Setup.exe (or YourAppSetup.exe).
There are several products that will create the installer for you, including the free (written in Delphi) Inno Setup.
The cleanest way to handle this is to deploy the SSL DLLs to the same directory as your executable file.
Assuming that you do not specify a location for the libraries, Indy will default to using the system DLL search order. And the executable file's directory is the top of that search order. So your DLL files will be found.
By supplying these libraries your app is isolated from other applications. That avoids so-called DLL hell where multiple applications share libraries but all have different version requirements.
Just wanted to check whether the precompiled files from "publish" are IL or Native. The file extension are .compiled for the views, and dlls for others.
I have seen some comment that imply that one of the advantages for doing this is to eliminate startup lag due to JIT, but this implies that they are native, but I am not sure.
I have chosed "no merging" of files for my first attempt.
Confirmation appreciated.
Thanks.
EDIT
Is there any potential difference if I select x86, or "mixed platforms" or "any cpu". The latter 2 might imply IL code whereas x86 could be native. I am targetting a 32bit Azure Websites instance. I am trying to get rid of the warmup period issue.
It is IL. You can confirm it by running CorFlags.exe. The CorFlags section of the header of a portable executable image will indicate whether its 32bit or AnyCPU etc. Another utility that comes in handy is DUMPBIN.EXE.
Even if you precompile your web applications, there's going to be an initial hit when you access the website. That process is described here. Its a tad dated, but much of it still applies. But the hit with a precompiled website is going to be substantially less than a non-precompiled website.
When compiling, select "Any CPU" and control whether its a 32bit or 64bit application via IIS, Azure or the hosting environment. Let the framework do what the framework does best.
I'm developing an ASP.NET MVC (still v2) Azure web application. I've run into a problem that seems to require me to step through the MVC code itself. I can do this but also need to be able to inspect the code as I step, so I need to be an unoptimized version (so as to not get the "Cannot obtain value of local or argument ...") message in the debugger.
The standard way of circumventing the optimizations (http://blogs.msdn.com/b/sburke/archive/2008/01/29/how-to-disable-optimizations-when-debugging-reference-source.aspx) doesn't seem applicable to running in the Compute Emulator.
I also tried this by creating a local debug build of the System.Web.Mvc project but my web role hangs when I try to start it in the Compute Emulator.
So ... Any help with either of the following would be much appreciated:
Running an Azure web app in Visual Studio (2010) so that it will ignore code optimizations in system dlls.
OR
Creating a local system debug build so that it can be referenced by an Azure web app being debugged in the Compute Emulator.
If the Azure Compute Emulator is giving you issues you could run your MVC project using IIS Express. Just right click and and Select Debug/Start New Instance.
I was finally able to get unoptimized ASP.NET code while debugging in the compute emulator. The basic approach described on MSDN (http://msdn.microsoft.com/en-us/library/9dd8z24x%28v=vs.100%29.aspx) and elsewhere (http://martin.bz/blog/asp-net-mvc-source-debugging-the-easy-way among others) is to put an .ini file that tells the JIT compiler not to optimize in the same directory as the DLL.
The first challenge was to determine just where that was; it finally dawned on me to watch the logs in the Compute Emulator UI and see where they loaded the DLL (in this case System.Web.Mvc) from.
The second challenge was getting the .ini file there. Windows Explorer didn't work because it uses a different way of viewing assembly caches that doesn't give you direct access to the files. One of the posts I read reminded me that using the Command Prompt might give me that access and it did. The last step was realizing, when the Command Prompt wouldn't permit me to move the .ini file into the assembly directory, that I needed to run Command Prompt as admin.
Once I could view variables while debugging, I pretty quickly realized where my bug was.
I have made a simple installer application in Delphi, nothing fancy. Basically I include files into the Exe, and then extract them to a user specified path.
I stumbled across a problem however, and I have noticed this works with ANY Windows Executable, it does not matter if it is an installer or not.
If an Exe is named, or contains the following words in the filename, "Setup", "Build", "Install" and maybe others, then.. whenever the Application is run and closed, Windows pops up a Product Compatibility Assistant dialog, saying the Application may not have installed correctly.
This is a problem, as even though the Files from my installer have actually extracted, and in my eyes the installer has done its job, Windows is complaining about it.
The only idea I have regarding this, is that Windows must check the filename of the Applications when executed, and in this case has identified it as an Installer. Windows must of then set a flag or something on the System, my Installer must then update this flag to say that the installation was a success?
Windows does not complain about this when debugging from the IDE, so it cannot be code related, it must be the OS - this only happens when launching the Application from Windows, not Delphi.
You can try this easily, either create an Application or rename one as Setup.exe, Run it and then close it - wait a few seconds and the Product Compatibility Assistant Dialog will show.
I don't know where to start investigating how to stop this dialog, or where a setting may be to tell Windows the Installer was completed correctly.
Appreciate your thoughts and solutions thanks.
If I recall correctly, this happens when your install app does not include an application manifest. When UAC was introduced, MS introduced a heuristic detection for installers and shows the UAC elevation dialog. The heuristic checks for names like setup.exe, install.exe. The simple solution is to include an application manifest. If it is an installer you probably want to use the requireAdministrator setting.
The feature is known as Installer Detection and is discussed here.
For what it is worth, I would always build an installer with a dedicated install tool like InnoSetup for example.
As David pointed out, MS uses some fuzzy logic to try to guess if the program is an installer. I wouldn't rely on this, as this is only for supporting legacy installer applications.
All new applications should have a manifest file, specifying whether it requires elevated privileges.
If an application has a manifest file that includes the requestedExecutionLevel directive, then Windows does not attempt Installer Detection.
Any program that is detected as an installer program but does not add a registry entry to the Add Remove Programs section of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) will get the message "This program might not have installed correctly".