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.
Related
I'm trying to debug an ASPNET Core/EF Core website hosted on Azure. When I try to attach the debugger in VS 2015, via Cloud Explorer, I get this error message:
Yet when I check the site in the Azure portal, it sure seems like it's 32 bit and set to enable remote debugging:
So what am I missing or doing wrong?
Portal setting controls the bitness of the IIS w3wp process. But ASP.NET Core runs in its own process, so that setting has no effect on it. Instead, what determines whether your .NET Core process runs as 32 or 64 bit is how you publish it.
Given that apparently your Core project is published as 64 bit, you might want to try switching the Portal setting to 64 bit. This will affect the debugger MSVCMON.exe process, which should then allow you to attach.
I've moved my classic asp app to win 2012 R2 (IIS 8.5). This app uses COM component. I've registered this component using regsvr32 and also exported older components from II 6 to II 8.5. I can see those components in control pane->component services.
This app is not working properly. Code include Server.CreateObject("myCOM"); looks like it works but when I try to get objArgs["prop1"]; it doesn't work.
I see this error:
"Server.CreateObject failed while checking permissions. Access is
denied to this object."
What could be potential issue?
PS: I've installed ASP/server side includes & others.
What are the permissions on the DLL set to? That is, can the user that IIS is running as access the file?
Did you register it as both 32- and 64-bit?
Can you create the object from a test VB script (running from an elevated command prompt, creating from a VBS script or a PowerShell script)?
"Access Denied" usually means exactly what it says on the tin. I'd guess that the IIS user (or that used by the app pool for your site) doesn't have correct permissions on the DLL.
I am having similar problem trying to run an ASP site using ASPMail with PGP on Windows 2012R2. The mailer runs fine, and PGP works if I run it inside PowerShell, but the mailer can no longer use its PGP option, which is running pgp.exe from inside an ASP page.
Turn on ASP from Internet Information Services -> World Wide Web Services -> Application Devlopment Features -> ASP.
I am using TFS 2010 and visual studio 2012.
I have created a C# api to connect to tfs. The code works. I used couple of microsoft.foundation dlls. They are using version 2.0
But I had to configure my application pool in IIS on my server (windows server 2008 64-bit) by setting Enable 32-bit applications to True.
The production server doesn't like the 32 bit and is acting up. The dlls can't be used.
I must find the equivalent 64 bit. Can someone point me to where I can find them?
Thank you
#sudhir3, thank you for your suggestion.
Like I said, the code is not an issue and it works, but that involved setting the 32 bit flag on the app pool.
Further investigations lead me to know that there is no equivalent of 64 bit for the 32 bit dll. VS itself is still 32 bit. No near conversion by microsoft to 64 bit is near.
So, I I ended up leaving the IIS 32 bit flag in the app pool set to false and created web api webservice that passed values to a powershell cmdlet, which in turn executes my TFS api code.
We're supposed to carryout Performance Testing on a 64 bit standalone desktop application on 64 bit OS built around .Net 4.0 and HTML5 with WPF & WCF(it's a ClickOnce Application)..
While using LoadRunner 11.5 for recording, application is NOT launching in the foreground but in the background, the respective process is running in Task Manager.
We've Googled and found out that a ClickOnce Application cannot be recorded using the general installation path(E:\xxx\xxxx\xxxx.exe)
Possible workaround might be going forward with the .exe file in the Deployment Folder. But we're still unable to launch the application using VUGEN via the exe file in the DeploymentFolder path: "C:\Users\username\AppData\Local\Apps\2.0\obscure_dir_name1\obscure_dir_name1\ "
Please find the links below for further info on ClickOnce-VUGEN problem.
Recording ClickOnce Application in VUGEN
MSDN Forums on ClickOnce Application
What is the application (or presentation) layer protocol communication mechanism for this application? (see OSI model definitions for clarity on application of presentation layer protocols)
You will already have an issue regarding a 64 bit application for recording as vugen is a 32 bit application and hooking is not going to effectively cross the WOW32 subsystem barrier for the 32 bit control of a 64 bit application. See release notes regarding the recording of 64 bit applications
I was developing an ASP.NET MVC web app on Windows XP and Visual Studio 2008 (using the Visual Studio web server). I recently installed Windows 7 64 bit Ultimate edition, IIS 7.5 and migrated my app using appcmd.
If I set the flag enable32BitAppOnWin64 == false on my application pool my application works fine. As soon as I set it to true (since I want it to run in 64 bit) it throws this exception:
Screen Shot of error
HTTP Error 500.0 - Internal Server Error
Calling LoadLibraryEx on ISAPI filter "C:\Windows\Microsoft.NET\Framework\v2.0.50727\\aspnet_filter.dll" failed
If I go and delete all ISAPI filters but leave ASP.Net_2.0.50727-64 then this error goes away.
How do I resolve this?
Your key is in the path mentioned in the error:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\\aspnet_filter.dll
Notice there is an extra slash in the path. At an elevated command prompt, navigate to ../Framework/v2.0.50272 directory and run the following command:
aspent_regiis -r
Alternatively, use IIS to modify the correct path of the filter.
So no magic dust needed...you just need to register the right path. :)
It sounds like you need some 64 bit ISAPI filters.
32 bit DLL's will not run on a 64 bit machine unless you sprinkle some magic pixie dust on them. This is why the enable32BitAppOnWin64 flag exists.
Set the flag to true and bask in the glory of the pixie dust.
It sounds like the Handler Mapping preConditions for your site are a bit messed up. In IIS MMC browse to the site and open the Handler Mappings feature. In the Actions pane on the right, click the 'Revert To Parent' link.
Just had this happen to a project deployment.
Changing the application pool for the website did the trick.
Found the answer on Rick Strahl's weblog