I have an orchestration that throws the exception below when calling Microsoft.Practices.ESB.ExceptionHandling.ExceptionMgmt.CreateFaultMessage().
The same code works on one server, but not another, so probably a config issue.
I have re-installed the ESB Toolkit and checked the IIS app pools, but to no avail.
I got to the bottom of this eventually...
A .NET component that makes a web service call received (and bubbled up) an exception that the orchestration couldn't serialize. By handling the exception in the .NET component (and rethrowing it as a serializable one) the problem was solved.
Still not sure how it worked on another server though... I guess some code must have changed after all.
Related
I am new to ASP.NET and I need to develop an application that communicate with a RFID reader.
In order to do that, I have a DLL project which runs a thread that manages the communication with the reader, while a I have another ASP.NET project which manages the user interface.
Those two projects live in the same solution, so the ASP.NET project references DLL project.
At the beginning of the application, my "Global.asax" file initializes the reader (DLL project), running the thread it has inside, and registering some events such as "CardInside" the DLL fires, when a card is inside the reader.
My doubt is if this thread is really running because it does not do anything. I have placed more than one breakpoints in order to see if that part is being run, but nothing stops there.
I have read something about an issue regarding threads an asp.net, but since this thread is not used in a http request:
-is there any problem running a thread in ISS server at the same time as web page?
-Does an aspx.cs file register events fired by another object normally?As if it were not a web application?
-I am using visual studio 2015, could I use DEBUG object to show messages amongst my DLL lines of code?
Thanks a lot.
Yes, there are issues with running threads inside of IIS that are not requests. When no requests have come in IIS will tear down the AppDomain and that will Thread.Abort() the thread you are running your background work in.
You will need to move your code out of IIS and change it in to a actual windows service if you want it running all the time. You then can have your IIS portion talk to the windows service (or vice-versa) to process whatever the web component is.
Can anybody tell how to debug the Com Dll in IIS 7.0 using VB 6.0 in Windows Server 2008 R2.
I am able to hit break point in VB 6.0 accessed from Console Application using interop dlll.Through ASPX pages in IIS 7.0 I am getting the following Exception
Unable to cast COM object of type 'XCreateUser.XAcctUserProfileClass'
to interface type 'XCreateUser._XAcctUserProfile'. This operation
failed because the QueryInterface call on the COM component for the
interface with IID '{7A48FABA-CCC8-4FA6-94E8-803F6CF121F2}' failed due
to the following error: Error loading type library/DLL. (Exception
from HRESULT: 0x80029C4A
Already DLL built and registered and com interop dll generated.
Please somebody show some light on this
Already DLL built and registered
"Registered" is the problem here, it wasn't correctly registered. This is an exception message that's generated by the CLR when it tries to locate the proxy for a .NET component that is [ComVisible]. A proxy is required to make a call to a COM component from a worker thread that doesn't do anything to help make the call thread-safe. A thread that's in the MTA, usually a thread-pool thread.
A .NET component is registered with Regasm.exe. You forgot to use the /tlb argument.
Should be simple to fix. If you still have trouble then SysInternals' Process Monitor is the weapon of choice.
I generally debug these things as you say through a console or windows forms application. You can always add logging to your web app to see what parameters are being passed to it.
Generally errors like the above are setup issues when running on a 64 bit platform and when utilizing 32 bit dlls. One thing to make sure of is that your application pool allows 32 bit applications. In IIS Manager right click on the application pool your website is running under and go to Advanced Settings->Enable 32 bit Applications. Set that to True.
You'll also need to make sure that your 32 bit dll is registered in the 32 bit registry hive. C:\Windows\syswow64\regsvr32 is the version you'll need to use to register this dll.
Context: .NET web service deployed on local IIS in XP. VS 2010 used to debug the webservice code.
Problem:
I am familiar with debugging a hosted webservice by attaching VS to ASP.NET worker process. This approach works if the portion of code being debugged is not the initialization code such as constructors within webservice. When the ASP NET worker process is created, it calls the constructors in the webservice. So by the time we attach to ASP NET worker process from VS, the constructors have already been invoked and therefore not possible to debug.
How do i attach to the ASPNET process and debug the webservice even before it reaches the constructors within the webservice?
Almost a duplicate of this.
You can insert a
Debugger.Launch();
instruction in the web service constructor to be prompted for a debugger to attach. See MSDN.
This may not be the best option, but it was the only solution I was able to find when I had a similar problem. Put a Thread.Sleep(xxxx) in your constructor and try and race to beat the clock and get attached before it is finished initializing. You need to be careful not to set the sleep too high as the service could get stopped if it is not done initializing under a certain number of seconds. (it is also a pain when it decides to kill the service on you before you have finished stepping through the initialization function because it did not return quick enough.)
Got some strange problem.
I'm developing some complicated Web Services network that uses some VB6 .dll. In my previous post I got some problems with the dll but we've solved them.
So, the new problem is:
When I debug my service (those which uses VB6 dll) on development server from visual studio - everything works fine, the problem starts when I publish my service on IIS (I tried my local IIS). After that, when I call .dll method (as I understand I need to call it by reference - and that's what the compiler tells me) I got an exception:
"System.Runtime.InteropServices.COMException (0x800A000D): Type mismatch at ..."
Actually is happens here in the third line:
Object s = (Object)OrderId;
Object s1 = (Object)lines.Length;
proxy.OrderRead(ref s, ref s1);
OrderId and Legth are integers.
As I understant this is exception that comes from the .dll from vb6 :/
What the problem may be? Why it runs when debugging but fails on IIS?
When debugging in vb6,the IDE will register the dll for you. After publishing, have you may ahve to register your vb6 dll on the server. Open a command prompt and change to the location of the dll and run regsvr32 myvb6.dll.
Also, check these settings.
http://support.microsoft.com/kb/281630
Backstory
Last month our development team created a new asp.net 3.5 application to place out on our production website. Once we had the work completed, we requested from the group that manages are server to copy the app out to our production site, and configure the virtual directory as a new application.
On 12/27/2010, two public 'Gineau Pigs' were selected to use the app, and it worked great.
On 12/30/2010, We received notification by internal staff, that when that staff member tried to access the application (this was the Business Process Owner) they recieved the 'Server Application Unavailable' message.
When I called the group that does our server support, I was told that it probably failed, because I didn't close the connections in my code. However, the same group went in and then created a separate app pool for this Extension Request application. It has had no issues since.
I did a little googling, since I do not like being blamed for things. I found that the 'Server Application Unavailable' message will also appear when you have multiple applications using different frameworks and you do not put them in different application pools.
Technical Details - Tree of our website structure
Main Website <-- ASP Classic
+-Virtual Directory(ExtensionRequest) <-- ASP 3.5
From our server support group:
'Reviewed server logs and website setup in IIS. Had to reset the application pool as it was not working properly. This corrected the website and it is now back online. We went ahead and created a application pool for the extension web so it is isolated from the main site pool. In the past we have seen other application do this when there is a connection being left open and the pool fills up. Would recommend reviewing site code to make sure no connections are being left open.'
The Real Question:
What really caused the failure? Isn't the connection being left open issue an ASP Classic issue? Wouldn't the ExtensionRequest application have to be used (more than twice) in the first place to have the connections left open? Is it more likely the failure is caused by them not bothering to setup the new Application in it's own App Pool in the first place?
Sorry for the long windedness
You'd really need to obtain and review the server's Application & System event and HTTPERR logs for the period the server was reporting these errors.
Without these it'd be hard speculate what was the root cause of the problem.
Update:
OP incorrectly tagged his question so this next section no longer applies. However I'll leave in place because I think the information is useful for those encountering these issues and perhaps thinking about migrating to IIS7.x.
You are correct that running two different .NET Framework's in the same application pool can cause these errors but that's something you'd tend to see on Windows 2003/IIS6, not Windows 2008/IIS7.
IIS7 uses a slightly different approach to specifying which .NET Framework version is loaded and it's determined by the Application pool's managedRunTimeVersion property. When requests are processed by IIS/ASP.NET the site's Handler Mapping's use a preCondition attribute to determine when to load the requisite handler (which is kind of like a script mapping in previous versions of IIS).
This mechanism prevents the incorrect runtime version being loaded into the application pool's worker process.
So if an application pool is configured to run .NET Framework version v4.0 only that version will load, even if your application is built against v2.0.
There's a great article on how this works here:
Achtung! IIS7 Preconditions
The section on Handlers about half way through explains why the dangers of accidentally loading the wrong .NET version into a pool are mitigated by the preCondition feature.
A Server Application Unavailable error usually means something catastrophic has happened (like loading the wrong ASP.NET version's ISAPI filter into an already running worker process).
Not closing SQL connections is unlikely to cause this type of serious error. You'd more than likely be seeing a yellow screen of death runtime errors if that were the case. Running out of SQL connections usually doesn't bend ASP.NET so out of shape that the whole service tops itself.
My prime suspect would be a permissions problem where the application pool identity was unable to correctly access the application folders. But it's just a hunch.
Again, what you need to do is get the Application & System event logs and the HTTPERR logs (they reside in %systemroot%\System32\LogFiles\HTTPERR. That will contain clues and facts about what went wrong.
Update 2:
On Windows 2003/IIS6, if you have two applications running different ASP.NET versions that reside in the same pool you will get this error. In my experience (I work for a web hoster) it is the primary cause of this infamous error page:
There's also a tell-tale event logged to the Application Event log:
Event Type: Error
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1062
Date: 12/01/2011
Time: 12:31:43
User: N/A
Computer: KK-DEBUG
Description:
It is not possible to run two different versions of ASP.NET in the same
IIS process. Please use the IIS Administration Tool to reconfigure your
server to run the application in a separate process.
Whilst your root application may not be written in ASP.NET it's likely that something has triggered loading of a different version of the framework into your site's application pool.
there's a rogue web.config in the root...this will trigger ASP.NET to load
there's a wildcard mapping to ASP.NET 1.1 in the site script maps (less likely, but possible)
I'm inclined to think that your new application most certainly ended up in a pool where other sites or applications were running a different framework version. The only way to really find out is to obtain the Application event logs and look for the event shown above.
It's hard to tell; there could be many causes (too many resources used, calling outside of .NET caused something to crash, etc). I would look in the Event log and see if you can find something there.
If you're running different versions of .NET you definitely want separate pools. If you have the option, I would recommend separate pools for each application (even if in the same .NET version).
As far as "closing the connection" (I assume you mean the connection to the database). If you're creating "low level" connections (i.e. SqlConnection, SqlCommand) then make sure you're wrapping them in a "using" statement, otherwise your connection pool can fill up. In my experience though, you should receive regular .NET errors in this case. If you're using an ORM this shouldn't be an issue.
Edit:
If you can't find anything useful in the Event Log, you could try this: http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/