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.)
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.
I develop and debug an ASP.NET application with VS 2010. My ASP.NET application holds some connections to other applications on other machines. When I stop debugging, I want these connections to be released. If this doesn't happen, these other applications fail and I have to restart them.
In the end I will store my termination code in the Application_End method in Global.asax.cs, but this one is not called when stopping debugging.
Is there a way to terminate the debugging of my ASP.NET application so that not everything is killed at once, but so that one last method is called in which I could add my termination code?
I'm not sure what your problem is but probably...
You initialize your debug session by pressing F5 and thus debugging through cassini. This way when you end your debug session the application is terminated.
If you have a configured IIS application you could simply attach to the running process - it's usually "CTRL + ALT + P" - choosing w3wp.exe (mind the checkboxes on the bottom to be checked). This way your app won't be terminated on ending the debugging session.
Does it solve your problem?
I misunderstood how debugging an ASP.NET application works. I thought the moment I stop debugging (by pressing Shift+F5) the ASP.NET application is terminated and no further line of code is executed. It was my explanation to why the Application_End method is not called.
But in fact the ASP.NET application goes on when the debugger is detached and therefore the Application_End method is not called.
I am developing one product and there are 4 separate projects, in that I have developed one EXE project and WCF and I have done switching in debugging mode by attaching WCF project in process of debugging client of EXE and it has worked.
But when I transfer my WCF to servicestack then I could not able switch between them.
I am running my EXE project and and attached my WCF(servicestack) project to process
JsonServiceClient client = new JsonServiceClient("MYServiceURL");
RESTWCF.ServiceModel.Perfmon objBalPerformanceDataProperties = MakeObjectForServiceStackToInsertData();
var res = client.Post<RESTWCF.ServiceModel.Perfmon>("/perfmon", objBalPerformanceDataProperties);
When I click F11 on client.post I could not able to switch in WCF project, I think you can make sense of my problem.
Give me some solution of this problem so I can debug my code of WCF project (to find error :) in that)
Thanks.
You can only debug one host project at a time.
If you want to test the server set the ServiceStack project to be Start-up Host and press F5 to start debugging the ServiceStack host. Put a break-point at the start of the service you want to hit.
You can then just Run (i.e. without debugging) the client application which if everything is configured correctly, it should hit your breakpoint.
To make sure you're debugging the service correctly, instead of running the client first try calling the web service via a url, e.g:
http://localhost/MyServiceUrl/perfmon
If it hits the break-point you set, then all is well and you can run the client application as mentioned above.
Also it's a good idea to include ServiceStack's debbuging symbols, i.e. it's *.pdb files in the same folder as it's *.dll's - as it helps with debugging.
Note: WCF has nothing to do with ServiceStack - In a lot of cases that's considered an insult :-)
I've got an application that needs to do some work on startup (before the first request is in).
I've added the initialization code in the global.asax file (Application_start method) but this code doesn't seem to be hit after an iis reset is performed.
Is there an event which is triggered in an asp.net application when an iis reset has occurred?
Thanks.
Application start happens on first request, not on iisreset.
The site doesn't start itself..
See "Restart cache item callback on web process restart" here.
In such cases, the service will stop
running unless a page is hit and the
Application_Start is called.
Application_Start is called only when
a page is visited for the first time
in a web project.
I would suggest having a batch file that contains iisreset and an "iexplore mypage" call
Edit: apparently, you can use application end to trigger application start. YMMV
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
This may be of help to you.
Tho the features are new to IIS 7.5 which is only on Windows Server 2008 R2 / Windows 7.
Auto-Start Web Applications with ASP.NET 4
Some web applications need to load large amounts of data, or perform expensive initialization processing, before they are ready to process requests. Developers using ASP.NET today often do this work using the “Application_Start” event handler within the Global.asax file of an application (which fires the first time a request executes). They then either devise custom scripts to send fake requests to the application to periodically “wake it up” and execute this code before a customer hits it, or simply cause the unfortunate first customer that accesses the application to wait while this logic finishes before processing the request (which can lead to a long delay for them).
ASP.NET 4 ships with a new feature called “auto-start” that better addresses this scenario, and is available when ASP.NET 4 runs on IIS 7.5 (which ships with Windows 7 and Windows Server 2008 R2). The auto-start feature provides a controlled approach for starting up an application worker process, initializing an ASP.NET application, and then accepting HTTP requests.
Edit: Link to more information about Auto Start feature.
http://www.asp.net/LEARN/whitepapers/aspnet4#0.2__Toc253429241
What are the advantages/disadvantages to running time based jobs using:
windows services
Application_BeginRequest to start seperate threads / timers.
One disadvantage of running the jobs in the context of a asp.net web appplication is during .net recycling things will have to be setup again, any others?
To my mind, there's no real benefit to doing time-based things in a web app. Go straight to a windows service. You know the process should be up and running all the time.
The ASP.NET site may simply unload, and will only operate again once someone starts browsing. The lifecycle is all wrong -- it's much 'choppier' than a service.
Lastly, services aren't very hard to create.
If you have administrative access to the server, I would either run a Windows Service or a scheduled SQL job depending on what you are trying to achieve.
It is nice to be able to stop/start and log these jobs independent of your web application. Also, if you have problems or errors in the job, it could adversely affect your website.
Finally, you are forcing the web application to go through code at every request to see if the timer has elapsed, which is an unnecessary overhead.
As I said to start with, the implementation depends on what the job is. If it is simply to update a number of database records, I'd use a scheduled job in SQL Server. If you need file I/O or access to external services, then a Windows Service might be more appropriate.
It is worth noting that you need to build in your own scheduling and thread safety into Windows Services. An alternative is to build a console application and use an application like FireDaemon for the scheduling.