I have a .net website that runs on IIS
I have a new requirement that needs to reference a 32-bit .dll
If I go to my application pool on IIS and check the 'Enable 32-Bit Applications' it causes the following error in my site:
Could not load file or assembly 'ChilkatDotNet45' or one of its
dependencies. An attempt was made to load a program with an incorrect
format.
I thought that by enabling 32 bit applications I was only facilitating them if they exist. What am I doing wrong?
Related
I have a .NET Core web API that works fine when hosted in IIS on my local Windows 10 desktop OS. However, when I deploy the same code to a Windows Server 2016 machine, the app pool in IIS fails 5 times and then stops the app pool. The error in the event viewer indicates the following:
A process serving application pool 'My API' reported a failure during application preloading or service loading. The process id was '416'. Please ensure that all application preload or service settings in the application pool are configured properly. The data field contains the error number.
I've tried configuring the API to write out to the stdout, but it doesn't ever generate a log file.
This API was originally written in .NET Core 2.2, so I tried upgrading it to .NET Core 6 and have the same issue - it works in Windows 10 with IIS, but not on Windows Server 2016. The hosting bundle for the appropriate version is installed on the server. I found that if I change the app pool that is hosting my API to have a .NET CLR Version of .NET 4 instead of 'No Managed Code', it then works. All documentation indicates 'No Managed Code' is recommended.
I did actually get it to work at one point with the app pool set to 'No Managed Code'. I ran procmon to see if there were any failures accessing registry keys, system files or folders, etc. and did find that if I copied a few files like webengine.dll, webengine4.dll, and aspnet_rc.dll from the folders they were actually in to folders where procmon indicated it was looking for them in, it then worked. Obviously though I don't want to be copying system files to various locations.
My guess is that something isn't installed on the server or I've misconfigured something as I got the same result when creating a test Web API project in Visual Studio and used the sample endpoints included in the default project. Unfortunately I can't figure out what is missing or misconfigured.
I ran the JexusManager ASP.NET Core Diagnostics tool and this is the report:
System Time: 7/20/2022 8:01:35 AM
Processor Architecture: AMD64
OS: Microsoft Windows NT 10.0.14393.0
Server Type: IIS
Scan 35 installed module(s).
ASP.NET Core module version 2 is installed for .NET Core 3.1 and above: C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll (16.0.22173.7).
Scan 91 registered handler(s).
* Found a valid ASP.NET Core handler as { Name: aspNetCore, Path: *, State: Enabled, Module: AspNetCoreModuleV2, Entry Type: Local }.
Visual C++ runtime is detected (expected: 14.0, detected: 14.12.25810.0 built by: VCTOOLSREL): C:\Windows\system32\msvcp140.dll.
The application pool 'Test API' is used.
Pool identity is NetworkService
Please ensure pool identity has read access to the content folder D:\Program Files (x86)\My Company\Test API.
Pool bitness is 64 bit
Scan aspNetCore section.
"processPath": dotnet.
"arguments": .\TestApi.dll.
"hostingModel": inprocess.
In-process hosting model is detected. To avoid 500.xx errors, make sure that the bitness of published artifacts matches the application pool bitness
Framework dependent deployment is detected. Skip bitness check.
Found runtime config file D:\Program Files (x86)\My Company\Test API\TestApi.runtimeconfig.json.
Runtime is 6.0.0.
I did verify the bitness and the folder permissions. Both were set properly.
I've been working with isapi.dll files on IIS for years, up to IIS 7.0.
I am now trying to migrate my Server 2008R2 to Server 2019. I have done everything I know, but nothing seems to work.
Here is what I've done:
Made sure the server Roles & Features for the Web Server includes CGI, ISAPI Extensions, and ISAPI Filters. I've even removed and re-added all these features to make sure there wasn't a problem when first installing them.
On IIS Manager, on the default site, I added a new application (scripts) and made sure the dll file with all supporting files are in this folder (exactly the files that work on IIS 7.0).
2.1. If you open the dll file in a browser, it tries to download the file, which means my IIS server works, the application folder alias works, and IIS found the dll file.
On the application folder's Handler Mapping, I enabled CGI and ISAPI.dll by ticking Execute on Edit Feature Permissions.
3.1. If you open the dll on the server browser now, you receive a 404.2 error, stating that you have not added the dll to the CGI and ISAPI Restrictions List, which means it is recognizing that the dll file as an ISAPI dll file.
In IIS Manager, on the server tab on the left, opening the CGI and ISAPI Restriction feature, added the dll file and made sure to Allow access. I also tried to update the Feature Settings to enable all unspecified DLL and CGI files, just to cover all bases.
4.1. Now, if you open the dll in the browser you should see some results (even if it is an error 500 if some supporting files or database connections don't work), but instead I get a 404.0 error that the file is missing or moved.
I have tried every possible combination of all the suggestions on the web, but effectively all of them come back to the steps above.
I enabled tracking for the 404 error, but all it says is that the Component cannot be found.
Further testing found that this is specific to 32bit dll files. Running the 32bit dll file with Enable 32bit set to true gives the 404.0 error, running a 64bit dll file with the Enable 32bit set to false runs without any problems. Not having the Enable 32bit set correctly results in an error 500 as expected on both files.
Any assistance to point me in the right direction will be helpful.
You can try this solution:
Open the IIS administrative Manager tool, highlight your server, and open ISAPI and CGI Restrictions
Right-click the restriction that restricts the requested ISAPI resource or the requested CGI resource, and then choose Edit Feature Settings.
Tick the relevant box (either Allow unspecified CGI modules or Allow unspecified ISAPI modules) depending on which technology you intend to use.
If unsure, simply tick both, then click OK.
I am a system admin tasked with migrating Classic ASP based web application from Windows Server 2003 (IIS 6) to Windows Server 2008 r2 (IIS 7.5)
The application is very old written in around 2002-03 and the concerned developer people are not around anymore to let me know anything related to this Web Application.
After lot of trial and error, I have been able to get the Web Application running on 2008 r2.
While navigating through application, I am getting various errors which on further investigation I understood are related to DLLs which the Web Application is invoking.
My issue is, I don't know what all DLLs are used/invoked on the source server, which I need to copy & register on the new server.
I tried to use DependancyWalker but I am not able to find a way to use this tool for Web Application.
I would really appreciate this community's help in this regard.
I found out a simple way of finding the DLLs which are specific to my Web Application.
I got a small freeware utility called as RegDLLView from Nirsoft.net which lists all the DLLs which are registered with the Server with File Paths, Description, Company name, etc details.
I found out all the DLLs which my Web Application is invoking by checking the company name and paths of all the DLLs which were listed.
Now I just have to copy these DLLs to my new server and register these on the new system.
It's not rocket science.
When you find a COM component dependancy you can use the ProgId to identify and locate the DLL which is registered in the Windows Registry.
The only DLL dependancies come from COM component DLLs and these can only be invoke in Classic ASP / VBScipt with the
Server.CreateObject("ProgId")
and
CreateObject("ProgId")
respectively.
Wrote about this extensively here
Error ASP 0177: 8007007e Server.CreateObject fails for COM DLL
I have inherited a classic ASP project and a VB6 Component (ActiveX .dll) that goes with it.
I would like to be able to debug this component by running it locally on my machine.
I have a Windows 7 Home Premium (64 bit) laptop.
I have setup IIS 7.5 locally (production is running IIS5), however, when I browse to the site (locally) I get:
Active Server Pages error '00000000'
Create object failed
?
An error occured while create object 'OBJECTNAME'
Microsoft VBScript runtime error '800a01ae'
Class does't support Automation: 'ID of object in global.asa
I'm not a server guy, so I don't have a lot of experience setting up IIS. I want to setup this project locally so I can step through the COM object using the debugger.
What do I need to do to get this running?
Just as an FYI :
In the global.asa I have the following:
<object runat="server" scope="session" id="ABC" progid="prjABC.clsABC"></object>
Then in the ASP I have the following call:
if ABC.propertyName = True then
...
It fails at that line.
Sounds like the application pool your site is running in is configured for 64-bit mode (the default).
Switch it to 32-bit by right clicking on the pool and choosing Advanced Settings:
Set Enable 32-Bit Applications to True.
You might also want to configure the Managed Pipeline Mode and set that to Classic, not all Classic ASP apps are happy running in Integrated mode.
If all you need to do is debug the component it may be easier writing a COM Application that uses this COM component. Especially if you have the source to the component you can launch your test application from your vb6 component project as your debug application.
Since it's VB6 though you may have to set up a XP virtual machine to be able to run visual studio 6.0 (I've never been able to get 6.0 working on windows 7). Either that or upgrade the component to visual studio 2010.
If you want to run 32 bit components in a 64 bit environment, you can do it. The trouble with setting IIS to allow running 32 bit components as described above is that you end up having all of iis running 32 bit - which if it's a webserver means the main app you're running is 32 bit so reduces the speed advantage of a 64 bit machine.
To run a 32 bit component in a 64 bit IIS, you need to put it in Component Services. Start->Run->"comexp.msc" runs component services. Then just expand down the tree until you find COM+ Applications, and create a new empty application (with all the defaults set as are). Then expand that application and right click on components and then "new">component. The install new component and select the DLLs. This should allow a 64 bit component to just use the 32 bit ones.
I have a method that loads a Crystal Reports file, sets the appropriate login information, and then generates a PDF.
ReportDocument rep = new ReportDocument();
rep.Load(...);
// Set table LogOnInfo
rep.ExportToStream(ExportFormatType.PortableDocFormat);
// Save the PDF to disk or return it as web request
This exact code works in both
A stand-alone WPF desktop application
An ASP.NET MVC website running through Cassini launched from VS
but does not work when the same website is deployed to IIS7. It gives a rather unhelpful message and stacktrace.
An error has occurred while attempting to load the Crystal Reports runtime.
Either the Crystal Reports registry
key permissions are insufficient or
the Crystal Reports runtime is not
installed correctly.
Please install the appropriate Crystal
Reports redistributable
(CRRedist*.msi) that contains the
version of the Crystal Reports runtime
(x86, x64, or Itanium) that is
required. Please go to
http://www.businessobjects.com/support
for more information.
Exception Details: CrystalDecisions.CrystalReports.Engine.LoadSaveReportException: An error has occurred while attempting to load the Crystal Reports runtime.
Note that I am using CR 2008 SP2 and the files haven't been named CRRedist... since 10.5 so someone has been forgetting to update the messages somewhere :) Here is a list of all the CR runtimes.
So why would running the same code referencing the same assemblies work in the two situations listed above but not in a deployed website?
I found this suggestion to give the IIS user write access to the temp folder, and it does appear that the Crystal runtime does some work there but I still get the same error even after giving IIS_IUSR or IIS AppPool\DefaultAppPool full access to %TEMP%.
I have also tried changing the app pool to use my account as the identity and still receive the same error message so I'm not convinced it's a permissions issue.
It turns out that for any newer versions of Crystal Reports after 10.5 (the one that is bundled with VS2008) there are no 64-bit runtimes.
The "simple" solution is to make the app pool 32-bit and then everything works ok.
There are more explanations found here (along with the expected angry responses)
You have to install CR version 13, download the msm and build an installer with VSS. Finalley execute the installer (you build) on your server.
Good luck!