Image resizing in Windows IIS7 Data Center Edition - iis-7

I tried installing my old ASPImage from server Objects in my new server, but the object is not created even though the dll is registered and ASP is enabled in IIS7. Does anyone have any ideas on this issue, or used a different component that can be called from VBS as well as ASP classic?
I tried running tests on the object and it returns internal server errors. When running in VBS, no errors but it ignores the object.
Thanks
James F.

Assuming you have a 64 bit Web Server, you have to enable the setting "Enable 32-Bit Applications" in the Application Pool using the 32bit Component.
See here for further details:
http://help.webcontrolcenter.com/KB/a1114/how-to-enable-32-bit-application-pool-iis-7-dedicatedvps.aspx

Related

ASP_0177_:_800401f3|Server.CreateObject_Failed error while migrating Classic asp from iis 6 to iis 7.5

While migrating a Classic asp project from windows server 2003(IIS 6) to windows server 2008 R2(IIS 7.5), the Menu is not getting loaded, when checked in the log. It displays the below error.
Menu.asp |107|ASP_0177_:_800401f3|Server.CreateObject_Failed
When checked the code, the line shows
Server.CreateObject("webCalendarv1.objCalandar")
Can some one please help me why im getting this error.
Server.CreateObject_Failed
This type of error usually means the component (DLL) you are trying to reference isn't installed on that server or your syntax is incorrect.
As you say that you've moved servers I would suggest that you check that the
webCalendarv1.objCalandar
component is installed/registered on your new server. Most likely you can move the relevant DLL file across and run;
Regsvr32.exe nameofthecomponent.dll
One thing you'll have to check is that you have the correct bit version of your component that matchs the bit version of your Windows Server OS. There is an option within IIS that allows use of 32bit components on a 64bit Windows Server for a specific App Pool.

Why is my IIS 7 refusing to serve up css or js when I change 'Enable 32-Bit Applications' to False

