I have an ASP.NET project using a COM dll. When I load the site, I login without a problem and I can browse the site fine as long as I don't go to a page which uses the COM library.
When I go to a page which uses the COM library to get data from a database, the page loads fine. The problem comes when I navigate away form this page. For some reason I am sent back to the login page as if the initial session was dropped.
If I take away the component on the page which displays the data which the library retrieves, I can navigate away from the page, so it is definitely the call to the library that kills the session.
Does anyone have any idea why this could happen??
Fixed it. It was a silly problem. The library created a log file in the bin directory every time it did something. The session gets dropped everytime there's a change in a file in the bin directory because the AppDomain gets destroyed and restarted.
I wonder if the COM component crashes and tears down your application pool (or whatever it's called these days in ASP.NET).
Can you keep an eye on the ASP.NET worker process (it used to be called aspnetwp.exe) and see if it disappears when you navigate to the page with the COM calls?
If so, the COM component probably throws a structured exception, which terminates the process, causing your session state to be lost, if you store it in-process on the server.
You might be able to glean more information from the Event Viewer (Start -> Run -> eventvwr), where ASP.NET logs any crashes.
Related
I have a basic webforms asp.net site. Currently its working on pre-created sql tables and I have to manually triger it to update data. Moving towards a live deployment though, I'd like to make it more comfortable.
How would I make it so that whenever the server software loads it up, the first thing it does before accepting any requests is to run an initialization sub? Just so I can make sure all the tables are there and if not I would create them etc.
Also, I'd like to run another sub that would trigger the data update periodically every few hours. I was thinking that if I could get my initialization sub, I could just spawn a background thread to deal with that but if theres a built-in option, I'll take it.
whenever the server software loads it up
In asp.net, you have the global.asax file - open the code behind for that and look at the possible overrides. Among them will be:
protected void Application_Start()
This always runs when the application starts up and you could use this to check the DB.
If you're in an "in-house" environment where there's a single live database server and a single live application server, then it should be ok to assume that the database is deployed before the application and you won't need this. If you're providing an application to a third-party or providing it on the web, then this is a good place to check. How you generate the DB is up to you, but checking here is a good idea. You could also have a (hidden) admin page on your site that checks the database connection etc.
trigger the data update periodically
This won't be built-in to asp.net as asp.net waits for requests and responds to them. There are ways around this, but generally triggered externally to the application. The easiest is a simple windows scheduled task that hits a page to trigger the check.
This is what's referred to as "deployment".
If your web site is deployed via MSI, this step should be done in MSI.
If your web site is deployed via Visual Studio "publish" option, this is where you need to create tables.
Some applications indeed do as you say, e.g.: create SQL tables on the 1st run. The problem with this approach is that your app will need sa rights, instead or simple read/write. This could lead to security issues.
Code which runs on web site launch (which is where initialization belongs to) is located in global.asax in:
protected void Application_Start()
I'm deploying an ASP.NET application (just a simple Http Handler) to IIS (7.5) and I'm seeing the AppDomain unload after the first request following the deployment.
I'm just doing a simple file system deployment (copying the new files (web.config, bin folder, etc.) to the application location (C:\inetpub\wwwroot.....)) and based on messages being logged from the Application_Start and Application_End event handlers in Global asax, this is what I'm seeing:
The initial file copies cause the AppDomain to unload and I get a message logged via Application_End: the shutdown reason is generally 'ConfigurationChange'.
A request to the application causes the AppDomain to be re-loaded, so I get a message logged via Application_Start.
Once this request has been serviced the AppDomain is unloaded again, this time with the reason 'BuildManagerChange'.
I've tried stopping the application pool before step 1 and starting it again before step 2, but with the same result.
Searching around the web, the usual reason for a 'BuildManagerChange' shut down is that the hash.web file has changed in the Temporary ASP.NET Files folder for the app, and indeed this does seem to be what's happening in this case. As part of the application startup I'm guessing that, as part of the BuildManager initialization, it's calculating a hash of the various files in which it's interested (web.config, global.asax, etc.) and that because this is different to the value currently on file (because it's just been deployed), it's unloading the AppDomain.
So I guess my question is, why doesn't the original AppDomain unload caused by the file copying update the hash.web file? And is there any way for force this? At the moment all of the evidence suggests that it will always go through a shutdown-startup-shutdown cycle before it gets going, but I just can't believe that this is correct. Am I missing something really simple?
I have a web application that is used by several different clients. At the moment the process of updating their end with any changes is like so:
Publish/Compile App
Put relevant files into a zip (not web.config as different db paths for each client and don't want to overwrite)
Generate scripts on SQL Server for all Stored Procedures
Add to zip
Upload zip to Web
WPF App I created that runs from client server downloads zip, extracts files to web app folder and executes scripts for sql server stored procedures
Now this does work but it requires an IT guy at the client end to run the WPF App to update and it can be days before some of them get round to it. So what I would like to do is provide the ability to update the web app from WITHIN the web app. I know I can create a DLL to do the FTP, Extract etc, but how can I get this to display progress on the page?
Or if anyone has an alternative to updating the web app without the need for someone to access the server it's on great as this method makes it hard to let clients know when there is an update available.
You can use i.e.
[assembly: PreApplicationStartMethod(typeof(Your.Type), "MethodNameToCall")]
which is specified in the AssemblyInfo.cs file of a project to do some setup code whenever the application is deployed. This automatically runs on deployment and would allow you to do your copying/setup. You could probably run the WPF App from this code via
System.Diagnostics.Process
UPDATE:
Having re-read this post it seems clear to me that this is about moving from a WPF app to a web based app. Also it appears the poster just wants a method by which to signal back from the code that is updating the file system on the client side so....
Depending on how complex the input required is you may need one or more pages and a navigation system to go forward and back.
However once all input had been taken and the update commenced you have a couple of options - one 'hacky' the other not so.
1 - Hacky) Refresh the page using window.location javascript and setTimeout along with session tracking to update the progress of the threaded coded behind EWWWWW...
2) Create an ajax function using setInterval to poll the server (probably using a callable method decorated with the [WebMethod] attribute. This method can send back arbitrary data back to the ajax call which is then used to update the UI (perhaps using something like jqueryUI progress bar
NOTE: IF you are replacing anything in the bin, touching the web.config or in fact ANY .aspx page. Then you will restart the server automatically... If this is the case then you will have to code a seperate application that will update the other application from the outside + you should signal to any connected users that a shutdown will occur shortly and start blocking new users until the upgrade has completed.
I've run into a problem I just can't seem to solve. The background: Years ago, I developed a web site for one of my customers using ASP 2.0 and Ajax. One function of the web site is to produce customer invoices, on demand. Their in-house production system is written in Visual Foxpro 8 with SQL Server 2005 on the back end. Since I already had an invoice generation object that would produce a PDF file, I rolled up a COM EXE and created a COM wrapper for use in my ASP page. It works great for years, but now we're trying to move the page to a different location and things aren't working so great.
The network techs have re-produced the environment and the rest of the web site runs perfectly. I can even instantiate the COM object (I've logged the init and all is well), but the very first call to one of the objects methods results in an "Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))". I'm just plain stuck!
Here's what does work:
1) Using a visual foxpro program from the same server I can instantiate the object, call the generate invoice method and produce the PDF - no problem whatsoever.
2) Using VBScript from a very simple ASP page I can use Server.CreateObject() to instantiate the object and successfully generate the invoice from there.
So far I know:
1) the object is registered correctly and is launching as the proper user, with all of the rights needed to do it's business.
2) the wrapper for the COM EXE and COM object versions are matched.
I apologize for the long post. To make a long story short: Why would ASP.NET not be able to make a call to any method of a VFP COM object after it's been instantiated successfully?
Thanks in Advance - I'm seriously stuck on this one.
Erik
For those running into the same situation, adding the COM EXE to the Data Execution Prevent (DEP) exception list allowed the calls to the objects methods.
Did you compile it as an EXE, a runtime DLL, or Multi-Threaded DLL. Additionally, a problem I've had before is that of single or multiple instances of an OlePublic dll entry. To confirm, modify your project... then from the Top Menu, click "Project", then "Project Info". On the third tab is "Servers" showing the available servers in your project. On the right side of it is "Instancing" this would be either single or multiple. Sometimes, just throwing this to single has solved instances for me. However, if multi-threading, make sure you have the multi-threaded dll too.. VFP9T.DLL
--- EDIT PER RESPONSE...
Since you compiled it as an EXE, Its probably going to show up as a distributed COM object. Go to the Windows "Start", and run "DCOMCNFG" which will bring up the DCOM Configuration manager. You'll have to scroll down the list of items until you find your exe (OlePublic class name) and might have to revise permissions, who can launch / access / execute... apply impersonate, etc...
FOR TESTING ONLY --- You could set this COM server as impersonate Administrator -- JUST TO TEST and see if any errors or not. If no errors, then you'll know its a permissions thing, then change it back to a more restricted user.
Is it possible to update the site dll for a precompiled site without stopping IIS.
Currently, if I try to just copy the new file to overwrite the current file, All users receive runtime errors while the file is being copied. Is there a way to avoid this?
even if you don't stop, any change to the web.config file, BIN folder, App_Data or App_Code will force the .NET compiler to perform ...
and you will loose any Session variables in memory.
What I do is to use Session State in SQL Mode and if your system is set up like this, user will remain in the site (after a longer exposition to a page reload)
.NET will still invoke the compiler in order to compile the new set of instructions but soon it is done, all sessions will be read from SQL Server and because they are still there (and not lost with a memory refresh) users will remain in the website with current credentials.
it is a little bit slower than In-Memory Session State, but much more reliable, specially with Shared hosting :) this is the way to increse/decrese the minutes in your session, as Shared hosting do not allow it to change even if you do
Session.Timeout = 5;
their machine configuration will override everything you do, with SQL Session State, you will be able to set your time as this is all made by SQL Server.
Fell free to read this article to know how everything is done.
Hope it helps.