Maybe the worst type of error message that one can see. Does not mean anything, may be related to everything...
I try to create a web service (WS) on IIS 7.5 (I have initially tried WCF services but same story)
The WS uses a COM DLL which is successfully registered and the COM security permissions are given.
When I run the WS using Visual Studio Development Server everything is fine, I get the results as requested. But when I try to deploy the WS to IIS, I end up with
System.Runtime.InteropServices.COMException: Catastrophic failure
My computer has Windows Server 2008 R2 Standard, x64.
I have to emphasize: I develop (using Visual Studio 2010 Ultimate), test (using Visual Studio Development Server) and deploy (using IIS 7.5) on the same computer.
I was thinking that the problem might be related to 32-64 bit incompatibilities, as my COM is supporting 32 bits. Therefore, I changed the application pool settings to enable 32 bit applications, changed the platform target to x86 in Visual Studio, redeployed the WS, none of these helped.
My question is:
How can a WS successfully run on VS Development Server but fail on IIS? What else shall I change in IIS settings?
It really helps to consult the producer of the COM DLL. They have given a clear installation procedure for the DLL, that I have somehow omitted.
Moral of the story: Although your web service or web site operates successfully under Visual Studio Development Server, this does not necessarily mean that you have configured all settings for the COM DLL correctly.
You can start checking the following issues:
Register the COM DLL
Check configuration settings using dcomcnfg
If your DLL does not appear in dcomcnfg lists, then probably you did not register it correctly. Some registry editor entries are probably missing.
Check your IIS application pool settings
You may need to impersonate in web.config
Check the event viewer. It might include some important clues
In my case, I was playing with all of these items, but never in the correct sequence. Finally the help from the producer has arrived which was showing the correct path.
Related
We recently migrated from VS 2008 to VS 2013 including a set of setup projects. One of the setup projects is meant to install a web application. It has one custom action that is meant to check the connection to the database. The code of the custom action has not been touched during the migration and the .msi works perfectly when generated from VS 2008. When I built the .msi from VS 2013 it works perfectly well when installing on our local development server, and throw an error saying that it cannot connect to the db when rolling out in the clients environment.
I'd really appreciate if anyone can point me into direction of search here. I know that I'm passing a correct connection string, and .msi generated from VS 2008 can connect to that db from the same server.
Visual Studio custom actions that are installed for Everyone will run with the local system account. Connecting to a SQL DB will often fail because the DB doesn't allow the system account to connect, or because the DB is on a network share and the system account has no network privileges.
So it could fail because of the security settings of the DB or because the DB is on a network, and it may be nothing to do with the server. It might also connect if the install runs with a Just me setting because the custom actions then will run with the installing user's credentials. There may also be issues with architecture because servers are 64-bit and the 32-bit subsystem is optional, and you didn't say whether you install was x64 or your custom action code.
All the sudden started getting the following error while trying to debug a worker role:
"Windows Azure Tools for Microsoft Visual Studio
There was an error attaching the debugger to the role instance 'deployment16(360)blah blah' with Process Id: '8780'. Unable to attach. The Microsoft Visual Studio Remote Debugging Monitor has been closed on the remote machine."
Restarting Visual Studio and the machine do not help.
As you start getting this problem all of sudden in your development machine something must have changed and it is mostly due to some of the OS auto-update and/or some application update you installed in your machine. There could be any random reason for this problem however if I would have hit the exact same problem here is what I would do to troubleshoot such issue:
To start, first thing is to just check it is not an application specific problem by creating a base app from web/worker template and see if that exhibit the problem.
If you have installed new release Windows Azure SDK 1.7 check with both SDK 1.6 and 1.7 to verify if both exhibit the problem.
Check if your could debug IIS based application as well outside Compute Emulator. This will isolate if the problem is specific to Windows Azure development Fabric or bind to your IIS itself.
If this is IIS specific issue, Check IIS configuration for all enabled functionalities, try resetting Application Pool configuration, running "ASPnet_regiis -i" etc to fix the issue.
If it is Windows Azure Computer Emulator specific, I know sometime OS updates may make application unstable so in that case, I will re-install .net 4.0 and VS2010 SP1 again respectively. (This does help so many time) then re-install Azure SDK 1.7 completely.
Such random problem mostly occur due to some change in your machine configuration, so restoring the VS2010 and the re-installing all other application does help to solve problems.
If you have an exception in the role's OnStart() or in Application_Start() that the debugger doesn't pick up, you may also receive this message. Application_Start() errors are especially pernicious because the debugger doesn't attach to the web process until after this method returns.
If you are wedded to cloud specific classes such as RoleEnvironment and cannot make the web role a startup project, you can use Ctrl-F5 to run the cloud project without debugging. With some luck you'll get a yellow screen of death to show you the true error.
Avkash covers the points.
I had the same issue recently. I set my web project as start-up rather than Azure and I discovered that that web project didn't actually run. Turned out somehow when of my projects was compiling for X64. I changed that and it worked.
When trying to install a web setup project (MSI) created in Visual Studio 2010 on Windows Vista, Windows 7 or Windows 2008 Server the setup will fail, with some generic error.
According to http://devio.wordpress.com/2011/04/26/pitfalls-installing-web-setup-msi-on-iis-7/ this is because of a compatibility problem between the setup project en IIS7.
To resolve this I've to enable/install IIS6 metabase compatibility in my windows configuration. This workaround did fix the problem, but raises 2 questions:
Does this have any (negative) impact on functionality of IIS 7?
How can I notify a user running the installation of this problem so he or she can take proper action and install the metabase compatibility component? Is it possible to pop-up the windows component configuration dialog from this install, to make life easier for the user?
I don't think this will have any impact on the application itself, as long as it's implemented the way to talk to IIS7 via its native API. Otherwise, if it doesn't support IIS7 you'd have to enable IIS6 compatibility anyway.
The standard approach to search for anything on a target machine is searching registry and file system. I don't know how it is possible in VS setup project, but e.g. WiX has special elements for this (RegistrySearch, DirectorySearch, FileSearch). Basically, this post to WiX Tips and Tricks thread shows how to check for IIS6 compatibility in WiX and block the installation if it's not enables/installed. It's rather straight-forward even if you don't know WiX, but know the concepts of Windows Installer, and it can help you translate the code into the similar thing in VS setup project.
We seem to be having one negative impact on our servers.
Everytime we roll out a .NET 4.0 application with a msi made in Visual Studio, We get a recycle of ALL our application pools, even the ones not affected by the install.
Apparently the root cause of this is the IIS 6 compatibility. ( This was reported to us by a developer of microsoft in response to our support question about this.
At the moment we have no solution. It's impossible to convert all our installers to Wix.
The environment:
Clean (new) install of Windows 7 64bit.
Clean (new) install of Visual Studio 2010 Professional (10.0.30319.1).
Windows Update is up to date.
The problem:
I cannot start the debugger on Visual Studio 2010 (hit F5): 'Unable to start debugging on the web server. Unable to connect to the web server. Verify that the web server is running and that incomming HTTP requests are not blocked by a firewall.'
However, 'attach to process' (what I usually do) does work, but it is painfully slow to start (Visual Studio 'thinks' a lot of time before the debugging is actually enabled).
On the same hardware, running VS 2008 on good old Windows XP (32bits), this problem never happened.
Trying to debug a site running under the ASP.NET Development Server also fails: 'Unable to connect to ASP.NET Development Server.'.
There are plenty of web pages about these errors (many very outdated and does not apply to my environment), none of them worked for me.
Notes:
No matter if I run Visual Studio as Administrator or not. The problem is
the same.
The problem happens even when running a brand new blank IIS web site, either created as 'localhost/something' or 'sample.local'.
If I create a 'File System' web site (to try ASP.NET Development Server), when I hit F5, the server starts, but after a long wait Visual Studio says 'Unable to connect to ASP.NET Development Server.'
The 'hosts' file has an explicit 127.0.0.1 entry for 'localhost' and for 'sample.local'
It's the same problem either running .NET 2.0 or 4.0.
It's the same either configuring the application pool with or without 'Enable 32-Bit Applications' true or false.
It's the same either configuring the application pool is classic or integrated mode.
In a desperate attempt, I've added all the IIS 6.0 legacy 'features' stuff (not needed!) and doesn't helped at all.
I don't now what else I can try.
Thanks.
OMG!, I'm so stupid. The most oblivious thing was truly wrong. There was a wrong rule in the firewall. Therefore, even being in 'interactive mode' (as it is was always set), the connection was denied.
I keep running into all sorts of nuances between the "web site project" versus "web application project" - here is the latest for me:
I've inherited a Visual Studio 2005 solution with several class library projects (a DAL.dll, a Biz.dll, etc.) but this is all "fronted" by a web site project rather than a web app project.
While the web app project provides a Platform Target dropdown list (Any CPU, x86, x64), the poor web site project appears to offer nothing like that. Is there a way to ensure the web site runs as x86 when hosted on a 64bit IIS machine?
..The bigger picture of why I am asking this:
The website runs on a 64bit machine (Win Server 2003) and [I have just learned] cannot load a 32bit COM object which I believe has been wrapped with a Runtime Callable Wrapper. Because it cannot load this piece, a web.config setting is set to avoid the runtime load error by bypassing the load of this 32bit dll (but all of the functionality of COM dll is therefore "lost" when the site is running on a 64 bit machine).
So, in summary, I presume the web site on the 64bit machine must be running in IIS as a 64bit app and that if I could just get the site to run as 32bit instead, then it could load the COM dll and therefore execute that functionality of the application.
NOTE: I have been and still am doing research here in preparation for a quick uptake when I get access to the actual development environment so much of my question is based on piecing together parts of my [anticipated] problems to be faced soon. Thanks.
As far as im aware, under server 03 you cant have 64 bit and 32 bit application pools in IIS side by side.
You can force it run in 32bit mode but this would affect all application pools, and therefore all sites / apps. This sounds like it should fix your COM issue but it might have an effect on any thing else running on that box so be aware of that. To be fair the chances of switching from 64 bit down to 32 effecting things are less than vice versa. The only common thing that springs to mind that must be ran in a 64 bit applicaiton pool is Exchange 07. Having said that im a dev, not a server admin.
If your sure, look here
Btw, server 08 can rock both 64 bit and 32 bit app pools simultaneously.
There appears to be no x86/x64 target for web site projects, only the Any CPU target. You therefore have to control the bitness of your website by controlling the bitness of your app pool.
On Windows Server 2008 or Windows 7, if you want to make an AppPool 32-bit, go into the IIS Manager > [Server Name] > Application Pools > Advanced Settings. Set "Enable 32-Bit Applications" to "True" for the app pool you want to run as an x86 process.
Note that you will have to take other WOW64 considerations into account, for example, registry settings accessed by your web app will now use the [HKLM\Software\Wow6432Node] key instead of the [HKLM\Software] key.