I have a very simple web application (asp.net MVC3, .net 4, using IIS not Visual Studio's embedded server, 64-bit Windows 7). When I change the settings in the application pool for my application and set 'Enable 32-Bit Applications' to False, my application's view shows up, but none of the static content (Content/Site.css or Scripts/myScript.js) shows up. Instead, I get status code 500 on those requests.
HTTP Error 500.0 - Internal Server Error
The page cannot be displayed because an internal server error has occurred.
The reason I'm changing this value is that I'm trying to use the 64-bit Oracle.DataAccess.dll and if I have this value set to True it causes the application pool to run in WOW64 mode and it tries to load the dll with the wrong format.
I've searched online for a while and can't find very much info about this. I've tried playing with permissions on the files, I've tried running aspnet_regiis with all kinds of flags. I'm out of ideas. Why won't IIS serve up this static content when running in 64bit mode?
When I had this error there was a problem in system.webServer\staticContent in web.config.
Because of a difference between servers, an for a particular MIME type was required on one machine but caused this error on another.
The failsafe would be to include a for each that you have in web.config to avoid getting a 500 if the is not required.
It is very likely that on your IIS setup, a 32 bit only module is installed by you accidentally which prevents the whole web application from running in 64 bit module. That's a common cause of such 500 errors.
Failed request tracing should be able to show you more information on which module it is,
http://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis
Double check mime types are correctly assigned, it could be because you have double entry of mimetypes for local site web.config and server itself.
Having to put comment here as I dont have enough points to comment.
Have you tried checking the handler mapping on your website.
Under Handler Mappings: Check that the StaticFile Handler is still registered and that the path is assigned to *
Also check that it is enabled.
Just had this issue myself with windows security enabled and ananamous access turned off.
The solution in my case was to add the localhost site to my local intranet sites. Running Visual Studio in adminstrator mode can also clear the problem.

Script not served by static file handler on IIS7.5

I've just tried to deploy my first web application to IIS on my Windows 7 Home Premium notebook. After creating the application, I had to change to the Classic App Pool, then set that pool for framework 4.0. Now I get the following error:
HTTP Error 404.17 - Not Found The requested content appears to be
script and will not be served by the static file handler.
The requested URL is http://localhost:80/pvmms/default.aspx
I'm afraid extensive Googling has yielded nothing clear or definite enough for me to work with and as usual I've turned to the experts.
EDIT:
I suspect this is because there are no framework 4.0 handler mappings for .aspx files. However, aspnet_regiis even gives my admin user the finger and says I need admin rights to run it.
EDIT #2:
I registered all the frameworks (2 & 4, 32 and 64) and all now works. I found this by manually adding a script map for .aspx to aspnet_isapi and voila. I don't understand why the installation of the framework doesn't do this, unless my memory fails me and I only enabled IIS after installing VS.
Maybe too late now, but more often than not you need to run
aspnet_regiis.exe -i
after installing asp.net. Maybe I would do it anyway now.
In addition to above, if you need WCF support, you might need to run this:
c:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe -i
Replace v3.0 to whatever your current framework version is.
I encountered this error from IIS 8.5 when trying to access a WCF service I had written. Turns out the server didn't have the WCF HTTP Activation features turned on. Checked the boxes and clicked through the wizard, iisreset, started working.
If you are using iis 7.5.
Just go to IIS Manager, open your website properties.
You will see 'Handler Mappings' section there, just go to that section and Search for 'staticFile'.
Most probably its a last file in the list.
Then Right Click on it and Select 'Revert To Parent'.
I have wasted so many hours while i have faced this first time, anyways this will solve your problem.
I had this issue with Windows Server 2012 with ASP .NET 4.5 you can't use aspnet_regiis.exe, and just have to install ASP .NET 4.5 via the Add Roles and Features Wizard:
You can find the menu item "Add Roles and Features" in the menu "Manage", in the right corner of Server Manager
should check out this option i suppose
I solved this problem by enabling WCF Services
Programs and Features > NET Framework 4.5 Services > WCF Services> HTTP Activation node
But you have to admit it guys this ENTIRE IIS setup configure/guess/trial and see/try this/try that spends 4 or 5 of our days trying to find a solution around approach IS A COMPLETE AND UTTER JOKE.
SURELY, 'IIS' IS THE BIGGEST CONFIDENCE TRICK EVER PLAYED ON MANKIND TO DATE
I know this is an old question, but I've just had this with a 3.5 application on my rebuilt Windows 8 machine and I was still getting this after aspnet_regiis -iru and it turned out the be ASP.NET 3.5 wasn't ticked within Application Development Features (not enough reputation to post an image).
There is a chance that application pool created for you application by default is version 2. So although you see a handler for .svc extension in the list it does not work and treat it as static file. All you need is to open application pool properties and switch it to version 4.
Register asp.net again....will solve the issue.
Go to Visual Studio Command Prompt, And register asp.net as windows\microsoft.net\Framework[.Net version num]\aspnet_regiis.exe -i
I had this same issue on a windows 8 machine I am setting up. I had installed vs2012 before vs2010, which installs .NET framework 4.5. I have my app pools running in 4.0. I made sure I had aspnet registered for 4.0 using aspnet_regiis -i. That still didn't do the trick. Then I opened up the Windows Features and noticed that 4.5 added a set called ".NET Framework 4.5 Advanced Services". I enabled the WCF Service node and its children and then my svc endpoint operated correctly. Hope this helps folks who are making the move to Windows 8.
I stumbled upon this question when I ran into the same issue. The root cause of my issue was an incorrectly-configured app pool. It was set for 2.0 inadvertently, when it needed to be set to 4.0. The answer at the following link helped me uncover this issue: http://forums.iis.net/t/1160143.aspx
For Windows 10/Framework 4.7, I had to turn on HTTP Activation through the following method:
Control Panel > Programs and Features > Turn Windows Features on or off
Under .NET Framework 4.7 Advanced Services, expand WCF Services, select to check the HTTP Activation and whatever else you need when working with WCF
Click OK and let the install do its thing, then open an administrative command prompt and issue the IISRESET command
cmd -> right click -> Run as administrator
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i
For other people reading this:
This can happen is if the .Net version that you have registered isn't the one selected under the 'Basic Settings' of the application pool attached to your website. For instance, your sites application pool has .Net v2.0 selected but you registered v4.0
Just another possible solution I found having the same error message.
When trying to setup a .NET 4.0 web application to a new applicition pool I was receiving this strange error telling me it was trying to process my aspx file with the static file handler, which didn't make sense.
For some reason the ISAPI for .NET 4.0 was set to disabled in the ISAPI and CGI Restrictions area of the server level in the IIS manager. Setting it to enabled was all that was required, however the IIS 7.5 manager is so convoluted and hard to follow it took me a long time to figure this out.
I'm guessing that since it was a 4.0 Application that could not be processed by the 4.0 Engine the static file handler was being used by default.
I had the same problem. When I added Static content feaute for IIS, It works fine.
it could be multiple reason, in my case under Application pool->advance setting->Enable 32 bit application (should be true).It was set to false before.
Using IIS manager, I found that .aspx files were mapped (under "Handler Mappings") to ISAPI 2.0 - even though ASP.NET 4.5 had been previously installed. Editing them to point (also) to an executable for ISAPI 4.0 64bit fixed the issue.
The executable was found in
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll
i received this message for an application on iis 7.5 with a classic app pool assigned to .net 2.0. i needed to go to Handler Mappings and add two script maps, both were the same with except for the name. one name was svc-ISAPI-2.0-64, the other was svc-ISAPI-2.0. The request path was .svc. And the Executable was %SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll. i restarted iis and all was happy
One of the worst case scenario I just solved is - having conflicting entry in Web.config.
On my local machine I didn't had .woff extension registered in IIS, so I added it using Web.config. But on production server .woff had mime type registered. This caused application level conflict.
Funny part is there are no error logged for this. Just a guess work (first time of course).
So for me solution was just to remove and/or elements from web.config.
I had the same issue, I just changed the target framework version on the website to the version it is developed in,Same in IIS. This solved my problem. Hope this helps...
Thank You

Have you had DLL's fail after upgrading to 64 bit server?

I'm wondering if anyone else has experienced failed DLL's after upgrading their servers.
My company is in the process of upgrading our code and server's after ten years of using classic ASP. We've set up our new server running Windows 2008 and IIS 7. Our classic ASP code and our new asp.net mvc code work pretty well.
Our problems started happening when we began moving our old websites to the new server. When trying to load the page on the actual server machine's browser, we initially got a 500 error. If we refreshed the page then some of the page would load but then display an error:
Server object error 'ASP 0177 : 800401f3'
Server.CreateObject Failed
/folder/scriptname.asp, line 24
800401f3
btw: On remote machines we would just get 500 errors.
Line 24 is the first executable code in the script:
'23 lines of comments
set A0SQL_DATA = server.createobject("olddllname.Data")
'the rest of the script
That specific line is trying to use a ten year old DLL to create a server object. I don't think the server configuration is a problem because I'm able to create "adodb.recordset" server objects without any problems.
Is there an issue when running correctly registered old DLL's on 64 bit systems?
Is there a way to get old DLL's working on 64 bit systems?
Edit
I have confirmed that the site's application pool is running in 32bit compatability mode, but the site still sends the same errors whenever set A0SQL_DATA = server.createobject("olddllname.Data") is called.
Is there an issue when running correctly registered old DLL's on 64 bit systems?
Yes, the most prominent example of a 32-bit DLL no longer working on 64-bit Windows seems to be the Microsoft Jet Engine, i.e., the driver required to access .mdb files. Since there is no 64-bit version, the only way to access .mdb files in classic ASP application is to run IIS (or the Application Pool, to be precise) in 32-bit compatibility mode.
How to detect if you are in 32 or 64 bit mode (untested):
Set shell = CreateObject("WScript.Shell")
Response.Write shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%")
This should output AMD64 in 64-bit mode and x86 in 32-bit mode (either native 32-bit or 32-bit emulation on a 64-bit processor).
Well, error 800401f3 means "invalid class name." That strongly suggests that the DLL is registered with the wrong ProgId (or that the ProgId is missing entirely). When your sys admin verified that the DLL was registered, did he also verify that its ProgId is "olddllname.Data"?

Classic ASP using COM+ .Net Interop 64 Bit Windows Server 2008 IIS 7 Server.CreateObject Fails

I am having an issue related to executing a .Net dll from a classic asp application on a 64 Bit Windows Server 2008 server running IIS7. The situation is as follows:
I have written a .Net C# assembly to perform some encryption tasks. This assembly has been made available to the classic ASP environment via inheriting from ServicedComponent, ensuring the assemblyinfo file has the ComVisible(true) attribute, and it has been installed using the "regsvcs" command line.
When testing on my own desktop (XP running IIS6) everything worked fine. When moving to IIS 7, Windows Server 2008 I get the infamous "ASP 0177 Server.CreateObject failed".
I have tried the following to no avail:
Ensuring the ASP and Script Extension features were installed on the server, as this is not the default for IIS7. This allowed me to execute simple ASP commands, but not server.createobject for the .net assembly.
Enabled 32 Bit application support for the app pool supporting the classic asp site
Used NetworkService as the identity for the app pool supporting the classic asp site
Tried registering dll using regsvr32, which failed
I am able to create other objects such as "scripting.filesystemobject"
Moving dll's to the wow64 directory and then using regsvcs to register them.
And yes when I have been executing the regsvcs commands they have been from a command line launched with "RunAs" Administrator. The regsvcs commands have registred successfully
from both the 64 and 32 bit versions. However, when used from the classic asp application, it fails.
This question is closely related to this one. However, I think this question was more related to using tools on the server as opposed to a programatic problem similiar to mine.
Anyone have any more ideas to try?
After a lot of help here and some more research, we finally came across the answer. To solve our issue we did the following:
No longer inherit from ServiceComponent (This is ok, since we are not actually leveraging any specific COM+ features)
Utilized the following commands to install the component, which must be done in order:
gacutil /i "C:\Inetpub\wwwroot\ASPTest*name of dll*"
regasm /tlb "C:\Inetpub\wwwroot\ASPTest*name of dll*"
This process eliminated the original errors and also had the added benefit of being able to replace the dll while IIS is running.
Try this
Component Services -> Computers -> My Computer -> COM+ Applications
Open a COM+ Application object.
Open Components.
Right-click on a class and select Properties.
Under "Advanced" there is a check box for "Allow IIS intrinsic properties".
It works for me
Create a vbs test file and try to create your COM object there. If you can't (i.e. you get the same error) then your component is not registered correctly.
If you can - then it was installed correctly and the problem is with the lack of permissions for the account your application is executed under in IIS.

Resources